Elastic Cloud password complexity has an “OR” condition
dropbox.com
dropbox.com
But every application context is different, so maybe offering a clear text password for your users to choose might ring the wrong bell in yours.
These are all internal users at large CPG companies in sales or accounting. I don't understand how so many people who have to work with software all day cannot figure out passwords and login flows.
Except in France - CNIL does not agree with NIST. :(
Passphrases are perfectly reasonable choices for passwords, but often run foul of the number and special character rules. Worst part is some sites even have very short max length rules for passwords. One can only suspect they either go around thinking people still memorize passwords, or worse, they store passwords in a varchar(12) DB column.
The best bet would be to eliminate passwords alltogether using some combination of webauthn key authentication and some other user friendly factor (e.g. TOTP). But as long as passwords are here to stay, make them user friendly.
/jackie-chan-meme
... doh, that's 17 characters
Which is at least somewhat non-trivial. What is the entropy of »abcd«? Four of four different characters, therefore 8 bit? Four hex digits, therefore 16 bit? Four lowercase letters, therefore 18.8 bit? Or even four letters, therefore 22.8 bit?
Ad hoc I would say that 8 bit seems to be the best choice as one does not have to guess the underlying alphabet, but that probably means that you mostly get values quite a bit lower than password length times the logarithm of the alphabet size would suggest.
You'd also want to do things like look for patterns, because tools like John the ripper absolutely do more than random guessing.
You are absolutely right there, and zxcvbn makes a guess by using the whole character set for a specific type. It groups a whole bunch of special characters together as well, potentially overestimating passwords that contain a special chars.
This is mitigated by the fact that it's much less important to be good at estimating the score of a properly random password than it is at estimating poorly (human) constructed password.
It's a game of making the best assumptions you can, but total accuracy is not something to shoot for here.
I may just try and implement and see what it looks like.
HIBP works by having the client SHA1 hash the password and send a 5 character hash prefix to the API. What you receive in response is a list of all breached password hashes which you can then compare the full hash against.
https://haveibeenpwned.com/API/v3#SearchingPwnedPasswordsByR...
HIBP never receives the password or the full hash. Did you have any other risks in mind?
No specific risks, I was just trying to keep a very low footprint with this library to give little reasons for a security department to tell developers "no, don't use that".
Grinds my bloody gears.
What irritates me more is knowing that the people who implement those solutions are probably here. Shame on you, go back and fix it right now!
Login with your password. Site then responds that we emailed you a security code, but the security code expires in five minutes. Immediately below that, it notes that the email may take up to four minutes to send. From experience, I think the note about slow emails is accurate.
Who spent more than 30 seconds on that implementation thinking it was acceptable? Note that this is for a stupid intra-company fitness tracking thing (ie, I do not care at all about this data). Confirmation codes from my bank have a 30 minute window, but that is evidently too lax for step counting.
Now that whole site has the weirdest bugs. When I go to the mailbox, the site switches to some eastern european language. The things we do for cheap electronic components ...
'; DROP TABLE users; --
just for the lulz...
Oh, of course they truncate also the password confirmation field.
So I restrict my password manager to use what I consider to be a widely accepted subset of the printable characters, and then some random website will complain about the lack of this or that character. :(
It matters, because it is annoying. Password security rules should achieve two goals:
1. Actually improve security
2. Make it easy for users to choose a good password
A password policy of "chose one or more lowercase, one or more uppercase, two or more numeric and at least one special character, but not the one that you have been thinking of" does not achieve that goal, especially if they limit the password length to 15 characters.
Just tell give them a reasonable minimum length, check against the most common passwords and their username and call it a day. If you need more security, increase the minimum length.
Maximum length should be chosen in a way that nobody who is not malicious will notice it (e.g. 128 chars or bigger).
This produces safe passwords, is understandable and people with password managers are served as well.
What kind of absolute maniac comes up with such a password policy? Demanding friggin' two numbers and then limiting the password length to ridculous 15 characters?
On a more serious note: enforce minimum length, enforce that it is not in the list of most common passwords, enforce that the password is not their username/email and inform about the risk of password reuse.
If an account is hacked because they used "password" as their password they won't care about your argument why it was hacked (and if you did things right you won't know what password they used). So better avoid that class of problem in front.
But there is a lot of wiggle room between maxlength=8 and allowing people to upload the source code of DOOM as their password.
You store a cryptographic hash of the password, which will always be a fixed length.
This makes the actual password length irrelevant to back end storage.
What you do is use a hashing function[0] in the provided password and you store this result in the database. And these hashes tend to have a fixed size output. So it doesn't matter if your original password had 10 or 200 characters, the resulting hash will have the same size.
[0] - https://www.authgear.com/post/password-hashing-salting
Is this a common problem? Which sites do this?
It's also happened where sites have updated their password policy, e.g. to set an upper length limit after I signed up and now I can't login because it won't let me enter my longer password.
I think they simply truncated the input though, but didn't enforce a maximum length during signup.
I really like this way to ensure password robustness, users with password generators are not blocked by some absurd rules.
2. the password is not allowed to be in the list of the most common passwords
3. username, email or similar is not allowed to be in the password
(If you hadn’t posted I would’ve backed out of it too.)
e.g. a 15-character password without complexity could be all lowercase letters.
> john has many feats but this particular one is spectacular