Sites with dumb password rules(github.com)
github.com
Sites with dumb password rules
https://github.com/dumb-password-rules/dumb-password-rules
326 comments
I've lost count of how many times I had to "fix" broken sites by editing the javascript manually client side.
The maximum length of text in a field could be (and should be if it's actually necessary) an attribute in the HTML. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
What's your process of editing client side JS? Is there some method to capture scripts before they load so you can make your modifications?
In chrome, if you open the dev tools and go to Sources, you can see the files and modify them right there. If they are executed once at page load time, you need to set a breakpoint and refresh, edit, save, then press Run again.
Often times when I'm fixing sites, there's an actual error thrown in the console, which will take you to the line in the code where the exception happens (or any line along the stack trace), so you can set a breakpoint right there and fix the code. If the code is minified, there's also a button near the bottom of the code section to reformat it./
The only tricky part is if the JS is embedded inside the html, then Chrome doesn't let you edit it, but often then, it's in the global Window namespace, so you can literally override the function by typing in the console. Hope this helps!
As a hands-on example, you can open hn.js on this page, add `alert('hello')` to vote(){}, save, then try upvoting my comment :)
Often times when I'm fixing sites, there's an actual error thrown in the console, which will take you to the line in the code where the exception happens (or any line along the stack trace), so you can set a breakpoint right there and fix the code. If the code is minified, there's also a button near the bottom of the code section to reformat it./
The only tricky part is if the JS is embedded inside the html, then Chrome doesn't let you edit it, but often then, it's in the global Window namespace, so you can literally override the function by typing in the console. Hope this helps!
As a hands-on example, you can open hn.js on this page, add `alert('hello')` to vote(){}, save, then try upvoting my comment :)
You can run a new script that overrides any reachable function. Right from the console.
Say there is a function named ‘verifyPassword()’ you can simply run ‘verifyPassword=function(pass){ return true }’
Say there is a function named ‘verifyPassword()’ you can simply run ‘verifyPassword=function(pass){ return true }’
chrome does have overrides in developer tools - it supports persistent script editation.
https://developers.google.com/web/updates/2018/01/devtools#o...
Ah, thanks for the link, that's super neat! I was looking for making changes that would persist across page loads or browser restarts, and this is exactly that. It's a shame that it's not a feature in Firefox's dev tools (not yet anyways)
Mine is my workplace. They mandate changing the password every 3 months (so most people use post-its) and their password change utility accepts special characters for input but mingles them when actually stores them (the backend uses AD for authentication, but the password change goes through a custom web form).
And of course then logging in doesn't work at all. It took me days to figure out what was going on.
I have to avoid symbols and special characters when I have to renew my password there from now (luckily with pass it's just another command line switch).
And of course then logging in doesn't work at all. It took me days to figure out what was going on.
I have to avoid symbols and special characters when I have to renew my password there from now (luckily with pass it's just another command line switch).
Just use an ultra secure password schema such as September2019@$ . They obviously want you to use it considering that policy
I once tried Password1 scheme as a form of protestation for a client corp account I'd connect every 2 month or so but that had a 1 month rotation policy (so that I actually had to change my password every time I connected to them). It worked... Obviously I changed it to something else but regularly tried if still worked.
The big payout was when we had an on-site formation from a third party and the teacher needed to create a corp account. He miserably failed to validate various secure combinations against policy (like 16+ length 5 words xkdc style). Being the only consultant associated, I just yelled across the room full of in-house IT guys "Just try Password1 it's gonna make it!"
Obviously it worked out ¯\_(ツ)_/¯
PS: Oh and nobody reported me for this "incident" I still don't know if it's out of shame, dumbness or because nobody wanted to actually get to work to change that policy.
The big payout was when we had an on-site formation from a third party and the teacher needed to create a corp account. He miserably failed to validate various secure combinations against policy (like 16+ length 5 words xkdc style). Being the only consultant associated, I just yelled across the room full of in-house IT guys "Just try Password1 it's gonna make it!"
Obviously it worked out ¯\_(ツ)_/¯
PS: Oh and nobody reported me for this "incident" I still don't know if it's out of shame, dumbness or because nobody wanted to actually get to work to change that policy.
Oh yeah. Yeeeears ago, I was contracting for a telecom provider, and as a contractor, the process for getting logins to all the stuff I needed access to was onerous in some cases, nonexistent in others. So the employee who was sponsoring my presence in the building just said I could share his login. "The password is Apr1999!, if you happen to be the first one to log in when it expires, just change it to May1999! and so on, alright?"
It satisfied the uppercase, lowercase, number, symbol, and non-reuse criteria perfectly, while having precisely zero security.
Come to find out, something like a dozen different contractors were all sharing this one guy's login. He was the only reason anything got done in the whole region. The "system", such as it was, worked, but it made a mockery of corporate IT.
A few months into the project, that employee gave his notice and quit. Went to work for the competitor across the street; we'd bump into each other at the diner and stuff. But they couldn't just turn off his login -- his manager understood that all the contractors were using it, so they just left it active, and whoever got the expiry prompt would dutifully update the password every month...
It satisfied the uppercase, lowercase, number, symbol, and non-reuse criteria perfectly, while having precisely zero security.
Come to find out, something like a dozen different contractors were all sharing this one guy's login. He was the only reason anything got done in the whole region. The "system", such as it was, worked, but it made a mockery of corporate IT.
A few months into the project, that employee gave his notice and quit. Went to work for the competitor across the street; we'd bump into each other at the diner and stuff. But they couldn't just turn off his login -- his manager understood that all the contractors were using it, so they just left it active, and whoever got the expiry prompt would dutifully update the password every month...
If you make the system secure but unusable, the users will find a way to make it usable but insecure.
But changing the password every month doesn’t make it any more secure.
Passwords don’t really have an expiration date if they are secure (as in long enough and not reused) in the first place.
Passwords don’t really have an expiration date if they are secure (as in long enough and not reused) in the first place.
>but it made a mockery of corporate IT.
Isn't corporate IT recursively defined as being a mockery of corporate IT?
Isn't corporate IT recursively defined as being a mockery of corporate IT?
> as a form of protestation
Me too. It's like a game: choose the easiest possible password given constraints.. My theory is: for each set of constraints there is always exactly one such password. Hard to prove, I know.
Me too. It's like a game: choose the easiest possible password given constraints.. My theory is: for each set of constraints there is always exactly one such password. Hard to prove, I know.
Why would you get reported?
I don’t know someone from this client could have called my boss and said that I was a disrespectful dipshit that compromised their reputation in front of a third party...
But I guess they also knew my boss would have laughed at them and said he support me. I have a great boss. I really can’t complain on that level.
But I guess they also knew my boss would have laughed at them and said he support me. I have a great boss. I really can’t complain on that level.
I use very secure passwords (32 character random) basically everywhere except for work because they are so aggressive about password rotation.
Work gets the equivalent of Banana1!, Banana2@, Banana3#....Banana9(, Banana1! (upper case, lower case, number, symbol, can't be previous 8 passwords) because we rotate constantly.
Work gets the equivalent of Banana1!, Banana2@, Banana3#....Banana9(, Banana1! (upper case, lower case, number, symbol, can't be previous 8 passwords) because we rotate constantly.
Same here. Using a base password and adding the month in which I changed it the last time. If somebody feels happy about that, so be it.
That seems like a system where the “password” `rm -Rf /` would...run.
DROP TABLE
Not a password but slightly related, had to use western union to send money for a friend last year and on their credit card page someone tried to be smart and failed, it checked for they key pressed to ensure only numbers but didn’t account for the fact that not everyone use QWERTY (on a French azerty you need to use shift to use the top row of numbers, without shift it’s accented letters and the like).
I kept thinking there was probably something in their tos pushing the blame on me if any issue happened since I had to bypass their security feature.
I kept thinking there was probably something in their tos pushing the blame on me if any issue happened since I had to bypass their security feature.
Just bad code where they took the actual key codes being pressed not the characters they map into, which made the code reject anything with shift pressed.
I regularly run into situations where my password on sign up is silently truncated (without being given a maximum char count) so at login I can’t just edit a field, I’ve got to guess how many characters of my password they actually use or reset it (and still guess).
The time entry system at my job disables the later days of the week (anything after tomorrow's day of the week) in the week when you try to enter your time the next week, even if you've manually selected the previous week. So on Monday Wednesday forward is disabled. So I need to run jQuery('input').removeAttr('disabled') in the console!
I had this issue with Air New Zealand - one of their sites was truncating the password field on one of the pages, but not on another page. Took me ages to figure out why sometimes I couldn't log in.
Auckland Transport does the same thing
E*Trade’s mobile app does the same thing, but you can’t edit the password field since it’s a native app. Website allows longer passwords than what their mobile app allows and just locked you out of your account after a few correct password entires. To make things worse, support tells you it’s due to your network.
My local bank made a new website that does something similar, where the input for creating the password is truncated to be shorter than the field for entering the password. I forget the exact length but it is pretty short, like 10 characters. It took me forever to figure out why I couldn't log in to their new site.
[deleted]
Early versions of Bitlocker on Windows suffered from this.
I'll let you figure out how I know this :|
I'll let you figure out how I know this :|
I'm almost positive LINE does this with their 20 char limit too.
The only reason I can figure why anyone would do that is if at some point the password in the db was a varchar with a length and then they changed it but didn't change the frontend - big isolated development team problems.
afaik, passwords are not stored in databases. Only the hash of the password is stored. The database doesn't know and doesn't care about the length of the password.
A human has to do the work to turn the password string into a hash and store the hash. At some point in time (or now, even), it's probable that they ... didn't hash the password.
Either the password or the hash of the password is stored, which it is depends on the age of the application, the skills of the developers and probably other factors that do not readily spring to mind.
However I am quite certain that not every solution has hashes of the password stored because every now and then I still get sites that tell me the password I chose has disallowed characters in it.
However I am quite certain that not every solution has hashes of the password stored because every now and then I still get sites that tell me the password I chose has disallowed characters in it.
Hi, I made this.
It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad.
It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.
So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.
It seems like most of you are as enraged as I am about some of these password rules. They just flat out make me mad.
It's not much, but I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.
So, if you find any particularly egregious offenders, do your part and submit a PR. It may actually make a difference.
> I've actually had one company reach out to me after making it on the list and they made their password rules less dumb.
That’s a huge win!
My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don’t usually include “do not paste” in the listed requirements, so this doesn’t really work with your screenshot approach. Ideas?
That’s a huge win!
My pet peeve is sites that block pasting, say, from a password manager (glaring at you, Costco signup page). Those sites don’t usually include “do not paste” in the listed requirements, so this doesn’t really work with your screenshot approach. Ideas?
> My pet peeve is sites that block pasting
Firefox: about:config: dom.event.clipboardevents.enabled, toggle to "false" (default is true).
Result: websites can no longer block you from pasting things into form fields on your own browser on your own computer.
Firefox: about:config: dom.event.clipboardevents.enabled, toggle to "false" (default is true).
Result: websites can no longer block you from pasting things into form fields on your own browser on your own computer.
There is a Firefox extension called Don’t Fuck With Paste which let’s you toggle this per-website with a button.
In what situation would you want this enabled?
When a website is fucking with your ability to copy or paste!
I used to set this permanently, but discovered if you use facebook making status updates and comments become broken due to how fb seems to scan your input to apply styling.
But I often have to toggle it off temporarily to bypass the stupid copy/paste blocks.
But I often have to toggle it off temporarily to bypass the stupid copy/paste blocks.
You can create a bookmarklet to disable paste event listeners.
note for firefox users, that this will break copy/paste in google docs
I tried this, but this breaks some web apps where I need clipboardevents to work (e.g. Google Docs). There needs to be a more granular option for this somehow, possibly in a plugin.
Then you'll discover sites that consume your password by Javascript in the onKeyPressed event handler.
so you can paste with the menu? Because I guess they would just catch the keyboard events?
I think they must block catching Ctrl+C/V/X, because those key combos work for me with that flag.
Nope. Don’t think so.
Dunno about educating all those idiots, but for mitigating their idiocy I have a two-line AutoHotKey script (this is in Windows) called FakePaste mapped to ctrl-shift-alt-V. All it does is read from the clipboard and pretend to type those characters, one per 100ms if I recall correctly, or maybe I set it to 200ms. AHK can mimic keypresses at the system level, so it defeats whatever silly shit anyone tries to do in the browser. It's as if you were typing. If you're on Windows and willing to install AutoHotKey I can give you the script.
I'm a big fan of this browser extension "Don't fuck with Paste" https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
I've noticed a number of sites now are doing something that interferes with the password manager (Lastpass in this case). Common problems are either that autofill doesn't work (even explicitly clicking autofill does nothing), or they put a button in the username/password field that's exactly where Lastpass puts its button, so it's impossible to click.
I don't get it -- don't the sites want users to use more secure passwords? That should mean encourage password managers, unless they imagine I'm gonna remember a 32 character random unique password for every website?
I don't get it -- don't the sites want users to use more secure passwords? That should mean encourage password managers, unless they imagine I'm gonna remember a 32 character random unique password for every website?
I contacted my credit union about this and they responded their auditors required it for security compliance reasons. Thankfully after many months they "fixed" it by removing the restrictions... but made the login a multipage ordeal which still breaks my pw manager.
Just to add. I'm Not sure if it's just a policy thing, but when a windows rdp session locks, pasting the password is blocked. Manually typing the password becomes a pain.
I really hope anything that blocks pasting in forms has good reason, an not just psuedo security
> My pet peeve is sites that block pasting
Safari users can install StopTheMadness which disables this and other such nonsense.
Safari users can install StopTheMadness which disables this and other such nonsense.
You should have an honor roll for companies which were bad but fixed their dumb password rules.
I wish ING in Australia was as secure as your example site. Here we get a javascript number pad and a 4 digit numeric password. Hello 1998
Hi, this needs a checklist or ability to see severity of infractions because some of these edge cases are very dumb to elevate alongside the truly broken flows
Yeah, compare the very first two on there right now. The first is "can't use '%'". The next one has 7 very specific rules.
That one smacks of character encoding issues or badly sanitised inputs.
This is a good idea. I’ll think about how to handle it.
That's awesome. This is a great idea, if there's any way to get sites to fix their stupid rules, it's by shaming them :)
Amazon mails to change your password every three months. How does one come up new passwords every three months?
Using a password manager. Most include functionality to re-generate/rotate a record's password in-place, and then copy the new one to the clipboard (or even directly into the web page).
I use 1Password and even though I agree that forced password rotation is dumb, this makes it painless.
I use 1Password and even though I agree that forced password rotation is dumb, this makes it painless.
I am actually appalled and baffled at American Express not applying case sensitivity. Like, what the actual.
I literally couldn't apply for an American Express card about 15 years ago because my (ISP) email address was too long. I wonder why they chose to restrict it rather than go with the standard email max length; they had to put effort in to pointlessly restrict new signups. Odd.
Back in '99 or so, there was a company called Halibut Stuff selling T-shirts at Defcon (and presumably other events) that included a free email redirect service with purchase of a shirt.
So I got a shirt that said "[email protected]"
Not too much later, I ended up working in software validation, and I broke so many login forms with that perfectly-valid address, I lost count.
Since then, Halibut Stuff dissolved and the forwarding service is long gone. If some HN reader wanted to set up a Mailinator-like service that generates absurd-yet-RFC-compliant email addresses for such testing, I think there might be a market.
So I got a shirt that said "[email protected]"
Not too much later, I ended up working in software validation, and I broke so many login forms with that perfectly-valid address, I lost count.
Since then, Halibut Stuff dissolved and the forwarding service is long gone. If some HN reader wanted to set up a Mailinator-like service that generates absurd-yet-RFC-compliant email addresses for such testing, I think there might be a market.
Like anyone would actually use such a testing service.
Until a few years ago it was fairly commonplace for sites to reject my perfectly valid addresses just because they had more than one period (i.e., a subdomain) or in one case, ended in the .us TLD.
Until a few years ago it was fairly commonplace for sites to reject my perfectly valid addresses just because they had more than one period (i.e., a subdomain) or in one case, ended in the .us TLD.
Likely because of integration with legacy tech.
I remember when their max password length was 8 characters. It blew my mind that a (effectively) bank had such terrible requirements. At least they fixed that
The 8-character limit was probably because the web site was just a fancy front-end to some decades-old mainframe system. You'd be surprised the age of technology and software big banks rely on. They tend not to fuck with a working system, partly because their reputation and millions or billions of dollars are on the line, but also because no manager wants to be the reason for a critical outage.
There are so many compliance reviewers who get stuck on our "high entropy" approach to passwords when doing security reviews for a sale. "But what about special characters? Mix of upper & lower? etc." I'm very grateful to NIST for https://pages.nist.gov/800-63-3/sp800-63b.html and Sophos for their summary here https://nakedsecurity.sophos.com/2016/08/18/nists-new-passwo... (both of which make fine references when requested). As a side point, I'm now entirely unsurprised by the near-weekly big-corp breaches that get announced given the caliber of the compliance people we encounter.
Ironically, if you ever get an IT account on a NIST campus, they dont follow their own rules. It's "at least one capital letter, one digit and one symbol, and can't contain any English words of 3 letters or more" or similar. And they make you change it every 6 months. Pain in the neck.
As much as I'm grateful for the improvements made to NIST and the slow trickledown to other compliance frameworks (HITRUST, etc) there are still major compliance frameworks that require password changes and mix of upper/lower/special characters including PCI (see https://pciguru.wordpress.com/2019/03/11/the-new-nist-passwo... for a more detailed discussion). It's frustrating that while 80% of the time compliance frameworks reinforce security, 20% of the time compliance frameworks actively prevent better security.
I've been getting pretty annoyed by the "Security Questions" some sites have you setup.
A client I work with gave me a vendor account, with a preset list of security questions I had to answer. One was 'What was the color of your first car?'. I typed in 'Red', and got an error that the entry needed to be at least 4 characters long.
A client I work with gave me a vendor account, with a preset list of security questions I had to answer. One was 'What was the color of your first car?'. I typed in 'Red', and got an error that the entry needed to be at least 4 characters long.
The name of my childhood pet was "FVrE9msW9DLBAx".
Makes for fun conversations on the phone.
It is better to pick names with actual words. An attacker can otherwise say that the answer is just a bunch of random characters, and there is a risk that a naïve customer support representative may accept it.
In order to deploy this successfully, the attacker would have to know that you used a random string...how would they know this without having access to the string itself?
Not necessarily - they're given multiple "tries" so they can just pick "a bunch of random letters" as one of their first few choices in hopes that they guessed correctly.
Ugh...
Mine was "78 nails and 7 Greek philosophers", which works a little better on the phone. ;-)
That's really the best use for security questions: have fun with customer support.
"Pet's name?"
"ICUP."
"Can you ........ Oh."
"Pet's name?"
"ICUP."
"Can you ........ Oh."
Another nasty experience I had recently: On an account I hadn't used for ages and for unexplicable reasons was not covered by my pw manager they did not present me the security question for password reset. Instead they gave me the whole list and said answer the security question you had chosen at registration. Of course I didn't remember, the list had no option I would always pick.
I've ran into this a few times and so now I always store the question in my password manager too.
That actually makes it slightly more acceptable to use security questions I guess.
Normal users will probably try different question-answer combinations until they get a hit, submitting a lot of personal data in the process
Yes - Apple are one of the worst. I truthfully could not answer most of their questions, some of which seemed very US-centric. For example, I've never owned my car and do I really have a favourite colour?
What bugs me about security questions is when they give you questions that have subjective or time-varying answers. "What's your favorite X" is a terrible security question for me, I am not likely to remember an answer I chose 2-3 years ago
United is the worst offender with security questions. Not only are the questions preset, but the answers are a dropdown too! There’s also no way to input a “custom answer,” so you’re stuck with absurdly low entropy “security questions.”
As far as my credit card company knows, the name of my kindergarten teacher is Danny DeVito and I met my wife in the upper atmosphere of Venus.
Haha, that's terrible.
I get annoyed by the security questions in a different way. If they are all based on "firsts" such as first school, first address, first friend, etc, I'm screwed. I moved 23 times growing up and went to 9 different schools. I have no idea what my "first" things were.
I get annoyed by the security questions in a different way. If they are all based on "firsts" such as first school, first address, first friend, etc, I'm screwed. I moved 23 times growing up and went to 9 different schools. I have no idea what my "first" things were.
I have a credit card that requires you to answer a security question just to make a payment, with an existing linked account. I can't fathom what scenario they think they are protecting against here.
Perhaps they're protecting themselves against you making an on time payment and not accruing any interest. ;)
My former bank sends an SMS OTP every time I make a transaction. Not TOTP support. If it's the same security question, password managers can easily fill it out, no?
This SMS annoyance is a major reason why I left them.
This SMS annoyance is a major reason why I left them.
Maybe they expected you to label it as a Google Pixel color: e.g. `really red`.
Yeah, I've seen a similar restriction on mother's maiden name =/
My mother (and many many women in this modern world) _goes by her maiden name_ so it's not exactly a secret.
I always (politely) point this out when I'm dealing with a human at an institution who asks me for this information as part of the security process.
I always (politely) point this out when I'm dealing with a human at an institution who asks me for this information as part of the security process.
Even when a woman does change her last name after marriage, believing that her maiden name is somehow secret information in this day and age seems about as secure as "what street did you grow up on?", or "what was your high school mascot?". The root of the problem is believing that security questions are a good practice to begin with.
On top of that we are living in the era of social media, where these type of information are no longer hard to find.
Yep, plus all the people who don't live in a culture where "maiden name" implies anything.
Good point.
For a nice counterexample, check out login.gov, the unified authentication service that seems to be replacing individual approaches at many US government sites.
Their password requirements: “It must be at least 12 characters long and not be a commonly used password. That’s it!” [1]
Oh, and login.gov allows pasting from a password manager.
[1]: https://login.gov/help/creating-an-account/how-to-create-an-...
Their password requirements: “It must be at least 12 characters long and not be a commonly used password. That’s it!” [1]
Oh, and login.gov allows pasting from a password manager.
[1]: https://login.gov/help/creating-an-account/how-to-create-an-...
They're following the US government's own (very good) standard: NIST 800-63.
It specifically bans most of these dumb practices listed in the OP.
No 'security questions', no password hints, no special character or other composition rules, no short character limits, no routine expiration dates.
The main idea is: let the user make the password they want, require two factor, and run their password against a list of known compromised passwords to make sure they don't pick something stupid.
It specifically bans most of these dumb practices listed in the OP.
No 'security questions', no password hints, no special character or other composition rules, no short character limits, no routine expiration dates.
The main idea is: let the user make the password they want, require two factor, and run their password against a list of known compromised passwords to make sure they don't pick something stupid.
Ooh, also FIDO keys. Nice. This is 100% the best option listed (possibly not for actual US government employees, your employer issued token might arguably be better) because FIDO is strongly incompetence resistant, and when combined with the use of login.gov over each site having a separate login that's a huge security win.
- FIDO keys don't have identity. Each FIDO key is different of course, mine can't be used in place of yours. But an activist can use the same key for their Facebook "Smash Exxon" page where they are never shown without mask and also for their login.gov ID where they sort out government affairs using their true full name and address, yet even if the government and Facebook and Exxon all work together they can't tell those are the same person from the credentials.
- FIDO keys don't move secrets. There is usually a "secret" random value baked inside your key to make it unique, but everything sent back and forth is public, so if it leaks that's no big deal. login.gov could literally paint all the FIDO credentials it has on the side of the Capitol building for everybody to see and it would make no difference to security.
- FIDO keys don't have identity. Each FIDO key is different of course, mine can't be used in place of yours. But an activist can use the same key for their Facebook "Smash Exxon" page where they are never shown without mask and also for their login.gov ID where they sort out government affairs using their true full name and address, yet even if the government and Facebook and Exxon all work together they can't tell those are the same person from the credentials.
- FIDO keys don't move secrets. There is usually a "secret" random value baked inside your key to make it unique, but everything sent back and forth is public, so if it leaks that's no big deal. login.gov could literally paint all the FIDO credentials it has on the side of the Capitol building for everybody to see and it would make no difference to security.
For more good .gov stuff, check out the dotgov Mac terminal theme https://github.com/lysyi3m/macos-terminal-themes/blob/master...
I don't like that at all. 12 chars is much too long. And what does "not be a commonly used password" mean?
It means it's shouldn't be on this list[1] for example, because it makes brute force guessing from a dictionary of common passwords easy.
- Of all the password databases breached in 2016, "123456" made up 4% of them [1].
[1] https://en.wikipedia.org/wiki/List_of_the_most_common_passwo...
- Of all the password databases breached in 2016, "123456" made up 4% of them [1].
[1] https://en.wikipedia.org/wiki/List_of_the_most_common_passwo...
What a fascinating rabbit hole. Most of these obviously come from users not giving even a single fuck, but what about #9, "trustno1"? For some reason I suspect those guys are thinking they're really clever and no1 will ever guess that.
I'm also kind of surprised not to find some variation of "sesame" on here.
I'm also kind of surprised not to find some variation of "sesame" on here.
123456 is not even a word. “Common passwords” is meaningless. I can’t even think of a “common” 12+ char password.
Chase Bank:
Must not include more than 2 identical characters (for example: 111 or aaa)
Must not include more than 2 consecutive characters (for example: 123 or abc)
First, they apparently mean repeating and not identical characters.
But more importantly, perfectly random character strings frequently contain repeating and consecutive characters, so this rule must reduce the entropy of passwords.
------
Edit - Just simulated this for 10 million 12-character passwords randomly generated from the 90 characters Chase allows.
Turns out the repeating and consecutive rules would invalidate about 0.3% of purely random passwords.
A negligible reduction in entropy is certainly more than offset by preventing passwords like aBc123456789.
Must not include more than 2 identical characters (for example: 111 or aaa)
Must not include more than 2 consecutive characters (for example: 123 or abc)
First, they apparently mean repeating and not identical characters.
But more importantly, perfectly random character strings frequently contain repeating and consecutive characters, so this rule must reduce the entropy of passwords.
------
Edit - Just simulated this for 10 million 12-character passwords randomly generated from the 90 characters Chase allows.
Turns out the repeating and consecutive rules would invalidate about 0.3% of purely random passwords.
A negligible reduction in entropy is certainly more than offset by preventing passwords like aBc123456789.
When you did your simulation did you use lowercase and uppercase letters? I ask because chase.com doesn't differentiate between the two. Seriously. If you have a chase account, try changing the case of some of your letters and you'll still login successfully.
Using uppercase and lowercase letters and the symbols Chase supports, 0.25% of random 12-character passwords would be rejected by the repeating and consecutive rules.
Re-running the simulation to assume case-insensitivity results in 0.44% of random 12-character passwords failing these rules (assuming Chase treats aBc as an invalid sequence).
Note that Facebook also accepts variations on a password, for example if you have caps lock on, or if the mobile device automatically capitalizes the first character, or if an additional character is added at the end of the password.
More discussion on Facebook's policy here -> https://news.ycombinator.com/item?id=13426544
Re-running the simulation to assume case-insensitivity results in 0.44% of random 12-character passwords failing these rules (assuming Chase treats aBc as an invalid sequence).
Note that Facebook also accepts variations on a password, for example if you have caps lock on, or if the mobile device automatically capitalizes the first character, or if an additional character is added at the end of the password.
More discussion on Facebook's policy here -> https://news.ycombinator.com/item?id=13426544
This is often so you can enter your password in a touch tone phone, since there are no caps there.
It's a naive approach, and also honestly, in my personal experience with banking software, these rules are not selected through some careful secops research, but are usually arbitrary picked to sound smart to managers and be easy enough to implement by devs. Bad passwords should be addressed specifically, because having "ijk" or "777" somewhere in you 40chars long random sequence is not really a vulnerability. On the other there are many bad passwords that are not made of sequential numbers, say "qwerty" or "asdfghjkl" or "sunshine". There're so many data dumps these days that it's easy to create a blacklist of popular passwords and block it, without giving headaches to users with password managers just because their safe random password happens to have a wrong number of these or those chars.
Does it reduce the entropy of passwords in practice or just in theory? It could be that in practice if you let users repeat characters they will do so more often than random chance would allow for, thus making their passwords predictable to some degree. Thus, prohibiting that practice would increase the randomness of passwords actually getting used.
My 16-char alphanum generated password for Chase had an equivalent of "rST" in it. I can never remember which password modification I ended up with, and "can't choose the same password as your previous 4" gets real old real fast.
doesn't any rule decrease password entropy?
It's ironic that allowing low-entropy passwords (for example, one-character) can actually increase the available entropy.
For example, if you set a minimum password length of six characters, an attacker doesn't even need to bother going through all of the 1 through 5 character combinations.
The flip side of the coin is that, obviously, allowing low-entropy passwords will inevitably mean that some users will actually use them, which means that their passwords actually have decreased entropy.
For example, if you set a minimum password length of six characters, an attacker doesn't even need to bother going through all of the 1 through 5 character combinations.
The flip side of the coin is that, obviously, allowing low-entropy passwords will inevitably mean that some users will actually use them, which means that their passwords actually have decreased entropy.
> can actually increase the available entropy
Well, the theoretical entropy, but not the empirical.
You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy" and makes things less secure (after all, your random password generator might just randomly have generated "12345678"), but in practice quite obviously it makes things more secure.
Well, the theoretical entropy, but not the empirical.
You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy" and makes things less secure (after all, your random password generator might just randomly have generated "12345678"), but in practice quite obviously it makes things more secure.
Agreed.
> Well, the theoretical entropy, but not the empirical.
Agreed.
There are profound implications of that statement of that statement when applied to other problems, because we mutually accept the theory as correct, but only theoretically, when we know it has significant limitations in the real world.
> You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy"
Obviously. And yet, equally obviously, removing those from the rounds because they're preemptively banned reduces the actual number of test hashes we have to run to brute force, and introducing a rule means that we can also eliminate huge swathes of potential keyspace.
So, the obvious is not necessarily so obvious after all. This gets more and more interesting the deeper the rabbit hole goes.
What if we have extremely random data -- perhaps even raw binary -- but it happens to have a sequence of three arbitrary integers, which is in violation of the rules, and therefore we can eliminate all such passwords from our test cases? That's a potentially huge chunk of entropy.
> Well, the theoretical entropy, but not the empirical.
Agreed.
There are profound implications of that statement of that statement when applied to other problems, because we mutually accept the theory as correct, but only theoretically, when we know it has significant limitations in the real world.
> You could argue that ruling out "12345678" and "password" and "Password!" reduces the "available entropy"
Obviously. And yet, equally obviously, removing those from the rounds because they're preemptively banned reduces the actual number of test hashes we have to run to brute force, and introducing a rule means that we can also eliminate huge swathes of potential keyspace.
So, the obvious is not necessarily so obvious after all. This gets more and more interesting the deeper the rabbit hole goes.
What if we have extremely random data -- perhaps even raw binary -- but it happens to have a sequence of three arbitrary integers, which is in violation of the rules, and therefore we can eliminate all such passwords from our test cases? That's a potentially huge chunk of entropy.
I have actually thought about this a lot and done some napkin calculations: using a set of about 93 characters the search space for 5 character passwords is about 7 gigabytes; combining all the possible passwords <= length 4 is only about 74 megabytes in comparison. I think that the entropy loss is insignificant.
Indeed, and the factor is about 95, which is close to 93, and that is not a coincidence, when you think about it.
If you want to crack my password, and I tell you that my password is L characters long, by skipping all passwords of length < L you've only saved about 1/N of the required effort (where N is the size of the character set you choose from).
In other words, telling someone the length of your password does not help them very much.
If you want to crack my password, and I tell you that my password is L characters long, by skipping all passwords of length < L you've only saved about 1/N of the required effort (where N is the size of the character set you choose from).
In other words, telling someone the length of your password does not help them very much.
The impact of this really depends on the cost of calculating hashes, which varies based on hash algorithm. It might even be the difference between being able to ever find the hash or not. Being able to constrain the search space is the ONLY tool you can count on.
If you say "No passwords less than eight characters", most passwords will be clustered around 9 or 10 characters. That's human nature. This means that your entire search space is only the character set in that very limited set of strings. And, if you're limiting that character set, and also it's expensive for you to hash (ie scrypt or bcrypt with lots of rounds), then not having to go through the first 1-8 set will save you a tremendous amount of time...
If you say "No passwords less than eight characters", most passwords will be clustered around 9 or 10 characters. That's human nature. This means that your entire search space is only the character set in that very limited set of strings. And, if you're limiting that character set, and also it's expensive for you to hash (ie scrypt or bcrypt with lots of rounds), then not having to go through the first 1-8 set will save you a tremendous amount of time...
> then not having to go through the first 1-8 set will save you a tremendous amount of time...
Well, not quite. If you allow say capital letters and numbers only (36 different characters), and you have to go through all 9 and 10 character passwords, skipping the first set of 1 to 8 character passwords saves you less than 0.1% of the work, if my rough back-of-the-envelope calculation is correct.
That was precisely what my statement was about - longer passwords are just so much better.
(Note that this assumes that the cost of computing the hash is by and large independent of the length of the password, which is a very good assumption for the lengths we are talking about here).
Well, not quite. If you allow say capital letters and numbers only (36 different characters), and you have to go through all 9 and 10 character passwords, skipping the first set of 1 to 8 character passwords saves you less than 0.1% of the work, if my rough back-of-the-envelope calculation is correct.
That was precisely what my statement was about - longer passwords are just so much better.
(Note that this assumes that the cost of computing the hash is by and large independent of the length of the password, which is a very good assumption for the lengths we are talking about here).
The maximum possible entropy is in a sense sampled by users various passwords. The sampling can be biased, so rules can technically eliminate such biases and lead to higher effective entropy. Furthermore, there is a benefit in forcing the user to not share the same password across multiple websites which can be achieved by imposing extra (or ideally mutually exclusive) password rules. Of course I am just playing devils advocate here.
What's hell is not being told /at login/ what the unusual restrictions are.
Yes, but no, but yes. What I believe the original poster was hinting at and I believe you, witty little you, also understood was the rule severely inhibits the entropic nature that you would rather see.
Something like minimum characters pushes towards a more ideal entropic state for example, rather than limiting the ideal entropic state.
Something like minimum characters pushes towards a more ideal entropic state for example, rather than limiting the ideal entropic state.
Want to DDOS somebody? Try their password incorrectly three times.
Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.
Stupidest password rule ever. Rate limiting after 3 mis-attempts is understandable. That rate limit doesn't need to exceed 1m with passwords over 14 characters.
I don't even think rate limiting after 3 mis-attempts makes sense. I regularly can't remember my password and might need 6 attempts. Nobody's going to guess your password after 300 attempts, so make the limit 30 and you're safe.
While it doesn't really justify locking accounts, there's an approach to guessing passwords where you have a large list of accounts available and try each with top 10 passwords, then top 100. Given enough accounts, some will work. (Password spraying) so even limiting to 30 tries wouldn't stop it.
Ideally you'd detect one source trying logging into multiple accounts with many failures instead.
Ideally you'd detect one source trying logging into multiple accounts with many failures instead.
This is basically why I started using a password manager.
Screw up 1 too many times and you end up in a cycle where you never will remember your password and you'll try the last 3 or 4 you used, eventually locking yourself out again.
Screw up 1 too many times and you end up in a cycle where you never will remember your password and you'll try the last 3 or 4 you used, eventually locking yourself out again.
The primary reason you should use a password manager is that you should consider that password insecure at the place you use it. Any sysadmin at a company can grab your password and try it everywhere else you have accounts.
Why not use a password manager?
My mortgage's website does this rate limiting... by setting a cookie client side.
I just close and reopen an incognito window and voila, no more rate limiting.
I just close and reopen an incognito window and voila, no more rate limiting.
Yup. Long ago, a high level person was fired. After that someone hit everybody's passwords enough to trigger account locks. It could only be fixed at the console.
I accidentally DDOS'ed myself creating my ssa.gov account and now I'm pretty sure I've got to visit a physical SSA office with identification to create the account.
Honestly, I'm past caring about upper length limits, however stupid they are.
What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.
What really pisses me off is not validating on it, so my too-long password is happily accepted, and I have no idea what it is except that it's some prefix of the one I saved.
Silent truncation. This becomes worse when you realize that a companies web login vs mobile have different hard lengths, in this case it was mint.com. They allowed 16 online and 32 mobile, after letting them know they thankfully made it consistent at 32. Which isn’t perfect but it’s far better than most
I've encountered other weird bugs in mint too. On one site they wouldn't let me enter an email address as a username for a website which used your email as your username. Editing the DOM to remove that front-end validation worked, which was also disappointing, but at least it worked.
Oh! Related gripe - registration and login having different validation, removing it in the frontend 'fixing' it...
I've been able to supply my 'too long' password more than a few times that way, and it's transpired that actually it clearly was all stored on registration.
So on a whim I've tried it when registration's failed, and sure enough it's been stored, and then not validated on login.
It's so easy to do better, just don't do it in the frontend!
I've been able to supply my 'too long' password more than a few times that way, and it's transpired that actually it clearly was all stored on registration.
So on a whim I've tried it when registration's failed, and sure enough it's been stored, and then not validated on login.
It's so easy to do better, just don't do it in the frontend!
Reasonable upper limits don't bother me all that much. If you're going to store a hashed password, you want to choose an expensive hash algorithm (It's been a while since I looked at this, but I don't think bcrypt is standard anymore?) and that complexity is meant to be computationally ridiculous, and probably scales with length.
Good security dictates a minimum length, and practical avoidance of your login form being a denial of service... well, that dictates a maximum length too. It can be quite long, but you generally should not allow bot makers to instruct your login handler to actually hash the entire declaration of independence, repeatedly.
(Edit: I should clarify, by "reasonable" I'm talking like, 200 character or more reasonable. These sites with 20 character maximums make me cringe. Also the computational complexity can be mitigated in other ways, like sensible rate limiting.)
Good security dictates a minimum length, and practical avoidance of your login form being a denial of service... well, that dictates a maximum length too. It can be quite long, but you generally should not allow bot makers to instruct your login handler to actually hash the entire declaration of independence, repeatedly.
(Edit: I should clarify, by "reasonable" I'm talking like, 200 character or more reasonable. These sites with 20 character maximums make me cringe. Also the computational complexity can be mitigated in other ways, like sensible rate limiting.)
> that complexity is meant to be computationally ridiculous, and probably scales with length.
I'd think that there is an initial hashing (which is quite fast), and then iterated computations on that fixed length, with a more or less predictable (and high) CPU and memory intensity - in other words, not (significantly) scaling with length.
I'd think that there is an initial hashing (which is quite fast), and then iterated computations on that fixed length, with a more or less predictable (and high) CPU and memory intensity - in other words, not (significantly) scaling with length.
Why not have one round of hashing in the browser?
That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.
That way the input to your server-side hash function is fixed-length, whether the users password is 20 characters or 20 billion, and DOS attackers are only hurting their own computers.
Wouldn't that just turn the attacker's problem into brute forcing the client-side hash? Might be a problem if the client-side hash has a lower total complexity than the longer original password. I dunno though; just pondering out loud, I'm by no means an expert on this stuff.
But the hash would necessarily preserve the entropy of the password. A 256 bit hash is about as strong as a 32 character random password. According to the password haystack, that would take "6.22 hundred trillion trillion trillion trillion centuries" to crack in an online attack.
If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.
If you choose to attack such a scheme by guessing the hash, then all passwords have that same level of entropy, even if the password that generated the hash is only 8 characters.
Yes, obviously.
So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.
So you choose something like 1024 bits as the length of the client hash. The client hash doesn't even need to be any good, even xor-ing blocks might work. It just needs to preserve a lot of entropy.
Bcrypt is still widely used. It’s just advised to increase your work factor to something at least 12 if not 14+. And every year or two bump it up another level.
So:
`val factor = currentYear - YEAR_APP_WRITTEN + 14`?
bycrypt has a limit of 72 bytes (not characters) and possibly less depending on the specific implementation. Theoretically this could limit you to only 18 characters if your password is utf-8 encoded emoji (4 bytes per character).
This can be worked around by the server hashing the password using a fast hash before passing it to bcrypt but this risks reducing the security of the password.
This can be worked around by the server hashing the password using a fast hash before passing it to bcrypt but this risks reducing the security of the password.
No, this doesn't reduce the security of the password at all, if your first fast hash is well distributed.
Eg use the first 72 bytes of SHA256, if you like overkill.
Eg use the first 72 bytes of SHA256, if you like overkill.
I've switched almost entirely to diceware passwords and the too-long thing is a major PITA.
You'd think if they're fine with truncating the password on account creation, they'd also be fine with truncating it on login as well.
schwab.com used to do exactly this about 8 years ago.
I think they simultaneously ignored all case but that could have been an unrelated site, memory is hazy.
I think they simultaneously ignored all case but that could have been an unrelated site, memory is hazy.
> BMO Bank of Montreal
> Password must be exactly 6 characters long and no special character.
I had an account with these guys. Their security is just ridiculous. 6 alphanumeric characters is all they'll accept! I mean, some of the entries on the list are bad, but this is a friggin major national bank in Canada with a piss-poor password requirement.
This list needs to be segregated into different categories so we can laugh at the different ways sites are dumb.
EDIT: OK, they apparently updated their password rules to make them more sane (but didn't, like, tell any of their clients to go update their passwords?). Apparently their previous system was worse than I thought - it actually mapped your alphabetic password onto a number pad, so if you set the password AbcDEf then you could login with 111222. Guess this is what happens when you try to drag a telephone-banking system into the online banking era...
> Password must be exactly 6 characters long and no special character.
I had an account with these guys. Their security is just ridiculous. 6 alphanumeric characters is all they'll accept! I mean, some of the entries on the list are bad, but this is a friggin major national bank in Canada with a piss-poor password requirement.
This list needs to be segregated into different categories so we can laugh at the different ways sites are dumb.
EDIT: OK, they apparently updated their password rules to make them more sane (but didn't, like, tell any of their clients to go update their passwords?). Apparently their previous system was worse than I thought - it actually mapped your alphabetic password onto a number pad, so if you set the password AbcDEf then you could login with 111222. Guess this is what happens when you try to drag a telephone-banking system into the online banking era...
Tangerine still does this. I’m honestly surprised I don’t hear stories about account compromises with them. Likely a ticking timebomb though.
United MileagePlus:
They ONLY offer multiple choice questions for the security questions!
Of course, for some questions none of the answers are correct (favourite artist etc). On the other hand it would be dumb to choose a correct answer that someone else could find out and then take over your account.
Some of the questions have as few as 12 valid answers - e.g. "in which month...". Also in the select box where you pick your answer the months are sorted in a nonsensical order.
I ended up picking questions with more possible answers and choosing a random answer and putting it into my password safe.
Infuriating!
They ONLY offer multiple choice questions for the security questions!
Of course, for some questions none of the answers are correct (favourite artist etc). On the other hand it would be dumb to choose a correct answer that someone else could find out and then take over your account.
Some of the questions have as few as 12 valid answers - e.g. "in which month...". Also in the select box where you pick your answer the months are sorted in a nonsensical order.
I ended up picking questions with more possible answers and choosing a random answer and putting it into my password safe.
Infuriating!
Why does everyone (including the big tech companies) pretend that security questions are secure and should even be mandatory?
It's mind-boggling to me.
It's mind-boggling to me.
The other day I called my insurance to reset my online password and couldn't remember the answers to any of the security questions (I shop around every year so I never had to call them since I registered my account with them).
The person on the phone then just asked me a basic question about the policy, which I got right since I had the policy in front of me, and was then happy to change my password.
Fantastic... not.
The person on the phone then just asked me a basic question about the policy, which I got right since I had the policy in front of me, and was then happy to change my password.
Fantastic... not.
I realise it's not ideal, but it's an open question West you'd like them to do instead? Do you want them to refuse you service completely, for example?
If they are happy to ignore my answers to the security questions and go with other questions instead then they should scrap the security questions altogether. Otherwise, yes, they should refuse me service because the point is to use the security questions to establish whether I am who I am claiming to be.
MFA. Security questions are easily socially engineered, especially when you need to choose from a list. What city was I born? One of the easiest things to find out about a person.
The most annoying rule that Microsoft and Nintendo use everywhere: Your password cannot contain your email address
If you say it like that it may make sense, however the email address that I often use (especially if you have to use exotic text entering device) is [email protected].
End result: I'm banned to use the letter a in my password... how smart! It drives me really crazy.
If you say it like that it may make sense, however the email address that I often use (especially if you have to use exotic text entering device) is [email protected].
End result: I'm banned to use the letter a in my password... how smart! It drives me really crazy.
Does your email server automatically proxy [email protected] to you?
If it does, you can easily work around that limitation by signing up with [email protected]
I try to do that for any sites that let me, both for ease of indexing, and if my leaked email ever gets found in a data breach, I know which source it came from.
If it does, you can easily work around that limitation by signing up with [email protected]
I try to do that for any sites that let me, both for ease of indexing, and if my leaked email ever gets found in a data breach, I know which source it came from.
>[email protected]
For when XXX is just not kinky enough for you.
For when XXX is just not kinky enough for you.
The most hilarious rules I've encountered were for a large, well known US hospital:
* Password must be EXACTLY 8 characters long
* Password must start with a letter
* You must use exactly 3/4 of the following: upper case, lower case, numbers, one of three special characters
* Password cannot "resemble" username or past password
* Password must be EXACTLY 8 characters long
* Password must start with a letter
* You must use exactly 3/4 of the following: upper case, lower case, numbers, one of three special characters
* Password cannot "resemble" username or past password
Sounds like they were using z/OS or RACF [1] mainframe as a backend. Oof.
Unfortunately, it's not that uncommon. I've done security consulting work at a few major F500 companies that were using this and had those same password rules. At one of them, it got to the point where almost every security review meeting had to start with "yes yes we already know how bad the password are, don't bring it up, let's talk about something else".
1: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...
Unfortunately, it's not that uncommon. I've done security consulting work at a few major F500 companies that were using this and had those same password rules. At one of them, it got to the point where almost every security review meeting had to start with "yes yes we already know how bad the password are, don't bring it up, let's talk about something else".
1: https://www.ibm.com/support/knowledgecenter/en/SSLTBW_2.1.0/...
Still no excuse. They need to create a custom encoding that works with their backend that allows more flexibility is password choice. It is not that tough of a problem.
> They need to create a custom encoding...
IBM already has solutions for secure passwords of variable length. Outdated systems may have stored passwords as plaintext with symbol limitations, but modern RACF can hash passwords, encrypt profiles, and generally take whatever you throw at it and handle it securely. The tech isn't the problem, only the personnel.
IBM already has solutions for secure passwords of variable length. Outdated systems may have stored passwords as plaintext with symbol limitations, but modern RACF can hash passwords, encrypt profiles, and generally take whatever you throw at it and handle it securely. The tech isn't the problem, only the personnel.
I suspect they want to be able to brute-force passwords if they really need to, in the event of a uncooperative or malicious employee, and these rules allow for that.
Nah, they tend to be systems whose original infrastructure was written pre-internet and had 3 or 4 (or more) decades of bolt-ons laid on top. Password security wasn't nearly as much of an issue, but now the same system that had been designed for employee use now is used by customers and is exposed to the web. Kind of like taking a lock on a diary meant to prevent casual perusal by a sibling and puting it on a bank vault because you put the diary in the vault.
Um... if "they" are system administrators, they do not need to brute-force password. They can just change it to whatever they want.
Why would you ever need that? If you have administrator access, just perform whatever the local equivalent of `su` is.
The "password must be exactly 8 characters" rule screams AS/400.
I worked on a VMS system that used 4. It was originally meant to be a PIN entered over the phone, then the internet came along and that interface was exposed to the web. But it's okay, after a few years they upgraded to 6.
"Password cannot "resemble" username or past password" So they're storing passwords in plaintext somewhere then? Otherwise how would they know?
Past passwords can be tested against past hashes.
Not resemblance though surely, only an exact match.
The interesting thing about some of these is that you can instantly spot instances where they are storing the password in clear text.
For instance, case-insensitive passwords.
EDIT: I guess they could be converting to lowercase (or uppercase) every time before hashing, as multiple people pointed out. If that's the case though... fine, let's pick one of the first instances in that site (not mentioning by name).
Why can't it have spaces? Hashes don't care about this. Smells awfully like some string manipulation going on.
Why is it limited to 20 characters? Odds are that they are using VARCHAR(20) or variants. Hashes also don't care about this.
None of this is proof, but it smells really bad.
For instance, case-insensitive passwords.
EDIT: I guess they could be converting to lowercase (or uppercase) every time before hashing, as multiple people pointed out. If that's the case though... fine, let's pick one of the first instances in that site (not mentioning by name).
Why can't it have spaces? Hashes don't care about this. Smells awfully like some string manipulation going on.
Why is it limited to 20 characters? Odds are that they are using VARCHAR(20) or variants. Hashes also don't care about this.
None of this is proof, but it smells really bad.
Not necessarily. They could run str.lower() on the password input before hashing and saving the hash. Then to verify the password, you just always run str.lower() on the input before calculating the hash.
You are right. But then it boggles my mind even more that one would go through the extra effort.
Why? I've done it before. This was an in-house program with little in the way of security implications. Forcing the case on the password greatly cut down the number of problems.
Since then I have seen a better solution: Try the password, if it fails try it with the case flipped. If that works it's a caps-lock error, they know the password, accept it.
Since then I have seen a better solution: Try the password, if it fails try it with the case flipped. If that works it's a caps-lock error, they know the password, accept it.
I haven't checked lately, but I understood that Facebook passwords are case-insensitive.
They're not case insensitive, but they do allow for some casing mistakes.
Flipped case (caps lock) or first character case is wrong (mobile input field) were both allowed. Not sure about now. The article I found about it was from 2014.
Flipped case (caps lock) or first character case is wrong (mobile input field) were both allowed. Not sure about now. The article I found about it was from 2014.
That seems bad, like philosophically it feels like a password and only that exact password should work. But rationally I can't see too much of a problem with this.
No, not case-insensitive. They are case-sensitive. Atleast in 2012 Facebook accepted PassWord1 & pASSwORD1 (Case Reversed) passwords.
Stackoverflow Meta Question here:
https://webapps.stackexchange.com/questions/26301/facebook-a...
My Question (the reason why I know):
https://stackoverflow.com/questions/10718236/how-to-alter-th...
Stackoverflow Meta Question here:
https://webapps.stackexchange.com/questions/26301/facebook-a...
My Question (the reason why I know):
https://stackoverflow.com/questions/10718236/how-to-alter-th...
IIRC Wells Fargo passwords used to be /partially/ insensitive. Like, just the first half was to_lower.
They could be doing argon2(lowercase(password)). But you're right, it's unlikely that they're doing the wrong thing in the right way.
You can't be sure, they could lowercase all passwords (so during registration and after logging in) after they are entered.
"For instance, case-insensitive passwords."
"Why can't it have spaces?"
They don't want to deal with angry customers who are "definitely entering the correct password but it's not letting me in".
They don't want to deal with angry customers who are "definitely entering the correct password but it's not letting me in".
The one that actually tells you they store plaintext passwords is when it can't be close to previous passwords.
You can also implement that by just bruteforcing the previous hash with variants of the new password. IIRC Windows since 2000 implement these kinds of checks in exactly this way.
They are some ingenious ways to make that judgement without storing plaintext passwords.
But you are right, that none of those companies do that.
But you are right, that none of those companies do that.
Most of these are dumb rules, but a few really makes you feel like something smelly is going on in the underlying code. Like the first one that specifically restrict %, my head started screaming “sql injection somewhere”
Or just an inability to deal with character encoding.
Where I work they use RSA 2fa keys. I have the app on my phone. You would receive a link in the work email, and by clicking it, it would add the token to the RSA app and give you the 2fa keys every 30 seconds.
After a few months, I bought a new phone so I had to get a new link (I thought). But even the IT guys are saying: Nah man that's too hard. Just use the same link you received months ago.
It worked. There is no time-out on those links!!!!. A link we receive in a plain-text email!!! Some of our inboxes are shared / have a PA attached.
But nooooo, this is not a security problem AT ALL... :-(
After a few months, I bought a new phone so I had to get a new link (I thought). But even the IT guys are saying: Nah man that's too hard. Just use the same link you received months ago.
It worked. There is no time-out on those links!!!!. A link we receive in a plain-text email!!! Some of our inboxes are shared / have a PA attached.
But nooooo, this is not a security problem AT ALL... :-(
Not surprised to see Sparkasse (German Bank) here, their password rules are horrible, they cap it with 5 chars which is insane.
I hope if someone gets hacked they will be able to sue the them because of their archaic security practices.
p.s. would like to use this opportunity to also complain about their non-english English dashboard, god I hate it.
I hope if someone gets hacked they will be able to sue the them because of their archaic security practices.
p.s. would like to use this opportunity to also complain about their non-english English dashboard, god I hate it.
If only they were the only ones! Consorsbank (BNP Paribas) also has a limit of 5 chars, and comdirect even has a limit of 5 decimal digits. The IT security incompetence in banks in .de is just insane.
> comdirect even has a limit of 5 decimal digits
Hm, sure? My comdirect account uses a 6 digits pin. Never tried to use more than that. But 6 were still horrible enough when looking at the fact, that SEPA transfers of up to 30 Euros don't require entry of a TAN. A feature, which can't be disabled. Hate comdirect for that move.
EDIT: feature, not option. :)
Hm, sure? My comdirect account uses a 6 digits pin. Never tried to use more than that. But 6 were still horrible enough when looking at the fact, that SEPA transfers of up to 30 Euros don't require entry of a TAN. A feature, which can't be disabled. Hate comdirect for that move.
EDIT: feature, not option. :)
Oh, oops, yes, you are right, it's 6 digits ... not that that really makes a difference, though ;-) (And yes, I tried, you can't use longer or non-digits ...)
And, yes, the forced TAN-less transfers is why I am closing down my accounts. That is, they forcing thid disfeature on me, and their impertinent reaction when I rejected their bullshit justification (essentially they calling me rude and therefore refusing any further conversation because I pointed out that "many customers like this feature" is not a reason to force it and the risk that comes with it on customers who don't like it).
And, yes, the forced TAN-less transfers is why I am closing down my accounts. That is, they forcing thid disfeature on me, and their impertinent reaction when I rejected their bullshit justification (essentially they calling me rude and therefore refusing any further conversation because I pointed out that "many customers like this feature" is not a reason to force it and the risk that comes with it on customers who don't like it).
DKB (another German bank) has the same 5 digits rule...
They finally changed it to between 8 and 38 characters.
Which is clearly better, except ... what kind of incompetence hides behind that upper limit? Is their hashing function incapable of processing more than 38 bytes? Or is someone storing passwords in plain text?
Westpac, one of the largest banks in Australia have a 6 letter password requirement. No more. No less. Requires at least one number and no symbols allowed.
Clearly not an IT focused organisation! The were also offered the .com version of their name for $1m AUD and turned it down which I found amazing for a $100bn organisation.
Clearly not an IT focused organisation! The were also offered the .com version of their name for $1m AUD and turned it down which I found amazing for a $100bn organisation.
I remember this from when I was in Australia! I also remember that you couldn't type in your password, you had to use the website and click virtual keyboard keys.
I use westpac here in New Zealand and their website works really well, normal password, normal inputs, nice looking UI... but IIRC they are technically different companys.
I use westpac here in New Zealand and their website works really well, normal password, normal inputs, nice looking UI... but IIRC they are technically different companys.
I can beat that, actually. The administrator passwords on the catalog system at my local university library in the 90s were required to be exactly 5 uppercase letters, and were hashed with crypt() and stored in an unshadowed file.
My pet peeve: sites that require all-numeric PINs when logging in online. Numbers make sense when you're punching buttons on a phone or ATM, but elsewhere, why limit my entropy to 10 possible characters instead of at least 62?
And there's a special place in hell for sites that require entering numeric PINs by clicking on a "keypad" of randomly generated button locations.
And there's a special place in hell for sites that require entering numeric PINs by clicking on a "keypad" of randomly generated button locations.
> Admiral: Restrict the inclusion of a % character.
I guess the password is being used in a query template? Seems like a very bad idea.
I guess the password is being used in a query template? Seems like a very bad idea.
TreasuryDirect, an official US government site for buying and selling Treasury securities, makes users enter their passwords via a clickable on-screen keyboard. The passwords are not case-sensitive either.
FYI, you can just open up the html inspector and delete the readonly = "readonly" on the input box and suddenly you can use a password manager to fill it in.
Which, I'm pretty sure is technically a felony.
Strange to see a .gov.uk site on there ( https://github.com/dumb-password-rules/dumb-password-rules#h... ) as they have excellent guidance on this https://design-system.service.gov.uk/patterns/passwords/
Is this your first time encountering a government saying one thing then doing another? :D
You can always trust State Bank of India to pick the worst possible process and phrase. WTF is hacking characters ?
> WTF is hacking characters
Basically anything a scripting programming language might use as a comment or sigil. Putting 'we are probably calling exec() on your password' into writing though is a boneheaded move.
Basically anything a scripting programming language might use as a comment or sigil. Putting 'we are probably calling exec() on your password' into writing though is a boneheaded move.
Maybe they run a password report and someone had <script>alert("lol");</script> as a password. Managment freaked out and demanded someone fix the hack.
Presumably something like “;<>. Characters that get used in XSS/SQLI. Totally the wrong defense, of course
Please don't put anything in here that might harm us, because we're inserting these characters directly into our totally secure password database, which also happens to contain all of your biometrics. We use firewalls and lots of red tape, so it's all very safe.
[deleted]
For a steady stream of these, check out https://twitter.com/PWTooStrong
My fortune 100 company has the following internal account password rules:
-Must be 8 characters
-Must be all lowercase
-Must contain $ or !
-Must contain letters and numbers
I'm not joking.
-Must be 8 characters
-Must be all lowercase
-Must contain $ or !
-Must contain letters and numbers
I'm not joking.
We need another repo for stupid 2FA rules. Looking at you United Airlines.
Microsoft OWA for business. It automatically sends a 2FA message to your phone whenever a session times out, whether you asked for it or not.
Because it's totally not a bad thing to train users to accept unknown 2FA requests in the middle of the night because "it's probably just my work computer refreshing itself".
Because it's totally not a bad thing to train users to accept unknown 2FA requests in the middle of the night because "it's probably just my work computer refreshing itself".
Add Chase to that list. They don’t offer TOTP and are vulnerable to cellular account takeover attacks.
My credit union has the same issue (no TOTP, only options for second-factor are email and phone call, with no way to disallow one or the other).
I didn't even bother enabling online banking with my local bank because of this. None of the local banks have a damn clue so I just use them as if it's 1995; ATM and IRL. I only use them for cashing checks though so it's no big deal.
E-Trade has a decent security story though. 2FA w/hw token, and they refund all ATM fees on the checking account so it's decent for general banking in addition to trading.
E-Trade has a decent security story though. 2FA w/hw token, and they refund all ATM fees on the checking account so it's decent for general banking in addition to trading.
Many complaints are that non-ASCII characters (which all but one European languages have natively) are not allowed. While I agree that allowing them would be good for password security past experience has made me paranoid. Not all systems handle non-ASCII the same way, so when you change browsers or they upgrade their system your password might no longer work. Today Unicode is used a lot so it gets better, but it's still not universal. The worst I have seen is a system that silently removed all non-ASCII characters when entering passwords.
Another case where I tend to use the plain English alphabet for passwords/passphrases is with disk encryption. I have a German keyboard, but before Linux is up and running, I'm never sure whether the system assumes an English or German keyboard layout. And since I can't see which characters I type, the safe bet is to only use the plain alphabet and make the phrase a little longer.
That might have been an excuse in 1999, but I'm not sure it's still a valid excuse in 2019. This is why you should use utf8.
I recently debugged through a case where this was a problem with non-ASCII usernames. Through an upgrade of an underlying docker image the default system encoding changed from UTF-8 to ISO-8859-1 and nobody noticed. This even passed QA since they always create new users in their test cases and the bug only occurred if you wanted to log in as a user with a non-ASCII character that was created with an old version of the service.
That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default.
Long story short, encoding problems can be tricky, even in 2019.
That doesn't mean the fault was not on us. We should've made the encoding explicit rather than relying on the system default.
Long story short, encoding problems can be tricky, even in 2019.
For an implementer it is a bad excuse in 2019.
For a user setting a password it is unfortunately still reality in 2019, even if probability to hit such a system is slowly decreasing.
For a user setting a password it is unfortunately still reality in 2019, even if probability to hit such a system is slowly decreasing.
Or if they need to connect from a foreign computer.
Lots of them also ban space.
The University of Notre Dame requires that your password be 16 characters long. But only if you are new or are changing your password. Evidently shorter passwords are just fine for the people who have been there for a while.
Of course, we have to use these passwords in quite a few circumstances where a password manager cannot be used (logging on to random terminals, etc.), and then there is the multiple random 2FA checks, in buildings that have no cell signal...
Of course, we have to use these passwords in quite a few circumstances where a password manager cannot be used (logging on to random terminals, etc.), and then there is the multiple random 2FA checks, in buildings that have no cell signal...
Another 'dumb' feature with PayPal (at least a couple of years ago) is that it had a 30 character limit on password length. Except it won't tell you that when you create an account, instead it just truncates your password. So when you try to log in with your 32 character password (which it will happily let you enter) you'll just get a wrong password error.
This is good work. It's amazing how the pressure has to come from outside to get any traction.
I just realized that I set up this Twitter account 10 years ago, this month: https://twitter.com/passwordfail
Most sites don't email passwords anymore, so I suppose that's something.
I just realized that I set up this Twitter account 10 years ago, this month: https://twitter.com/passwordfail
Most sites don't email passwords anymore, so I suppose that's something.
It's also frustrating when they change password rules and invalidate existing passwords in the process.
Yesterday I had to go through an inconvenient password reset because my bank no longer allows spaces in passwords. The password input inconspicuously removes spaces after you type them. It took several failed attempts before I realized what was happening.
Yesterday I had to go through an inconvenient password reset because my bank no longer allows spaces in passwords. The password input inconspicuously removes spaces after you type them. It took several failed attempts before I realized what was happening.
I've hit that, also. I finally gave up and did a password reset. In setting the new password I find the new rules precluded the password I was using. Apparently that was enforced by editing the input.
I've also set a password that wasn't accepted by the login box, it explicitly stated there was an invalid character.
I've also set a password that wasn't accepted by the login box, it explicitly stated there was an invalid character.
I like the idea of such "shame list". The question is though, how would you prioritize and incentivize those websites to change?
My quick idea is that it would be good to have a way of reproducing those cases somehow; not sure how though, because registration is something that is difficult to automate, so we'd probably need some browser extension to do this research. Once we could automatically test (or semi-automatically, waiting for a user to verify) whether this is still an issue, we could create a website where one could sort by most popular / annoying / old flaws, maybe also arranged by communities so that changes would happen.
Either way, I appreciate kicking this off. It's definitely a good start. I just wish we could transition from this to actually changing this deliberately, as opposed to just shaming and hoping for organizations to eventually fix their things.
My quick idea is that it would be good to have a way of reproducing those cases somehow; not sure how though, because registration is something that is difficult to automate, so we'd probably need some browser extension to do this research. Once we could automatically test (or semi-automatically, waiting for a user to verify) whether this is still an issue, we could create a website where one could sort by most popular / annoying / old flaws, maybe also arranged by communities so that changes would happen.
Either way, I appreciate kicking this off. It's definitely a good start. I just wish we could transition from this to actually changing this deliberately, as opposed to just shaming and hoping for organizations to eventually fix their things.
I understand that you follow some misguided security guidelines that state that a password must contain special characters and have a length of at least X.
What I don't understand is why sites use a maximum password length. They shouldn't save your password anyway, and only compare the hash, right?
What I don't understand is why sites use a maximum password length. They shouldn't save your password anyway, and only compare the hash, right?
Yeah. It either means that they do, in fact, save your passwords and the column in the database has a fixed length. Or... I dunno... the backend is written in C and they store the password in a `char password[16];` before sending it off to be hashed.
Whatever the reason is, it's pretty darn stupid!
Whatever the reason is, it's pretty darn stupid!
Cost of calculating 10k character hash? IMO above 30 length serves no practical purpose.
To put this in perspective: The cost of calculating a 10k character hash is negligible compared to serving a modestly sized image.
Still, you have a point that allowing arbitrary sized passwords to denial-of-service attacks. Still, a more reasonable limit would be 100 or 256, for example.
Still, you have a point that allowing arbitrary sized passwords to denial-of-service attacks. Still, a more reasonable limit would be 100 or 256, for example.
and no way is 12 a good limit
If that were the case, would the limits be so small? I mean, it's usually like "less than 16 characters" or something. The extra CPU time to raise that limit to, like, 128 or something would be totally insignificant (especially if they're using a key-derivation function after the hash, as they should be).
>Cost of calculating 10k character hash?
Irrelevant compared to the rest of the operations done on the server.
Irrelevant compared to the rest of the operations done on the server.
Other than not annoying users by not allowing their 31 character passphrase.
I thought it was fairly well established in the tech community that something like a sentence you can easily remember is better than a weird sequence of 12-20 letters, special chars, etc. But I very, very rarely see any site ever mention or require it or anything. How come it hasn't taken hold?
I think it’s established in the tech community that you use a password manager, then you don’t have to care how the password looks like or how easy it is to remember.
Passphrases are still easier to transcribe between systems. Which, given password managers' brain-damagedness at archiving and migrating passwords, remains frustratingly necessary.
> Which, given password managers' brain-damagedness at archiving and migrating passwords
What do you mean with that? I don't have a problem archiving passwords in 1Password. When I change it it's automatically stored in the entry as password history. If I retire a login because a site closed but I still want to keep my credentials / details I move it to an "Archive" vault in 1Password.
What do you mean with that? I don't have a problem archiving passwords in 1Password. When I change it it's automatically stored in the entry as password history. If I retire a login because a site closed but I still want to keep my credentials / details I move it to an "Archive" vault in 1Password.
Hm there should be an example of a “right” password rule flow here
Many of these are so nitpicky that it loses credibility
“oh it doesnt let the user know the max character limit is 30 characters uwaaaah”
cases like these should be part of a checklist that shows this is a minor infractions instead of putting them all on the same level of shame
Many of these are so nitpicky that it loses credibility
“oh it doesnt let the user know the max character limit is 30 characters uwaaaah”
cases like these should be part of a checklist that shows this is a minor infractions instead of putting them all on the same level of shame
This is slightly different but webex makes me change my password every 30 days... It's ridiculous...
Similarly misguided policy.
It makes sense to change credentials periodically, but the policy of 30 days for humans doesn't work because the humans aren't realistically going to remember new credentials every 30 days.
If you have Let's Encrypt, the default setup (Certbot) will change the key every time it renews, typically 60 days, but you aren't expected to remember the key it's just data for a machine to store somewhere, so there's no practical problem and it defuses some risks (e.g. bad guys get hold of old backups). So the idea of rotating credentials like this would make sense _if humans weren't expected to remember them_.
It makes sense to change credentials periodically, but the policy of 30 days for humans doesn't work because the humans aren't realistically going to remember new credentials every 30 days.
If you have Let's Encrypt, the default setup (Certbot) will change the key every time it renews, typically 60 days, but you aren't expected to remember the key it's just data for a machine to store somewhere, so there's no practical problem and it defuses some risks (e.g. bad guys get hold of old backups). So the idea of rotating credentials like this would make sense _if humans weren't expected to remember them_.
Passwords, on average, have around 40 bits of entropy (or 0 if they're in any existing list, and some lists are 500M strong) so don't us pass words.
Also, TLS is MITM-able (the CA system is one giant backdoor, CT doesn't prevent MITM attacks) so you're password and authenticated token can be captured and your account can be pwnd.
Don't use pass words. Use mnemonics to derive public/private keys and use authenticated encryption (see lib sodium) or separate signatures and encryption.
Some of my explorations here (work in progress)
https://docs.google.com/presentation/d/1f2k6fsIkDmIS1WyJAT0l...
Also, TLS is MITM-able (the CA system is one giant backdoor, CT doesn't prevent MITM attacks) so you're password and authenticated token can be captured and your account can be pwnd.
Don't use pass words. Use mnemonics to derive public/private keys and use authenticated encryption (see lib sodium) or separate signatures and encryption.
Some of my explorations here (work in progress)
https://docs.google.com/presentation/d/1f2k6fsIkDmIS1WyJAT0l...
These are ramblings by a Coiner. As is usual for a Coiner since you don't really understand what you're talking about we get pages of vaguely related stuff sort of thrown together in the hopes that it covers roughly whatever it is you're claiming this time.
Let's take the "insufficient serial entropy" as one very clear example. That was a Brown M&M and not an actual technical concern, but you haven't understood that at all and just linked it as part of a claim this is "Security Theater".
Several of your links supposedly about "HTTPS snooping by Governments, Employers and Hackers" aren't about HTTPS, or even TLS, or even the Web PKI, but instead unrelated "certificates" of one sort or another than you apparently didn't understand weren't the same thing. For example the Apple Insider article is about Apple's iPhone application signing.
And then your "solution" ends up relying on all the same infrastructure you've wasted slides decrying as subject to MITM, including both HTTPS itself and OS-specific code signing.
Get out of here with that Coiner nonsense.
Let's take the "insufficient serial entropy" as one very clear example. That was a Brown M&M and not an actual technical concern, but you haven't understood that at all and just linked it as part of a claim this is "Security Theater".
Several of your links supposedly about "HTTPS snooping by Governments, Employers and Hackers" aren't about HTTPS, or even TLS, or even the Web PKI, but instead unrelated "certificates" of one sort or another than you apparently didn't understand weren't the same thing. For example the Apple Insider article is about Apple's iPhone application signing.
And then your "solution" ends up relying on all the same infrastructure you've wasted slides decrying as subject to MITM, including both HTTPS itself and OS-specific code signing.
Get out of here with that Coiner nonsense.
> Passwords, on average, have around 40 bits of entropy (or 0 if they're in any existing list, and some lists are 500M strong)
If you choose a password by randomly selecting from a list of 500M passwords, surely it has log_2(500,000,000) ~= 29 bits of entropy?
If you choose a password by randomly selecting from a list of 500M passwords, surely it has log_2(500,000,000) ~= 29 bits of entropy?
From the GitHub issue about BMO:
The original entry didn't even fully capture the stupidity of the BMO password system (which I recognize they have now fixed).
The most egregious part was not that your password had to be only 6 characters. It was that whatever password you chose ended up getting mapped to where those characters were on a telephone keypad. So, for example if your password was passwo, you were also able to login with 727796 or rARsYo or anything else that mapped to the same characters.
I really should have switched banks when I found this out.
The horizontal scrolling makes the quoted part pretty hard to read. If it's still editable, please consider changing that to simple `> ` based quoting.
Edit: Link to the github issue comment mentioned - https://github.com/dumb-password-rules/dumb-password-rules/i...
Edit: Link to the github issue comment mentioned - https://github.com/dumb-password-rules/dumb-password-rules/i...
I made this comment.
Since you're curious: I signed into telebanking and it asked for me to input my password. I didn't ever remember setting a phone password, so I tried punching in the numbers that corresponded to my online banking password. It worked.
Obviously the only way this would work is if they stored the numeric keypad representation of your password instead of your actual password. So I experimented a bit and found password horror.
Since you're curious: I signed into telebanking and it asked for me to input my password. I didn't ever remember setting a phone password, so I tried punching in the numbers that corresponded to my online banking password. It worked.
Obviously the only way this would work is if they stored the numeric keypad representation of your password instead of your actual password. So I experimented a bit and found password horror.
Made a typo that happened to map to the same sequence on a telephone keypad?
From what I remember, their online banking system was built on their legacy telephone banking system.
Any French bank with a single exception: Only digits, maximum 6-8 characters. Can not copy paste or even type in the field, must use a stupid on screen keyboard with randomized sequence of buttons.
Allegedly this protects against key loggers.
Allegedly this protects against key loggers.
I once had to implement ridiculous password rules for the Intuit api. Rules that Intuit themselves didn't use.
My favorite was "Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries)." So I have to search every word that humanity has ever used??
---
Letters [required 1]:a, b, c, d, e, f, g, … x, y, z, A, B, C, D, E, F, G, … X, Y, Z – AND
Numbers [optional 1]: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 – OR
Symbols [optional 1]:~, !, @, #, $, %, ^, &, *, (, ), -, _, =, +, [, {, ], }, \, |. ;, :, ‘, “, ,, ., <, >, /, ?
Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries).
Verify password is not the same as, or a trivial variation of the username.
If Account ID is ‘fred’, then password cannot be ‘fred’ ‘fred1’ 1fred’, ‘fr3d’, etc.
Password check should look for Account ID string in the password
Password system must support mixed case passwords (Password1 should yield a different result than password1)
Passwords will expire no later than one hundred twenty (120) consecutive days after issuance.
Products must accommodate Account ID lockout after 10 consecutive failed password login attempts.
The failed count (if currently under 10) should reset after a successful login
If the 10th consecutive failed attempt is reached, the Account must be locked out for a minimum of 24 hours
After a password expires, the user must select a new password
The password system must remember the previous 5 passwords for each user
The user may not select a new password that was one of the previous 5 passwords for that user
The user may not change their password more than 1 time per hour
---
https://developer.intuit.com/app/developer/qbo/docs/legal-ag...
My favorite was "Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries)." So I have to search every word that humanity has ever used??
---
Letters [required 1]:a, b, c, d, e, f, g, … x, y, z, A, B, C, D, E, F, G, … X, Y, Z – AND
Numbers [optional 1]: 0, 1, 2, 3, 4, 5, 6, 7, 8, and 9 – OR
Symbols [optional 1]:~, !, @, #, $, %, ^, &, *, (, ), -, _, =, +, [, {, ], }, \, |. ;, :, ‘, “, ,, ., <, >, /, ?
Verify password is not contained in standard dictionaries (including foreign, non-English dictionaries).
Verify password is not the same as, or a trivial variation of the username.
If Account ID is ‘fred’, then password cannot be ‘fred’ ‘fred1’ 1fred’, ‘fr3d’, etc.
Password check should look for Account ID string in the password
Password system must support mixed case passwords (Password1 should yield a different result than password1)
Passwords will expire no later than one hundred twenty (120) consecutive days after issuance.
Products must accommodate Account ID lockout after 10 consecutive failed password login attempts.
The failed count (if currently under 10) should reset after a successful login
If the 10th consecutive failed attempt is reached, the Account must be locked out for a minimum of 24 hours
After a password expires, the user must select a new password
The password system must remember the previous 5 passwords for each user
The user may not select a new password that was one of the previous 5 passwords for that user
The user may not change their password more than 1 time per hour
---
https://developer.intuit.com/app/developer/qbo/docs/legal-ag...
I would include there ANY website that imposes a maximum limit on the password length ... And it's not like a reasonable 255 chars or something. I've seen limitations to 8 characters! Why would you do that ?
If you want to have a good system of passwords, you have to let users put what they want? Not a big security risk for these? I understand that too many rules are stupid, but even if it is a minimum of characters and then freedom to choose the character composition that one wants is the best instead of forcing a rare combination.
The only thing I hate from passwords is lenght. Most of the websites don't allow me to do +40 char passwords. I generate everything with 1Password and I have to limit on most websites to under 20 characters.
The only thing I hate from passwords is lenght. Most of the websites don't allow me to do +40 char passwords. I generate everything with 1Password and I have to limit on most websites to under 20 characters.
I really hate it when a site will allow you create a password with more than 20 characters, but then silently truncates it on the server. I wish I could remember an example, but it slips my mind.
So if you ever find yourself having trouble logging in with your 1pwd auto-generated password, try again with the first 20 characters. You just might get in!
So if you ever find yourself having trouble logging in with your 1pwd auto-generated password, try again with the first 20 characters. You just might get in!
I never faced that, but that truncate would be silly: you kill all passwords and customers have to recover it and keeping creating new ones.
I've seen that before (maybe a bank, maybe ADP back in the day). Really horrible UX.
This is great! Definitely therapeutic to be able to name-and-shame frustrating password experiences. Is the goal to actually get these sites to change their dumb rules?
If so, I wonder whether it's worth adding a (politely-worded) summary at the top of the page describing why rules like these are dumb? Then the people responsible for these sites, most of whom are themselves probably not dumb but just mis- or uninformed, can learn from their mistakes.
If so, I wonder whether it's worth adding a (politely-worded) summary at the top of the page describing why rules like these are dumb? Then the people responsible for these sites, most of whom are themselves probably not dumb but just mis- or uninformed, can learn from their mistakes.
With Fidelity, to authenticate yourself when you call in on the phone, you enter your username and password on the keypad. (They've recently also introduced a "voiceprint" method which bypasses that though.) You use asterisk on the keypad for special characters. One hopes they've hashed your password for storage in both its original and DMTF compatible formats. This may or may not be related to their dumb password rules.
The credit union I use has pretty standard password rules (that is: decent by bank standards, i.e. pretty abysmal), but what really takes the cake is that the "Forgot Password" mechanism is driven not by a button or link or what have you, but...
...a checkbox.
Worse, this checkbox is exactly where one would normally expect the "Remember me" checkbox, so if you check it out of habit, you'll end up getting shoved into the password reset flow instead.
...a checkbox.
Worse, this checkbox is exactly where one would normally expect the "Remember me" checkbox, so if you check it out of habit, you'll end up getting shoved into the password reset flow instead.
What bugs me more than anything are sites that refuse to accept the strong passwords generated by modern browsers.
Who does the usability testing on those sites?
Who does the usability testing on those sites?
I wouldn't publicly shame companies that might be regulated by slowing moving policies. Anyone who collects payments (any start-up that wants to stay around for long) is required to follow some form of PCI which currently still has really bad rules.
You can disagree with the rules but if you don't want to get in trouble, you have to follow them until they fix them.
You can disagree with the rules but if you don't want to get in trouble, you have to follow them until they fix them.
See also, https://plaintextoffenders.com/
Natwest has a really annoying password system where you have to enter certain characters of your password.
LLoyd's Has another system where you can create a password you like, and then you have to create another second password that they ask you to take certain characters from (e.g. 1st, 3rd, 9th character), oh, and it's alphanumeric too.
Loads of places do that (both methods). What's wrong with that? It provides (some) protection against keyloggers and means you have to type in fewer characters.
fun fact: amex online banking wont let you use exclamation mark ! but allows question sign ? amex foreign exchange website does exactly the opposite. apple and amex is why my 1 password to rule them all routine got destroyed and now i just trust chrome to generate and remember passwords and rely on my Google account to carry them across devices
It would be nice if there was a HTML standard for specifying password requirement data, like length ranges, valid/invalid characters, character type requirements(3 letters, 1 number, 1 special character), etc, so that password managers/generators could use it to always create a valid secure, valid password for you.
There is. The `pattern` attribute lets you specify a regex for an input field - including password.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Useful idea, but I wouldn't it be exploitable by adversaries as well (eg. knowing those constraints would be helpful for generating dictionary attacks)?
No, because attackers can easily determine the constraints (assuming they are kept "secret") by signing up for an account on their own.
If you're targeting a specific site's database for a dictionary attack, finding out and entering the specific constraints would be minimal effort. And if you're not targeting a specific site, you probably want your dictionary to be as permissive as possible so can potentially match users on all sorts of sites.
good old security by obscurity
I'm a proponent of only 1 simple rule: high min length. Most sites have min length of 8. Double that to 16-20. No max length, no other complicated restrictions regarding characters. This instantly takes care of brute-forcing as a reasonable possibility, and forces good passphrase discipline on the user.
> forces good passphrase discipline on the user.
I definitely don't think it does this. In fact it probably makes most people much more likely to use the same password on every site, since their passwords just became 3-4x harder to remember.
I definitely don't think it does this. In fact it probably makes most people much more likely to use the same password on every site, since their passwords just became 3-4x harder to remember.
Practically all French banks which use a fixed number of digits. Something insane like 6 digits is common. And of course they all insist on using a friggin' on-screen keyboard !
For some reason I feel that the upcoming European payment services directive is only going to make this worse.
For some reason I feel that the upcoming European payment services directive is only going to make this worse.
Amiami has a pretty dumb password system. It even tells you how passwords are "6 to 12 letters and numbers" on the login page.
https://secure.amiami.com/top/member/asp/
https://secure.amiami.com/top/member/asp/
I encountered the MLB.tv one the other day. I think they are a no special characters site.
Sites that go to lengths to block paste should burn. I use a password manager, and copying the pass manually feels so damn 1970s. Or I can try to diddle around in Developer Tools and try to unfoobar the paste.
unfoobaring the paste is usually what I do, in the end it might take longer, but at least I am beating the system.
Why is this even a thing? Is there any reason, historical or otherwise that limits password length? You just have to hash the password—then everything is the same length, right? Am I missing something?
well... unfortunately some sites don't hash.
I remember that once I used the "forgot password" on one, and they emailed me the password. Not a new, random one. My actual password...
When I first created a Cingular account (before they bought and became AT&T), the maximum password length was four (4) characters, because the system had been adapted from one that used PIN codes.
In other news, here's a list of password rules on various sites to save you haxxors the hassle.
Kidding, I hate silly password rules as much as anyone, and these places deserve the public shaming.
Kidding, I hate silly password rules as much as anyone, and these places deserve the public shaming.
I recently was forced to reset a password somewhere, I think it was AT&T prepaid/gophone, where the password rules required that the password begin with a capital letter.
Brilliant.
Brilliant.
Add amazon to the list. They introduced two factor but they don't allow you to paste the one time code, you have to type it. Come on. Why???
Can we have a similar list for sites that do not verify if the email adress is really owned by the user registering it?
Would you allow ascii characters under 32? Or would you considere it a dumb rule to disallow them?
From a security perspective exclusively, it's completely pointless to disallow them.
From a usability perspective, if someone manages to accidentally enter some dodgy control codes, and then can't log in on other devices because they don't know how to enter their password, it may be problematic.
Personally I think if a user chooses to put control codes or emoji or the unicode symbol for 1/2 as a fraction in their password, they're entirely welcome to have that but they shouldn't be surprised that when they want to log in they have to enter the password with that in it.
Ultimately, it depends on the expense of the support request that arises when users screws up and needs to reset their password - if it's too expensive it may be worth excluding the really exotic characters.
From a usability perspective, if someone manages to accidentally enter some dodgy control codes, and then can't log in on other devices because they don't know how to enter their password, it may be problematic.
Personally I think if a user chooses to put control codes or emoji or the unicode symbol for 1/2 as a fraction in their password, they're entirely welcome to have that but they shouldn't be surprised that when they want to log in they have to enter the password with that in it.
Ultimately, it depends on the expense of the support request that arises when users screws up and needs to reset their password - if it's too expensive it may be worth excluding the really exotic characters.
Would love to have a chrome plugin that shows the requirements next to the site login.
These rules would be perfect constraints for brute force attacks
obligatory thread naming good open-source password entropy checkers. I'll start.
zxcvbn: https://github.com/dropbox/zxcvbn
zxcvbn: https://github.com/dropbox/zxcvbn
Dumb password is good because smart hackers can't get into the that unlogic mindset
use an auth provider, like auth0
I signed up for EZPass using a relatively “long” password (20 chars). I then received a letter in the mail about a toll I had to pay, even though I’d had the EZPass at the the time. But, the letter said, I could pay the toll by logging in to their site and using my EZpass credentials. Didn’t use OAuth but I figured it would be OK. I input my username and password using my password manager but it didn’t work. Pretty strange, as I was able to log in to the “main” EZpass site using those same credentials. I tried logging in on the payment site again to no avail. Finally I realized that my password was being truncated by the password input field itself.
The solution was to inspect the page and change the maxlen attribute of the password field.