Slashdot Mirror
Slashdot Asks: Are Password Rules Bullshit? (codinghorror.com)
Here's what Jeff Atwood, a founder of Stack Overflow thinks: Password rules are bullshit. They don't work.
They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
Are often wrong, in the sense that they are grossly incomplete and/or insane.
Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". What do you think?
They heavily penalize your ideal audience, people that use real random password generators. Hey, guess what, that password randomly didn't have a number or symbol in it. I just double checked my math textbook, and yep, it's possible. I'm pretty sure.
They frustrate average users, who then become uncooperative and use "creative" workarounds that make their passwords less secure.
Are often wrong, in the sense that they are grossly incomplete and/or insane.
Seriously, for the love of God, stop with this arbitrary password rule nonsense already. If you won't take my word for it, read this 2016 NIST password rules recommendation. It's right there, "no composition rules". However, I do see one error, it should have said "no bullshit composition rules". What do you think?
It's "cargo cult" requirements. People are so used to the security theatre of the password rules that when they come to specify what their system should do they put in all of this stupidity, They don't actually read NIST guidelines. Maybe we should lobby for some kind of certification mark - and the people who assess it would have some clues.
they could extract various 4-character permutations, and store a salted hash of those characters along with their positions within the password.
The organisation I work for used to do exactly this. Then one day they decided that they would use a hardware password vault, with the ability to verify the password combinations. The problem was that to move to the vault we would either have to get access to the full password or get everyone to re-register. The business said to me "is there anyway you can get the original password". My initial reaction was "no - it's hashes the password isn't stored", but after a litte thought I realised that the first 4 character combination was basically a 4-character password. A naive brute force could crack it in about 45 seconds. Optimizing simply so that it would try the most common letter combinations first reduced that to under 20.
Having obtained the first four characters XXXX---- finding the subsequent ones XXX-X---, XXX--X-- and so on is sub-second, you only have to find one character each time using the appropriate hash. Cracking the whole customer list took just over 2 days
The current solution uses multiple passwords each of which are known to only one role of person, something in the hardware unit, a value put in the database by the DBAs, and a value set in a file by devops. We know that encrypting the password is not the most secure method but the reason that we use the "4 from n" is we see the risk as asymetric; there is a much larger chance that the customer's PC will be compromised than our systems. Also over a certain limit we require two-factor authentication.