Elastic Cloud password complexity has an “OR” condition(dropbox.com)
dropbox.com
Elastic Cloud password complexity has an “OR” condition
https://www.dropbox.com/s/mk4e0m73lqjayp1/password_or_condition.png?dl=0
82 comments
I hope this catches on. I hate making 30+ character passwords only to be told I need to add capitals and whatnot to be secure.
And then some sites throw salt in the wound by requiring "at least one special character that is not # or % or whatever" so if you turn on special chars for your password generator, you have to manually filter through it to pull out said characters.
Or how about "Sorry, your password may be at most 12 characters long".
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!
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!
My favorite faux security thing I have run observed in the wild:
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.
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.
AliExpress! They give you something like 30s to enter the "2FA" code to log in, only it takes ~20s for the SMS to get to me. Took me 3 tries.
As someone who just a week ago implemented a similar thing: SMS sucks. Sending it can take any amount of time it seems. Sometimes <10s sometimes a minute or more and unless you get a report from your provider you don't know which it was. The only reasonable solution was to adjust the timeout of the sent token.
Last time I was there, I actually couldn't get the login screen to appear. Clicking login grays the site out and draw 2 useless horizontal lines. Only clicking 'create account' and then switching to 'already have an account' gives me a login screen. As a bonus, mistranslations are so bad the text on the 'create account' and 'already have an account' are identical. You have to guess which dialog is which. All of this on firefox with ad blocker, maybe chrome is better.
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 ...
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 ...
[deleted]
More likely, people who are here are forced to implement security policies adopted by cybersecurity teams that have long since left the company, and the current cyber teams have no incentive or desire to changed said policies.
Yeah, love how my bank has a password length requirement of "8 to 14 characters".
Or you find one of those lovely sites where the password has a max length and they tell you it, but instead of validating, they truncate the password and save silently.
Oh, of course they truncate also the password confirmation field.
Oh, of course they truncate also the password confirmation field.
My favourite is when you enter a long password, and it fails with the error message "Your password must contain special characters" or some other message that nothing to do with the condition that is not met.
My favorite must have been the website that informed me that my password was invalid, when it actually didn't like my last name (forgot the specifics – I think that's because there was a dash in the name?)
Just yesterday I had a form ask me to use a special character, one or more lowercase characters, one or more uppercase characters and two (!?) or more numbers. The password must be between 6 and 15 characters long.
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?
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?
Why does it even matter? Don't you use a password manager to generate passwords for you?
The strings generated by password managers are often incompatible with arbitrary requirements imposed by websites. You must use a symbol, but some symbols are forbidden and we're not going to tell you which ones! You can't have more than N consecutive numbers! Your password is too long! It must be exactly 15 characters long! etc. etc.
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. :(
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. :(
Everybody who uses a password manager encounters stupid password rules regularily.
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.
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.
Stopped caring when I started using Bitwarden to autogenerate and store long, complex passwords. That was the real game changer.
Every once in a while, I have to actually type in a password manually. That’s why I’d prefer to simply use 32 alphanumeric lowercase characters. Sadly, abundant bad policies make that impossible (including: your password is too long…)
The worst is when they accept your long password only to truncate it silently so the password doesn't work when you use it to login.
I've had a site let me sign up with a 128 char password, but the input on the sign-in page was capped at 30. Edited the form element to log in, pinged them about the issue, and got it fixed
I know this is anecdotal, but this has never happened to me in my life.
Is this a common problem? Which sites do this?
Is this a common problem? Which sites do this?
Happened to me half a dozen times or so over the years.
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.
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.
Last time I saw this was the Sophos XG web interface some time ago. User changed their password and couldn't sign in, turned out it got truncated somewhere.
I've had this happen to me with PayPal a few years ago.
I think they simply truncated the input though, but didn't enforce a maximum length during signup.
I think they simply truncated the input though, but didn't enforce a maximum length during signup.
This is why I default to 16 alphanumerical chars. This is more than strong enough for random internet accounts but has less risk of truncation and easier to type if the need arises. Only if the account is super important will I bump up the entropy.
It’s far more often that I need mixed casing, or special characters. Length limits happen maybe 1 out of 10 times, not enough for me to change my defaults.
Even worse when it does work to login, but you're logged out on the next navigation because the login cookie does not support passwords longer than 16 chars (don't ask me how this is possible)
Bank of America comes to mind...
type=password + maxlength = disaster
Forgive my ignorance as I've never set up anything like this, but how do you then deal with the potential for extremely long passwords? Can that be detrimental on the back end?
It's reasonable to put measures in place so users can't transmit excessively large amounts of data where they are not expected, login forms being one example.
But there is a lot of wiggle room between maxlength=8 and allowing people to upload the source code of DOOM as their password.
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 don't store the 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.
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.
Password length isn't a problem because you never store the actual password in the database.
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
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
My services have three password rules:
1. the password has to be a certain length (8 or more)
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
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
I have a one-letter "[email protected]" email address and I often have issues with services saying "your password contains your email address". Basically means that my passwords cannot contain letter "a". Find it amusing since I have to replace all "a"'s in my 1password-generated 30-char password with something else.
Should put a minimum length on that rule
Webauthn can replace passwords if people finally accept that passwords can't be made into a good solution.
length("passwordpassword") > 15chars
Not sure about the specifics, but the concept looks reasonable.
What does without complexity even mean?
You don't have to meet the requirements of "a mix of letters, numbers, and special characters."
e.g. a 15-character password without complexity could be all lowercase letters.
e.g. a 15-character password without complexity could be all lowercase letters.
Beat me to it :D
[deleted]
It’s terrible wording, but I assume a passphrase, e.g.
> john has many feats but this particular one is spectacular
> john has many feats but this particular one is spectacular
The terms are not well defined enough in the dialog to know whether this is reasonable or not.
i like this, it’s very user-friendly; allows for both “battery correct horse staple”-style passwords and the randomly generated mess you’d get from a password manager
So ... 123456789012345 or passwordpassword
Or, you could just do what NIST recommends and not impose arbitrary password requirements beyond being 8+ characters and and not appearing in a list of known passwords. https://pages.nist.gov/800-63-3/sp800-63b.html#:~:text=no%20....
I really like the compromise of using zxcvbn to calculate entropy and offer suggestions on how to make stronger passwords as a good compromise. It won't be tripped by password managers generating passwords, and it'll be usable enough for real humans that they won't mind dealing with it.
We use zxcvbn and allowing only good passwords (score >2) is already too hard for many people to figure out a usable password.
This is too real. I wrote a java port of it to use with my SaaS, Nbvcxz. I had attended many in-person and webinar training sessions with our customers, and inevitability you'd have someone who was just unable to get past creating a password that didn't contain their name and birthday, or part of their email address, or the company name...all of which are added to a personalized exclusion dictionary.
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.
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.
Did you consider adding password suggestions? I do this. Generate 10 passwords and make them clickable.
This is the only thing that makes sense. Asking the user to create a password that is complex enough is just a waste of their time.
I would not go so far and say this is the only thing that makes sense. It made sense for my service, because it runs in a context where people can trust me to not copy the password suggestion and store the clear text.
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.
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.
I know I COULD, but my PO is telling me that they saw this on a really popular website and that we should really be doing it that way because the big guys obviously know what's right.
This is what we do at my place of work. Minimum 8 characters - and the password cannot appear as one of the top compromised passwords in HIBP list.
Except in France - CNIL does not agree with NIST. :(
Except in France - CNIL does not agree with NIST. :(
I'm not sure exactly in what they don't agree with NIST in your mind but CNIL recommends minimal entropy rather than minimum length (without "special characters, numbers, etc" restrictions), also recommends checking against a blacklist and above all that recommend using other methods than password authentication when possible. That doesn't strike me as incompatible with NIST recommendations.
Key risk with passwords is reuse across differently vulnerable websites/apps. Password complexity enforcement does nothing to address this risk. For many users it may actually push them to reuse passwords.
Unless your rules force them not to. E.g. "you are only allowed to use unicode whitespace characters and ancient greek letters". Guarantueed to not be used anywhere else.
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.
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.
I finally got fed up with the special characters, digits and case bullshit and made myself this.
https://addons.mozilla.org/en-US/firefox/addon/jp-hash/
https://www.kylheku.com/cgit/jp-hash/about/
https://addons.mozilla.org/en-US/firefox/addon/jp-hash/
https://www.kylheku.com/cgit/jp-hash/about/
This takes me to a dropbox page where I have to sign in.
There’s an X in the top right.
(If you hadn’t posted I would’ve backed out of it too.)
(If you hadn’t posted I would’ve backed out of it too.)
On desktop just press the X and on mobile click Not Now
OP is sharing a screenshot of a login form.
On mobile, at least, Dropbox inserts their own interstitial page to download the app instead of immediately displaying the file, which may be what the parent comment is referring to. At a quick glance it might look like a login wall since you're obviously expecting to see an image instead.
FYI, Github does the same thing too.
I really like this way to ensure password robustness, users with password generators are not blocked by some absurd rules.
I really like this way to ensure password robustness, users with password generators are not blocked by some absurd rules.
The only requirement for passwords these days should be that the entropy is high enough and that the password is not in password leak databases. Anything other than that is simply asking users to reuse passwords across sites or annoying people who use password managers that generate too complex passwords.
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.
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.
On the note of entropy, and checking for a breach at the same time... I have been toying with the idea of adding hibp api support to Nbvcxz which would give an integrated solution for ensuring you aren’t storing weak or already leaked passwords (hashed) in your system...but I was hesitant because adding network calls to a library like this can be a security risk.
I may just try and implement and see what it looks like.
I may just try and implement and see what it looks like.
> but I was hesitant because adding network calls to a library like this can be a security risk
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?
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?
Understood, but imo any network calls at all are a something to raise eyebrows with a library like this, and I figured that would raise the barrier of adoption. I was thinking if people wanted to do that they would integrate both nbvcxz and HIBP api themselves...
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".
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".
The only requirement for passwords these days should be that the entropy is high enough [...]
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.
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.
The right thing to do is to assume the attacker knows the character set used for a brute force attack so they can limit the search space accordingly, and use that in your entropy calculation.
You'd also want to do things like look for patterns, because tools like John the ripper absolutely do more than random guessing.
You'd also want to do things like look for patterns, because tools like John the ripper absolutely do more than random guessing.
That was my point, you don't really know the character set used, you only know the characters used. It is reasonable to assume that the characters of »cat« were drawn from the set of lowercase letters but for all you know they could have been drawn from a set of three letters and to err on the side of caution you probably should assume it was indeed drawn from the set of three letters. And of course, password crackers can do a lot more than simply brute force through all possible character sequences, which just underlines my point that calculating the entropy or maybe better the resistance against password crackers is non-trivial. But as others have pointed out, there are are existing implementations like zxcvbn and you do not have to solve this problem from scratch.
Yup, I understand the problem space. I wrote one of the ports for zxcvbn and have been maintaining it for the past ~7 years.
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.
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 was on a major UK broadband suppliers website yesterday, password required to be <= 16 characters ...
/jackie-chan-meme
... doh, that's 17 characters
/jackie-chan-meme
... doh, that's 17 characters