The n-tries lockout rule is much more effective anyway, as it breaks the brute-force attack vector in most cases. I am not a cybersecurity expert, so perhaps there are cases where high-complexity, long passwords may make a difference.
Not to mention MFA makes most of this moot anyway.
Sure, I do use password managers for random sites and services but I probably have at lower double digit amount of passwords memorized for the stuff that matters. Especially for stuff that I want to be able to access in an emergency when my phone/laptop gets stolen.
Moreover, those numbers did not changed for years and years. Unlike passwords that change, like, every 3 months.
Phone numbers of the people you called the most (the 10 you memorized) were overwhelmingly likely to be local numbers, so you were only memorizing (3 number chunk) + (4 number chunk). Password rules are all over the place. Memorizing numbers, letters, whole words, the capitalization of those letters and words, and special characters, that are far longer than ye olde timey phone numbers, is orders of magnitude more difficult.
I have over 100 passwords in my password manager. They are all unique, so if any one is compromised, it is contained. My password manager is protected by strong 2FA, so someone would have to physically interact with my property to gain access. In the real world, there is no scenario where memorizing all your passwords is more secure.
Most managers have 2FA, or an offline key, to prevent this issue, and encrypt your passwords at rest so that without that key (and the password) the database is useless.
I haven't turned off my desktop this year. How does encryption at rest help?
And even if it were, who would buy a used SSD with unknown durability gone?
Bitlocker (or anything comparable) makes it safe or ATA Secure Erase if you can issue it (not usable for the system drive most of the times) and check it afterwards.
> And even if it were, who would buy a used SSD with unknown
it doesn't worth it for $30 drive, for the multi-TB ones it's quite common, especially for the ssrver grade ones (look for the PM1723/PM1733)
The database is encrypted at rest.
Normal dude in a secure office? An auto-locking password manager would suffice.
Someone that should be concerned with passwords in-memory is someone who believes another has full physical access to their computer (and can, say, freeze RAM in nitrogen to extract passwords
My largest concern would be an adversary snatching my phone while my password manager was actively opened
So only Windows seems to use secure memory protection.
My point is that you need to read up on it to ensure the implementation of memory handling for your password manager is really safe. As you demonstrate yourself, KeePass has different clients with different memory protection profiles which also depends on the system.
I love proton pass.
I understand the conceptual risk of storing everything behind a single “door”. That’s not ideal. But in practice, circumstances force you to create passwords, expose passwords, reset passwords, so you cannot remember them all. You either write them down (where? how secure?) or resort to having only a few “that you usually use”.
Password managers solve the “where? how secure?” part. They don’t solve security, they help you to not do stupid things under pressure.
So "arugula" will score is very badly in the context of a passphrase of English words, but scores better as a (supposedly) random assortment of lowercase letters, etc.
It's very frustrating when you've got a secure system and you spend a few minutes thinking up a great, memorable, secure password; then realize that it's too few (or worse, too many!) characters.
Even worse when the length requirements are incompatible with your password generation tool.
Both NIST in the US (https://pages.nist.gov/800-63-FAQ/) and NCSC in the UK (https://www.ncsc.gov.uk/collection/passwords/updating-your-a...) have quite decent guidance that doesn't have that kind of requirement.
I think the number of orgs that follow best practices from NIST etc is pretty low.
There's nothing inherently wrong with that, but many of these require dubious "checkbox security" procedures and practices.
Unfortunately, there's no point in arguing with an insurance company or a contract or a certification organization, certainly not when you're "just" the engineer, IT guy, or end user.
There's also little point in arguing with your boss about it either. "Hey boss, this security requirement is pointless because of technical reason X and Y." Boss: "We have to do it to get the million dollar contract. Besides, more security is better, right? What's the problem?"
As you say, these are largely box ticking exercises but you don’t have to accept the limited options they give you as long as you can justify your position
Legitimate users usually aren't going to fail more than a couple times. If someone (or something) is repeatedly failing, lock that shit down so a sysadmin can take a look at leisure.
>disallow users to choose a password they used previously (never understood that one)
It's so potentially compromised passwords from before don't come back into cycle now.
There's so many reasons I get passwords wrong. (it doesn't help that work has 4 systems that all use different passwords, all with different requirements).
If you locked me out (without me being able to easily unlock myself), I would immediately consider this an even-more-hostile relationship than normal and would immediately respond in kind.
Have your users authenticate to the wifi with a certificate that expires after 18 months, and you'll find users will reboot a dozen times or so, racking up authentication failures each time, before they call IT support.
I think Epic Game Store hit me with that one the other day. Had to add a 1 to the end.
A common pattern for me is that I create an account at home, and make a new secure password.
Then one day I log in a work but don't have the password on me so I reset it.
Then I try and login again at home, don't have the password from work, so try and reset it back to the password I have at home.
That’s because you never responded to an incident when user changed their compromised password because they were forced to only to change it back next day because “it’s too hard to remember a new one”.
Disallow the use of breached passwords - whenever a password change occurs check against e.g haveibeenpwned. No need to remember past passwords (which is another security risk btw if you ever get breached it will leak all passwords the user ever had).
I suspect that rotating passwords was a good idea at the time. There was some pretty poor security practices several decades ago, like sending passwords as clear text, which took decades to resolve. There are also people like to share passwords like candies. I'm not talking about sharing passwords to a streaming service you subscribe to, I'm talking about sharing access to critical resources with colleagues within an organization. I mean, it's still pretty bad which is why I disagree with them dismissing educating end users. Sure, some stuff can be resolved via technical means. They gave examples of that. Yet the social problems are rarely solvable via technical means (e.g. password sharing).
Rules like "don't write passwords down," "don't show them on the screen", and "change them every N days" all make a lot more sense if you're managing a bank branch open-plan office with hardwired terminals.
Physical security is easy, who's gonna see inside your purse? How often does that get stolen? Phones and laptops are high-value targets for thieves, and if they're online there could be a vuln. Paper doesn't have RCE.
(That said, I use KeePass, because it's nice to have it synced and encrypted. These days only my KeePass password is written down.)
I had been using my credit card for at least a decade (Europe) and it never ever occured to me that the embossed letters had any function other than aesthetic.
And the cheques... jaw drop
>I suspect that rotating passwords was a good idea at the time.
It is just another evolutionary artifact from a developing technology complexed with messy humans.
Repeated truisms - especially in compsci, can be dangerous.
NIST has finally understood that complex password requirements decrease security, because nobody is attacking the entrophy space - they are attacking the post-it note/notepad text file instead.
This is actually a good example of an opposite case of Chesterton’s Fence
The advantages just didn't outweigh the disadvantages in this scenario.
Usernames are public now.
Back then, your username was public, and your password was assumed cracked/public, within a designated time-frame.
Your analogy would hold if when your cert expires, everyone gets to spoof it consequence free.
Certificate expiration, and cryptographic key rotation in general, works and is useful.
https://leahneukirchen.org/blog/archive/2019/10/ken-thompson...
[previous hn discussion]: https://news.ycombinator.com/item?id=21202905
It is extremely unlikely a modern certificate will be broken in the time horizon of a few years through a cryptography break.
All systems eventually fail, but i expect it will be several decades at the earliest before a modern certificate breaks from a crypto attack.
Keep in mind that md5 started to be warned against in 1996. It wasn't until 2012 that a malicious attack used md5's weakness. That is 16 years from warning to attack. At this stage we dont even know about any weaknesses about currently used crypto (except quantum stuff)
Rotating certificates is more about guarding against incorrectly issued and compromised certificates.
Rotating certificates guard against bad PRNG and birthday paradox
Tbh, i have no idea which part you are attacking with the birthday attack in this specific context. It doesn't seem particularly relavent.
(At the risk of saying something stupid) - i was under the impression RSA did not use nonces, so i don't see how that is relavent for an rsa cert.
For an ecdsa cert, nonce reuse is pretty catastrophic. I fail to see how short lived certs help since the old certs don't magically disappear, they still exist and can be used in attacks even after being rotated.
But there have been several high-profile cases of bad RNGs generating multiple certs with RSA keys that had common factors. I think if you were put at risk by such a broken RNG, frequently re-generating your certs would tend to make things worse, not better.
So it's essential that if/when a bad guy pops a single server that they don't get a secret that allows them to conduct further attacks against the site for some indefinite period into the future.
Contrast that to the other examples you provided. All of them are typically valid for several years. In two of the cases, people are managing a limited number of pieces of plastic.
It did not converged to secure state, it necessary converged to everyone creating some predictable password system.
Actually NIST provide a detailed rationale for their advice [1]. Attackers very much are attacking the entropy space (credential stuffing with cracked passwords is the #1 technique used in breaches). But password change and complexity rules are pointless precisely because they don’t increase the entropy of the passwords. From NIST:
> As noted above, composition rules are commonly used in an attempt to increase the difficulty of guessing user-chosen passwords. Research has shown, however, that users respond in very predictable ways to the requirements imposed by composition rules [Policies]. For example, a user that might have chosen “password” as their password would be relatively likely to choose “Password1” if required to include an uppercase letter and a number, or “Password1!” if a symbol is also required.
Pretty much anyone I've spoken to candidly about rotating passwords has said that they use a basic change to derive the next password from the old. For example, incrementing a number and/or a letter. If that was as common a practise as I suspect, then rotating passwords doesn't add much security. It just meanstthat hackers had to go through a few common manipulation strategies after breaking the hash.
Require frequent passwords, humans cheat, boom: your brute-force space just went from 1024 bits to 14, assuming you can onboard a red-team plant far enough to get the template for the default passwords.
If I know _bigcorp_ gives defaulted credentials in the format of [First Initial + Middle Initial + month_day] then not only can I piggyback a trivially-created IT/support ticket, I can also just guess that in 60, 90, 120 days, your credentials are the same, but the month_day - even if not correct, the search space is reduced by magnitudes.
(Yes, I'm commenting on the wierd idea about not allowing processes to run without asking - we're now learning from mobile OSes that this isn't practically feasible to build a universally useful OS that drove most of computer growth in the last 30 years).
Which is better, a strong password written down, or better yet stored a secured password manager, or a weak password committed to memory?
As usual, XKCD has something to say about it: https://xkcd.com/936/
1. Bank etc will not allow special characters, because that's a "hacking attempt". So Firefox's password generator, for example, won't work. The user works around this by typing in suckmyDICK123!! and his password still never gets hacked because there usually isn't enough bruteforce throughput even with 1000 proxies or you'll just get your account locked forever once someone attempts to log into it 5 times and those 1000 IPs only get between 0.5-3 tries each with today's snakeoil appliances on the network. There's also the fact that most people already know that "bots will try your passwords at superhuman rate" by now. Then there's also the fact that not even one of these password policies stops users from choosing bad passwords. This is simply a case of "responsible" people trying and wasting tons of times to solve reality. These people who claim to know better than you have not even thought this out and have definitely not thought about much at all.
2. For everything that isn't your one or two sensitive things, like the bank, you want to use the same password. For example the 80 games you played for one minute that obnoxiously require making an account (for the bullshit non-game aspects of the game such as in game trading items). Most have custom GUIs too and you can't paste into them. You could use a password manager for these but why bother. You just use the same pass for all of them.
Honestly, this comment shows, that user education does not work.
I'd be very wary of logging into accounts on any computer/phone other than my own.
Mandatory password composition rules (excluding minimum length) and rotating passwords as well as all attempts at "replacing passwords" are inherintly dumb in my opinion.
The first have obvious consequences (people writing passwords down, choosing the same passwords, adding 1) leading to the second which have horrible / confusing UX (no I don't want to have my phone/random token generator on me any time I try to do something) and default to "passwords" anyway.
Please just let me choose a password of greater than X length containing or not containing any chachters I choose. That way I can actually remember it when I'm not using my phone/computer, in a foreign country, etc.