Rule 1 is that password rules are bullshit, but all of the other rules lead to needing Rule 1: how are you going to explain to a user that their password cannot be their username, or that their password needs more entropy or complexity?
Rule 5 rejects nulls; if your password is your username, you don't have a password.
Meanwhile my organization is getting ready to mandate the use of a password manager that uses bullshit rules to produce analytics to surface at the director/VP level. So it goes. I look forward to automating the GI that's used to produce this GO.
To be honest I think this is a problem that needs to be solved outside of the web. We need to move towards password managers.
Of course, that comes with its own set of issues: Lose access to the password manager = lose access to all your accounts. An attacker gets access to your password manager = they get access to all your accounts.
On the other hand, for users who use a single 6 character word as their password all over the web, that's essentially the same thing. You can far more easily educate someone in picking a very strong passphrase they will never forget, than get them to use different passwords on each website.
I have successfully converted several non-techies in my family to KeepassX [https://www.keepassx.org/], which I also strongly recommend to anyone here. I had to hold hands at first but after explaining how it works and making sure they understand how important it is, over two years, there's never been any issues.
Just spitballing, but it's possible that you could take the given password and derive the hashcat invocation that would generate the password. In the strictest case this is equivalent to computing the Kolmogorov complexity of the password, but there's an easier way: have a list of the X most common rules, and test the password against those. Once you have the rule, you can calculate how many possibilities exist in that search space and do a calculation ala GRC Haystack[1]. If it's the case that the list of rules doesn't have one that matches the password, that's probably good enough anyway.
Here's another problem that isn't discussed very much: error messaging and failure modes.
I use a command line tool to generate passwords, and I use a password database to store them. It has happened to me before that the maximum password length is something disconcertingly small, like 20 characters. I would copy and paste my password, submit, and then failed to be able to login. Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Other times a password that was too long or contained whitespace would fail with a cryptic error message, or would tell me I failed to meet some other password rule that I know I did not fail to meet.
I don't understand how something with so many widely-recognized best practices associated with it can be implemented badly.
The same way anything else well understood can be implemented badly: naïveté, incompetence, ignorant ukaze from on high, "well we had to have something but there wasn't enough time", or some combination thereof.
This is why the first thing I do when I create an account -- no exceptions as long as it's not a throwaway -- is always to log out and log back in.
If there was a problem with password truncation I'll know straight away and I can either figure out what the truncated password should be and switch it to something that isn't truncated or if that's impossible I can create a new account. If I'm unable to create a new account at least I'll know to stay away from them without having done anything important yet.
I read a recent anecdote bout a similar issue. The person had their long password silently truncated to 21 chars on the reset page and 20 chars on the login page. That sounds like a super fun thing to track down as an end user.
(UK mobile network) giffgaff.com does this.
You can enter any length (as far as I can tell) on the "set password" form but the login form will only submit 25 chars.
This means you can successfully set your password to something you can never enter!
I've run into this kind of issue before. I had an 11-character password silently truncated to 10 on signup, then when I typed the full one into the login form it failed to log in.
Woo. Can't remember what clue the system gave me that let me figure out what had happened now.
I ran into one of those... with a bank! Supposed 32-character limit, but the login page truncated at 31 via Javascript (was able to force my way in via using the console). Ever since I usually don't max out the listed length during generation, just in case.
I think it was an account I had with Sony Planetside where the password was lowercased on signup, but not all parts of their site did it....... (e.g. forums, game itself, etc).
Funny thing is this sort of password bug bit me on PayPal. PayPal of all places! Not sure if it was the length or a disallowed character, but no actual validation took place. Would let you "change" it to something and then never allow you login.
> Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Here's an even worse one than truncating the end of long passwords: truncating internal whitespace
The change/reset password dialog for Apple ID does this. If your password is "foo bar baz bam" then it will happily convert it to "foobarbazbam" but not tell you it did so. Then when you go to log into your Apple ID on your phone, you include the whitespace, you try repeatedly and then lock your account (temporarily). Then you do it again...
Some general advice is:
- Don't silently truncate anything (i.e. don't limit the length)
- Don't silently transmute anything (i.e. don't convert to lowercase)
- Don't have a password max length with a limit less than $BIG_NUM chars[1]
- Do give the user feedback rather than silently doing anything.
[1]: You're hashing them anyway right? So the storage doesn't change. Though if you're using something like bcrypt be aware of the max hashed length: https://security.stackexchange.com/questions/39849/does-bcry.... Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
> Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
I wonder why people are so eager to combine different hash algorithms, especially a strong with a weaker one. If this is isn't a well-established anti-pattern, it should become one.[1] Why? Because in some sense it combines the weaknesses of both algorithms.
Assume your password hash is:
h(p) = bcrypt(sha512(p))
Assume in the future somebody generates a sha512() collision with p and q, while bcrypt() holds water:
sha512(p) = sha512(q)
It follows that:
bcrypt(sha512(p)) = bcrypt(sha512(q))
and hence:
h(p) = h(q)
So any collision in sha512() translates directly to h(), bcrypt's strength is unable to protect you from that.
Had you just used bcrypt(), you would not have been affected.
Frankly, this is about collision and not about preimage attacks (the latter being more relevant for password cracking), but the former is usually a first step towards the latter. Also, this example demonstrates that combining a weaker and a stronger hash algorithms usually does not combine their strengths, but their weaknesses.
[1] It is almost like inventing your own crypto primitives, which actually is a well-established anti-pattern.
While the collisions themselves would increase it's not statistically significant to cause an issue in practice. Plus the idea here isn't to increase the strength of the overall construct. It's to ensure that all characters that the user entered have some contribution to the final product.
What I'd consider a much worse issue is considering the following to be the same by silently truncating things:
- some really long password ... that ends with foo
- some really long password ... that ends with bar
- some really long password ... that ends with baz
The only acceptable alternatives when using something like bcrypt are:
- Restrict user passwords to 72 bytes (not chars!)
- Hash with something like SHA-512 prior to passing them to bcrypt.
People are eager to combine different hash algorithms frequently because they desire to hedge against weaknesses in one of the algorithms. Or, in this case, because they want to shore up an existing 'weakness' in one of the algorithms (for bcrypt, its maximum input size).
You are correct that doing this ad-hoc should be an 'anti-pattern'. There are subtle details (see the papers linked above...). However, the idea itself is sound, if handled properly.
One thing to note is that if you manage to get access to just the hashes, they won't have sha512(p), so they wouldn't be able to figure out sha512(q). So while your are correct that there is (technically) a weakness there, it's not one that's actually exploitable.
Can you explain how a collision helps? I mean, there's trivial collisions with the truncation that would be used instead. That doesn't mean that bcrypt(f(x)) is any weaker because there may be some other x' that f(x) = f(x').
> You're hashing them anyway right? So the storage doesn't change
No, but the time spent computing the hash does change and you open yourself to denial of service attacks. Just pick a max password length of like 200, or whatever your hashing algorithm mandates (55 for bcrypt).
Oh yeah! Freedompop actually transformed a space into a "+" (or vice versa). And this is just free internet I set up for my dad. Took us like an hour to figure that one out.
I'm guessing whatever they used as an HTTP client did it for them. It's a fairly common way to encode spaces (the alternative being %20 of course - encoding as "+" looks much cleaner).
Extremely large password sizes can lead to a DDOS attack on the server (due to computation complexity curve). A large size such as 4096 characters is perfect. Don't accept a password that is 10GBs in size. But don't limit to MAX 16 characters either.
I can confirm. I spent days locked out of my Apple account (and all associated devices) because I had spaces in my passwords. After several hours with support, who needed to escalate the issue to tier 2, then engineering, the only thing that fixed it was me briefly trying a simple password -- one without spaces. I'm not sure if the issue was ever fixed, but I don't imagine I'll use spaces in an Apple password again anytime soon.
Wonder what other sins are there. A couple of years ago when iCloud was first a thing, I did a couple of password changes in quick succession. It resulted in me having different login passwords for different iCloud services. It worked for a short time then broke and another reset fixed it all.
Enforced password reset questions. There's a limited set of about 10 questions (trivial stuff like "where were you born?"), and you have to set 3 of them. About half a year ago, I was forced to do this in order to be able to log in again (I'm only occasionally using it for publishing iOS apps). What is this, Hotmail in 2005?
And the questions haven't changed in decades. It's pretty simple to figure out things like "name of high school attended", "street you grew up on", "model of first car", "mother's maiden name", etc for just about anyone who has a social media account.
As my dad pointed out, the answers are passwords. If you restricted passwords to every possible make of car, for example, it would be incredibly weak - too little total entropy in the possible answers.
(Love the name of the high school mascot, by the way!)
> As my dad pointed out, the answers are passwords. If you restricted passwords to every possible make of car, for example, it would be incredibly weak - too little total entropy in the possible answers.
United Airlines does exactly this and it's hilariously insecure. The secret questions are preselected and the answers must be from their set of answers for each. There's only 8-10 choices for each (ex: Favorite music? pop / jazz / classical / etc).
> (Love the name of the high school mascot, by the way!)
There 10 types of people. Those that got that joke and ...
My favorite restaurant in college is a high-end hotel in Johannesburg (actually it's not, and I've never even been to Africa unless you count a week I spent on Tenerife as a child).
I'm siding with vog here. Do not compose hashes¹. You may not think it's relevant that it degrades the security of your site, but nobody knows what consequences it will bring, so how could you know?
Impose your size limitation as a clear password rule. That means, write on your site that passwords must not exceed the 55, 255 or whatever characters, send back an error if the user tries to create a larger password.
1 - And completely avoid weaker hashes in general, it's not like a percent or two increase in CPU usage will have a greater impact on your bottom than having to adapt your software after it's out.
This partially happened to me on NBA League Pass. It was particularly confusing because I wasn't completely locked out. The failure mode was that my password was one character too long, and was truncated. On the login form, the length was restricted by javascript if you typed in the password, but using auto-fill from 1Password bypassed that.
I thought they were locking me out for proxying or something until eventually by luck I noticed what was going on.
I had a fun issue a few months ago with Team City at work. I was setting up a build to upload to our internal Nuget server, but the upload kept failing. I finally discovered (I don't remember how, but it took hours) that our randomly generated Nuget API key included a character that Team City didn't like and it was silently stripping that character from the input field in the build setup.
This just happened to me on the Wii U with my Nintendo ID. I had set a 20 character password some time in the past(probably the limit on whatever webpage I used to sign up) and when I tried to log into my Wii U recently, only 16 characters were available for entry.
I have had that weird truncation happen several times. It is very frustrating, especially for someone who is first learning to make great long passwords, because they've never come across that problem before and now have to debug it.
Recently I had another scenario happen to me: signing up for a job application login, use my password manager to make a password, everything's great. Then when I go to login, "please remove the disallowed symbol (") from the password input before continuing". Needless to say, I could not log in. And they made me wait 24 hours before resetting my password. I was much less keen on applying for jobs there after that.
Hotmail did that my super long password, it freaked me out at first and I had to guess where the cut-off happened because I couldn't find the damn password length.
And don't you absolutely love it when you realize that your password is failing because of a quotation character. It's then that you realize how seriously poor security is at this website that requires capital, lowercase, digits, and special characters in a password limited to 10 characters and doesn't like spaces.
Because unless users are using a password manager, they need to be able to remember them (and anyone using a password manager is going to be generating secure passwords anyway)
The main reason is that, if IT chooses the user passwords, then the users simply forget the password. Thus, the system for resetting a lost password becomes part of the default login process. In which case, you might as well having a password in the first place.
We hit "peak password" somewhere around 10 years ago. Passwords are both bad security and bad UX. Cryptographic secure keys are better security, but at the cost of a much worse UX.
Bad UX is a defect. We need to stop giving a pass to crypto programmers who make such shitty software. Software that is not easy to use won't be used, and should therefore be considered as insecure as any other defective software.
Particularly for sites where you're unlikely to return for months/years (government, utilities, charities, small ecommerce sites) this is a fantastic approach.
i'd prefer no password validation other than having to type it twice. but have a password strength gauge, and give hints on how to bump up the strength (have you tried using a non-alphanumeric character)
I have to use Dashlane for work and it horrifies me that their password requirements are so outdated. A password manager ought to know that it's more important to have a longer password than a password with a number in it.
After explaining why many common password rules are bullshit, the author presents the few remaining rules that aren't. Or rather: if you're going to subject your users to the bullshit that is passwords, here's a set of rules that optimize the security:bullshit ratio.
Thou shall take care of the password manager, as it is a single point of failure. Because users (=not people who read and understand news from hnews, but the layman):
1 - won't make backup of the password manager (PM) database
2 - will forget sometimes the main password of the PM
3 - will loose the cellphone where the PM is installed
4 - will not update the PM
5 - will tell somebody else the PM password
And there will be many PM, some will have flaws, bugs or backdoors. Some will work on iOs but not on Android. Some will mess up in same point and make users lose trust.
And there will be sites with bad interface that won't accept copy-and-paste of the passwords. That will require things that your random-generated password doesn't contain. Will complain about something that it contains. Will do good on the password but will have those stupid questions (maiden name? grandfather name? pet name?) that you'll be able to find in any Facebook. Than the weak point becomes the password recovery.
I just found one type of requirement that was good enough to people take real care with the password: when the password is the one that allows anyone to withdraw cash from their account. When there is real money in the game, people take care.
I agree with almost everything but the he loses me towards the end:
> I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters.
Isn't that exactly what you're complaining about with your arbitrary password restrictions to begin with?
I mean, I can imagine that a clueless user might have the illusion of safety if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
I think there are two possible ways to look at this problem from a service provider perspective:
- if the user getting their password stolen is a bad thing for you (i.e., you're a bank or something like that, and getting an account compromised will put you in trouble), then IMO the only satisfactory solution is to impose a password to the user. In effect these ridiculous password requirements are exactly that, except less convenient and secure. Cut to the chase and say "your bank password is Axei5aoc0i, write it down somewhere safe".
- if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences. If they care enough about it they'll care enough to pick a decent password. At most if you really want to be friendly give an indication that a password might be weak, but please don't disallow it.
>but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
I agree. Sometimes I'm just signing up to a site where I don't put any personal info up, or at least nothing more sensitive than my name. Why do I need high-level security there?
Yes and yes! Many throwaway accounts I have use some variation of the same password, because I don't care if someone hacks my HN or reddit or youtube account. I don't use my real name on any of them. If I lose control of it, I'll just make a new one. (Karma doesn't pay the bills, and I don't make money from my very excellent youtube comments; someone else does.)
This is why all these accounts get an email account that doesn't include my real name, too. There are so many sites that have these signup dialogs that require an email address -- why? Oh yeah, that's right, user data is the oil that will fuel the future economy.
There isn't a day that goes by that I don't get an email intended for someone else, often including personal information, due to a mistyped email address. Whoever decided that email verification was a poor user experience needs to be hit in the head with a shovel after he digs the appropriate sized hole.
If you know Catherin (PA) let her know her round trip to vegas is confirmed
Carolyn's (NYC) open table reservation was canceled by the restaurant.
Different Carolyn (CA) needs to correct email address with the walnut creak school district.
Possible the same Catherine (PA), your financial advisor needs a distribution form filled out.
Clint (OH), your repair at Kay jewelers in Akron is done.
Ann (FL), Thank you for scheduling an online appointment with Conley Subaru
sigh, you get the idea
Edit:
Oh, and I'm going to start canceling Open Table reservations that show up in my inbox.
My most entertaining email yet was a group thread that kept track of a young missionary's progress as he traveled through South America. He's home now, so I don't get weekly updates anymore :( I almost miss it.
As someone with an unusual name (used for my public-facing email address) and who uses a fairly unusual email for personal stuff... that's pretty different from my experiences. I've never ended up with someone else's mail at all.
That's a solid argument for business cards with vCard QR codes as I see it. Or a pack of stickers with QR codes that you could slap on whatever documents you needed.
It's too bad QR code adoption is so horrible. I'm just as guilty of it as anyone else, I assume that any QR code is probably just some marketing thing.
But vCards seem like one of the very legit use-cases. Now that I am imagining using stickers and never filling out my contact info on a form again, I realize that's definitely a world I want to live in.
> As someone with an unusual name...and who uses a fairly unusual email for personal stuff... that's pretty different from my experiences. I've never ended up with someone else's mail at all.
I think it's more likely if you use an initial in your email address. I have a fairly unusual last name, but I used my first initial to create my gmail address, so I regularly get stuff meant for a couple of other people.
Business cards or sheets of stickers are not going to solve this problem. The former is not universal, and you're not going to get enough adoption for the latter (do you really want to carry them around in case you need to put your email on a form?).
The only solution that might actually work is to put some kind of financial penalty on certain classes of email sender to incentivize reasonable levels of validation.
I could overload my pockets carrying around all kinds of special purpose labels and stickers, and track my stock of them so I don't run out....or I could carry a pen.
> Do you people really not keep a book of stamps in your car?
What's even more annoying is that some sites ask for verification, but then proceed to email you stuff even if you don't click verify. Someone in Australia created an Apple ID using my email. I ignored the verification, but then I got a bunch of purchase receipts from them later.
What I really wish for is a link in emails that say "I am not the intended recipient of this letter." Normal mail works like that. You can ask the United States Postal Service to only deliver mail that has your name on it, and if you send back mail with someone else's name they will add that person's name to a database that says the mail is undeliverable.
I don't want to mark these organizations as spam, but that's basically what they are to me. I've started using the password reset to log in and change the email preferences so I don't get these emails anymore.
I suppose there may be some sort of anti-hacking law that could be twisted to fit this case, and if the cops came to my door over it I'd definitely hire a lawyer before I said anything. I somehow doubt if I'd be charged with a felony for accessing an account that is registered under my name and email address and turning off email notifications, especially since I've tried everything else I could think of to stem the tide, including emailing support, etc.
Plus, this individual who keeps signing me up lives in Australia. I cannot imagine our system is so dysfunctional that both the United States and Australia would agree that a) this is a criminal offense, and that b) it would be worth going through the effort of extraditing me to face justice.
I mean, I haven't even received another password reset request from those websites I logged in to fix that issue, so I half imagine that person is using my email address as a plausible address for email they don't care about.
I understand what you mean, but I don't think I'm going to have to spend the rest of my life looking over my shoulder. The few personal emails I've gotten with financial details (gym membership bills, etc) I've responded letting them know about the mix-up and they've been more than happy to fix the issue. Feel free to say I told you so when I end up in a jail full of kangaroos though.
I had the same problem with someone signing up for an Apple ID with my email address.
I even tried calling Apple to get them to cancel the account, but they wouldn't let me because I couldn't answer any of the security questions on the account!
The guy on the phone acknowledged that of course I can't answer them, because I didn't create them, bit their policy forbids them from doing anything without the security questions...
Man, now I'm wondering if this is some sort of violation of the CAN-SPAM act. My blood pressure goes up a little every time I get one of these emails and it doesn't have a way to unsubscribe if you aren't the legitimate recipient. Considering the companies that spam me the most with this irrelevant crap are Apple and Wal-Mart, I would feel 0% bad if they lost money over this practice.
Quick Edit: I just read the Wikipedia page, and individuals cannot bring suit against spammers (using CAN-SPAM in any case). Which is a shame really, because spam is really really annoying.
Instagram does this. They let anybody sign up for an account using any email address, and the account is immediately live. While they send a verification email, you don't have to click on it to still use the account. And most likely if you hadn't signed up for the service you'd think it's a phishing attempt and ignore it anyways.
I found this out the hard way when someone else had created an account under my email address and because some of my friends had uploaded their address book, my friends were following this stranger, perhaps thinking it was me. When I eventually did choose to sign up, I had to jump through a bunch of hoops just to be able to use my own email address.
My last name is pretty uncommon, but there are at least a thousand of us or so in the US.
I probably get a dozen emails a month to people who are not me (not counting all the ones that end up in the spam folder after I'm on a damn list).
Susan. Stephen. Another Sam. So many damn S. Lastnames around.
On occasion I've tracked the people down. I've forwarded their emails if they seem important. And whenever I ask that they be more careful and memorize their own email address, they get defensive and tell me someone else made a mistake.
Buddy, this email was was an automated response from a computer
after you signed up for something. No, it did not just randomly decide to send to my @gmail instead of your actual @yahoo address. YOU just don't know your own email.
Enough people clearly do -- they think that all email addresses end in @gmail.com, even if they check their email at yahoo.com. Because we have an email monoculture.
I have (first initial)(mid initial)(last name) at gmail. Same as my HN id. And a very common last name! 16 months into my first job out of University I got a call from a headhunter intended for the other Chris Miller sitting 2 cubicles away from me. At my second and fourth jobs there were also other Chris Millers. And from my list of examples, most all have the same last name.
4 days into university, the first time I logged in to the email account, I had several messages waiting for me, all intended for the same person, the best of which was:
"Hi X. The £80 million for the new biomedical building is approved, please make the transfer ASAP."
It turned out I had the same unusual name as the most senior financial officer.
> Whoever decided that email verification was a poor user experience needs to be hit in the head with a shovel after he digs the appropriate sized hole.
That's why you get send the verification email first, when creating the application user, and don't do anything until the email is verified.
The flow should be:
User: Please give me an account; my email address is jim@example.invalid
Server: I have sent an email to jim@example.invalid
That is what I was trying to say. Apparently there is some number of designers that believe that that whole email verification process is too much friction for registering a user, so they simply opt not to do it at all.
I have an uncommon name spelling and I still get misdirected emails.
Not to the extent of the above, but for instance, last year I received someone's job offer in Colorado. I did respond to the sender to let them know of the mistake of course.
I've always assumed it was for password recovery. People forget those all the time, email is a quick way to verify identity. Since everyone can have an email address for free. If you have a better way, do tell. Also, when your email is your username, that's one less thing to remember.
I do the same thing. I have my crap/spam/don't care account (at yahoo.com). All the accounts that use that email address (which has zero ties to me - though you have to be careful over time not to leak information) also all use the same password. Couldn't care less if anyone ever ties two random and anonymous accounts on the Internet together. My important accounts have huge passwords from a password manager.
well I really need to remember part two, for too long I just used an old email I no longer had as my primary account but it does incorporate my last name. time to get smarter. thank you for wake up
Then you're effectively banning someone's existing account, which they could have been using for years at that point. There's a lot of potential content there. Not a great feeling for anyone.
Seems like the simplest solution is to have some basic password requirements.
I think the OP and other posts here have demonstrated that password requirements won't solve anything given a sufficiently incompetent or not caring user. If the platform provider cares more about the security of the account than the account holder there isn't much you can do.
> if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing
You do. A lot of users don't consider automation when it comes to people hacking their account. I've heard "Nobody will ever guess it though" a few times during my career.
I am being serious when I ask this question: does anybody brute force passwords? I posit that using a unique password for every single website is sufficient, because no one brute forces passwords.
What attack vector is a password with high entropy protecting against? The only one I can think of is an unreported database leak. The attacker may be able to more easily reverse the password hash and use your account on that particular service, at least until the leak becomes discovered and the service does a full password reset.
While it would be ideal to defend against that attack, I think it's far more important to stress that users have a different password for every website. The real attack vector that we see every day is a DB leak from a poorly secured website, passwords cracked, and then reused on important services. That's where the problem lies, not in the user's password entropy.
Jeff isn't wrong here, he's just attacking a relatively unimportant problem.
I was wondering this as I read it as well. Yes, we know it would be fairly easy to compromise an individual account by guessing common passwords. But that assumes you have one particular account in mind. If you're just looking for bank accounts to access, you first need a list of usernames to try (ideally usernames of non-tech-savvy people) and then you need to run your entire password guessing routine for each one.
I'm no security expert, but I start to wonder if the "practical" entropy of a given password is actually much higher than the theoretical entropy numbers people derive.
Serious question: when is the last time anyone has had an account compromised because of a weak password?
And then what? Like sure, you'll be compromised on that one service and that's bad, but it's not anywhere near as bad as re-using passwords across services. My argument is we should be focusing on stopping password re-use far, far more than we should be nit-picking about password entropy.
>Serious question: when is the last time anyone has had an account compromised because of a weak password?
What is your definition of "weak"? I sometimes help my landlord fix their computer when they accumulate too much malware. One time I brought their tower home to do this and didn't get their Windows account password. Instead of calling them I decided to try a few things first, including their kids' names. Lo and behold, the second attempt was correct.
Brute forcing a weak password probably isn't what you have to worry about when it comes to targeted attacks against weak passwords, but social engineering is.
Hah, funny you ask. I was able to siphon off internet quota in my college using a combo of brute-forcing and previously known passwords. Worked quite good until my conscience got the better of me.
My wife had an account hacked years ago. I don't know for sure that it was brute forced (could have been phished or exfiltrated by a keylogger or session jacked with an XSS vulnerability or...), but I also don't know that it wasn't brute forced. She used very short, simple passwords at the time.
Come to think of it, I also had an old account with a very weak password that I hadn't used in years mysteriously hacked one day. The language settings were changed to Russian when I went to reset my password. The fact that no other account of mine appeared to be compromised and I hadn't used the site in years certainly suggests brute forcing.
I know of almost nowhere that encrypts content with the user password. It means if the user resets the password because they forgot it, they lose content.
Depends. If the leak or breach reveals actual password, then yes, you're screwed. If it reveals SHA-256 hashes, then you're screwed unless you chose a good high-entropy password (e.g. lBBo1f93XbbKs2hKa8T5pR). If it reveals PBKDF2-hashed, bcrypt- or scrypt-hashed passwords, then you're almost certainly safe, unless you chose a really poor password (e.g., the following is a Base64-encoded PBKDF2 hash, with 100,000 iterations of SHA-256 and a seed of 'QDTGEqi8to9PrkpBgCbnN0': 8h1HO6omVWhusXcQRGS0CcTzSC5AkAIvodC+hT/AoRk=; I contend that you will not be able to guess the password I used for it), since trying passwords with a good key-derivation function is so slow.
Do you run any ssh or email servers? If so, your logs will tell you already. I've got bots brute forcing passwords on my blogs, that nobody even read, but did have account functionality, with email sending. People made the point of adapting their bots for different captcha schemes just so they could send some email.
> I am being serious when I ask this question: does anybody brute force passwords? I posit that using a unique password for every single website is sufficient, because no one brute forces passwords.
Weren't the celebrity iCloud account compromises due to Apple neglecting to rate-limit a certain authentication API endpoint, allowing the hacker to brute force passwords online?
Also, doesn't some of the current crop of IoT malware brute force device passwords as well (after trying the defaults)?
If you have a server running SSH, you can try the "lastb" command, which shows failed logins. Or, look in the logfile, often /var/log/secure or similar.
That's a very interesting way to categorize passwords. I wonder if one reason why banks etc. don't auto-generate passwords is to avoid liability: I can totally imagine a class-action lawsuit where a lawyer claims that all the auto-generated passwords were insecure.
>I mean, I can imagine that a clueless user might have the illusion of safety if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
It's not an illusion, 1q2w3e4r5t is indeed better than aaaaaaaaa, even if it's just the numbers interleaved with qwerty (and probably easy to brute force generate up to it).
>if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
Because not everyone who uses "aaaaaaaaa" (or "1q2w3e4r5t" for that matter) knows "full well" that it's insecure?
"COMMON PASSWORD: IN THE TOP 9635 MOST USED PASSWORDS
Your password is very commonly used. It would be cracked almost instantly[1]"
I do realise there's a difference between cracking a local system password vs a website password but always assume a site's database is going to be leaked at some point
It's a password that I postulate is more secure that the average and yet is only made of two different symbols and would've been rejected by the proposed "x amongst y" character policy.
It's a bit far fetched but not that much, you'll notice that the pattern is simply the first digits of pi, so it's fairly easy to remember. And the letters are "Hn", like hacker news.
That's my point, really. If you think you know better than the user how to pick a password, then just do it. Otherwise don't get in my way, you don't know how I generate my passwords.
>That's my point, really. If you think you know better than the user how to pick a password, then just do it. Otherwise don't get in my way, you don't know how I generate my passwords.
Only they don't need to know how YOU generate your passwords. Just how most of their users generate their passwords. The suggestions and rules are not there to protect computer scientists from entering bad passwords...
zxcvbn (https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...) gives it a score of 4/4 and an entropy of 10^20, meaning it would take centuries to hack at 10B a second. I think this is a slight overstatement of the security, because it's probably more along the lines of 50502^30 which is closer to 10^12. And this would be a legal password (but banned by the bullshit password rule).
I feel like the solution to everything in this thread is just to use zxcvbn and stop with the insane rules for things. In your two cases: the bank would disallow passwords below some limit while the blog would just show you a warning (in case you were ignorant of hacking enough to know that "aaaaaaaa" wasn't a good password), but let you use your awful password to spare you from having to remember it.
> It's not an illusion, 1q2w3e4r5t is indeed better than aaaaaaaaa, even if it's just the numbers interleaved with qwerty (and probably easy to brute force generate up to it).
In this case, we're talking 'better' but still bullshit [1]. Calling it 'better' makes no meaningful distinction whatsoever in practice.
> if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences. If they care enough about it they'll care enough to pick a decent password.
Surely that's a cop-out? If the user getting their data stolen is not a big deal for you, why bother securing any system at all?
The reason service providers set password rules is because there are many, many people who do not understand what a good password is, or the risks associated with losing them. There are people out there using the same password for everything, unaware that the compromise of one service can spell doom for their financial life.
Developers really need to start taking responsibility for their code. Setting password rules, while arbitrary, are about protecting users. This may upset those who are tech-savvy and know what they are doing, but that really weighs nothing compared to the benefits it brings to those who are not.
I guess Atwood's point is that it's impossible for developers to stop users from creating dumb passwords just using regexes. That much is true. Even if you require an uppercase letter, lowercase letter, special character, and number, you're still going to have a lot of passwords like "Password_1" coming in. And then, if you require people to change their password every so often, it will become "Password_2," "Password_3," etc. There's no easy way around this.
It is weird that he goes on to suggest a complex system of rules literally right after saying rules are bad, and that's the point where he lost me too.
If users don't understand what a good password is, they are going to eventually get an account compromised somewhere, if not on your site, then on another. In cases where there's no liability back to you, then there's no sense in babying them. If you do have liability, then two-factor authentication is probably a better way to go.
I personally would hate it if a company forced me to use their generated passwords because I like to manage my own passwords.
However I take offense at the notion of "babying" users. We are all babied in some aspect of our lives: if it weren't for the active work and intervention of those in other fields, we wouldn't know whether the food we eat is safe, or if the roof isn't going to collapse during the night. I'd like developers to assume some responsibility for their users in turn.
But I concede that may be beside the point in the case of password rules.
Totally agree. If you annoy the user too much, they will not try to circumvent your rules, they will leave and find something else to do with their time.
Also, the big question that's missing from the article is: who's the enemy? If the enemy are Russian genius hackers, then certainly very long passwords and maybe other measures are in order.
But the enemy is not always remote. I just bought a new iPad and had to reset my password and so-called "security questions".
In my experience, there are only two kinds of security questions: ones I don't know the answer to myself, and ones everyone around me knows the answer to (what was your first job, what was your surname when you were a child, etc.)
The problem is, in the case of the iPad, your enemy is not some James Bond villain in a cave in Ukraine, it's your 13 year old child who wants to use your account to buy apps, or your spouse during a nasty separation. And they both know, or can guess, answers to "security questions".
What I do personally is type random things as the answers, and write them down somewhere. But that doesn't improve security, it weakens it.
Ran into one where it demanded I choose from a drop-down list, e.g. "What was your first pet" had "dog", "cat", "hamster", "gerbil", etc. I recall the list having a scrollbar, but there was not even enough choices for eight bits worth of entropy.
Oh, and they referred to these security questions as "2FA."
I love the ones that ask about one's favourite sports team (not everyone likes sports), or first girl (or boy) friend (not everyone has dated) or first car (not everyone has ever owned a car).
This is a good idea. Unfortunately if you have ever in the past (foolishly) answered these security questions honestly, you can't just now start answering them with your password, unless you keep track of which sites have your honest answers and which sites you just gave your password again.
Did I answer "Ste-Citée" or "Ste-Citee" or "Sainte Citée" or "Sainte-Citee" or ... oh, too late, only had two chances to answer. My account is now locked.
>What I do personally is type random things as the answers, and write them down somewhere. But that doesn't improve security, it weakens it. //
It weakens it to the extent of your physical security. But in practice how many crackers are breaking in to your flat [aka condo] to find your written down security responses, unless you're famous - or a target some other way (politician?) - in which case you should have sufficient physical security to protect the written answers.
Having security questions allows users to use hard passwords without the problem of losing an account. It increases the risk of personal attacks, for sure, but I'd warrant the chance of personal attack [ie by someone who knows you (or has gone through your bins)] is minimal for most people vs. the chance of an automated online attack.
I think it's right to minimise the online attack surface at the risk of the offline one for most users.
I have never come across an authentication mechanism that actually required your security questions. There's always another route to restoring your password, which means that they do not serve a security function, but rather serve a convenience function, at the expense of security.
If you are willing to be brave about this then the best way of answering security questions is by typing a random string and NOT writing it down. You will never need that value again.
I once did that for a site which I didn't want anyone to recover my password to and thus break the security. I -DID- write down the actual password.
Today, years later, I still can't login to the damn payroll site because there isn't a procedure for just completely resetting the password state of the account and it wouldn't let you log in without those extra things.
Since that point I have recorded every annoying split-password (that's what the 'security questions' actually are, a forced split in the single real password)...
It's also insecure to have password rules because people end up writing, printing, saving passwords in Google Docs, because they can't remember them anymore with those stupid rules.
Totally agree about the "security questions". They're just insecurity questions. Everyone knows what street I used to live on and what my previous phone numbers were.
For security answers I let my password manager generate a Multi Word Phrase you can easily spell out in a phone conversation. Store those in my password manager under my account. Someone told me he had to go through a converstation with Apple Support spelling out 3 random 20+ characater passwords and it was a nightmare. I immediatly switched tactic.
Regretfully Apple has an annoying bug that the dialogboxes accepts 5-word phrases, but only remember the first 32characters, 3 words or something alike. Very stressfull when you’re trying to recover a password.
Imposed passwords aren't the only solution. Something like Google Authenticator is an alternative. Or key fobs. Or send a confirmation code to their phone. Or something like Barclays' PINsentry [1] for cards where you need the gadget, the card and the PIN. Or face recognition, which I recently saw demonstrated (it includes liveness checks like asking you to blink).
Authenticator is great, but then you get the arsehole effect - every arsehole company decision maker wants you to only use their authenticator. So, I made an account on MS recently and can't use GA because "fuck you user, we won't stop until we own every facet of your digital existence" or something. That shows you where such companies rank security.
[FWIW I expect the reverse situation is probably the same, this is just my anecdotal experience].
Then I apologise, it must be an information 'hiding' issue then because they clearly flagged installing their own Authenticator and I was completely ignorant of the use of GA; GA must be the most popular authenticator? Does this all mean I can use a third-party auth for both MS and Google sites or is it only MS that supports third-party authenticators?
For what it's worth, the current NIST draft has the exact same recommendations:
> Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.
> When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):
> * Passwords obtained from previous breach corpuses.
> * Dictionary words.
> * Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
> * Context specific words, such as the name of the service, the username, and derivatives thereof.
> if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing.
There's no substitute for length. "dog" is a bad password. "doooooooooooooooog" is much better. The entropy is still the same, but the latter takes much longer to brute force and is just as easy to remember.
Of course one should not use passwords one can remember for anything critical, but many passwords are for services where compromise is not a big deal.
I agree with what you have said but I think the new guidelines don't go far enough. The biggest problem is that in the balance of security and convenience, users will always opt for convenience. Only via legislation will that change, think credit card chips versus swiping. (We should have chip + PIN in my opinion.)
We need to make passwords a much simpler thing to manage so that people don't create a bigger problem by putting it on post-its on their monitor. What I'm suggesting would take some effort but is where we need to go. Your username is your fingerprint. You won't forget that and it is very hard to fake/brute force. (Your phone already has one and a usb one for you computer would be trivial. A lot already have them.) Your password is always just 8 characters, alpha numeric only (62^8 is plenty big) and you must have 2FA on. It would be trivial for the phone manufacturer to add that at the OS level and it could be visible on your lock screen. Also, finally a good use for a smart watch. The rules are simple and you have removed the biggest security hole most companies have: people. Just my two cents....
> but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing.
That's you. The average user thinks 'nobody will guess this password'. In other words don't assume they know about brute force attacks, rainbow tables, most common password lists and a host of other things that they haven't thought of or don't know even exist. They don't even know the complete group of actors that could potentially breach the account.
> if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences
Yes! Please. Let users determine the value of their accounts for themselves. If I decide that say, my HN account isn't valuable and use a common password that is shared with many websites, I know the risk I'm taking and I'd rather take it than have to mark down a unique password for HN.
On sites I write I advocate for no password rules at all (hit enter is good enough for me, yes we can hash an empty string), have usually compromised on a simple length check.
Proper password storage is important, use the latest bcrypt/scrypt/argon2, don't cheap out there. You can cheap out on password rules. If you want to write a fancy entropy checker, run it client side and tell the user how secure their password is, let them choose whether they want that or not.
yeah i'm on your side. I randomly generated a password one time that ended up with 3 repeated characters. I used it because, hey p-random is p-random i'm not gonna argue. Unfortunately the site it was for rejected it.
I've since had to change my random generator to avoid 3 of a kind, which actually makes it less random/secure i believe.. pruned some branches off of the search tree.. especially since i've now told everyone ;)
I wish we could just avoid all of this by using methods like SRP[1] where the site wouldn't even need to know the plain-text password in the first place. Why am I giving a "secret" to someone else?
I'm surprised that this article didn't mention the most important point about password rules:
They force you to come up with a new password that you probably haven't used before and so you will probably forget it.
There are websites that I don't use often where I literally have to reset the password (and go through all the i-forgot-my-password steps) every time I want to log in because they forced me to come up with an overly creative password.
I think most people have two or three passwords for all their apps/services; one very secure one, one medium security one and one low security one (where you literally don't care if you get hacked). It's not the company's business to tell you which of those classes of passwords it deserves for its website.
For me it's gotten to where I just assume next time I need to log into the website, 6 months from now - car insurance for example - I simply expect to recover the password. No password really matters besides my email.
Related, some of these sites you forget what you used and have to create a new password - and some of them do this horrible "You cannot re-use your four last passwords" thing which leaves you in this sort of permanent "I'm never going to remember and always have to come up with something new" loop (for sites you go to only periodically, e.g. an HR portal, let's say). But hey, nothing important lives in an HR portal, right? :P
OMG very true. Often, it seems that all these password systems are designed for celebrities; maybe if there were teams of people working 24/7 to hack my account, then it would make sense.
Employee of a university here. Not only are the password requirements annoying, unless you close the browser you aren't logged out. Clicking "logout" makes it look logged out, but the next person to use email/payroll enters their credentials and gets the prior users account. Hilarity ensues with people applying for each other's leave, emailing responses to messages that weren't for them etc. The interim response is for people to set a theme in their email to make it more dictinctly different. I kid you not.
Shibboleth user? I can't even imagine how difficult that kind of problem is when you're working with other people's software.
* Go to some service A.
* Get redirected to SSO and authenticate.
* SSO confirms your identity and A issues you a session token.
* You log out using your SSO.
* Go back to A where you're still logged in with your session token.
At a certain point I would not be willing to commit to maintaining lots of patches to every product we host and just tell our users to close their browser.
"There are websites that I don't use often where I literally have to reset the password (and go through all the i-forgot-my-password steps) every time I want to log in because they forced me to come up with an overly creative password."
Indeed and then one's email potentially becomes the weakest link in one's password security.
If a site offers email resets at all, how often you (legitimately) use them generally doesn't play into the security analysis. If it's easier to get access to your e-mail than to get the password to the account that can be reset by proving access to the e-mail, then your e-mail is the weakest link.
>"if it's easier to get access to your e-mail than to get the password to the account that can be reset by proving access to the e-mail, then your e-mail is the weakest link."
This is why my new server system sends you a password for every login you want to do to your email. Of course you do stay logged on, so it is not needed very often.
You really shouldn't be re-using passwords across sites anyway, since all your accounts are compromised if any of them are compromised. Since re-using passwords is a problem solved by using a password manager, I'm assuming you're not using one, in which case you likely won't even remember the list of sites where you have accounts that have a shared password if you need to change it when any of the other sites are compromised.
Best to just use a password manager and keep unique per-site passwords.
Most of my accounts use my low-security password, I don't care much if they all get compromised. I only use my high-security password on 1 site.
Password managers are horrible - Whenever I change machines, I could never remember all my passwords and I certainly don't want to store my passwords in the cloud.
> Password managers are horrible - Whenever I change machines, I could never remember all my passwords and I certainly don't want to store my passwords in the cloud.
I wonder why people still think that their passwords are stored on the external site. It's explained on the "how this works" or whatever for most services like LastPass.
I'm quite hesitant towards using a password manager. All secrets are protected by only one single password, and to make the tool useful, it should be accessible from anywhere and I would use it quite often too, increasing the limit of my master PW being stolen (whatever way, keyloggers, shoulder surfers, cameras...). Thus, I rather memorize a handful of unique high-security passwords for important services and one or two low-security ones for all the rest I don't care about.
Of course, it's a different situation when e.g. managing many sensitive servers which you only access from work or so.
All secrets are protected by only one single password, and to make the tool useful, it should be accessible from anywhere and I would use it quite often too, increasing the limit of my master PW being stolen (whatever way, keyloggers, shoulder surfers, cameras...)
True, though your handful of passwords can be stolen in the same way.
With a password manager, you:
- ensure your master password is not transmitted over a network
- ensure you never reuse passwords
- ensure you have long, strong passwords everywhere
- never forget login details and never worry about remembering yet another password
On the other hand,
- you _need_ access your password manager in order to login
- you now have a single point of failure
- cloud-based password managers are very attractive targets for hackers
I don't like these aspects of it.
Still, a password manger is incredibly convenient and I do feel a greater sense of security/confidence when I copy a big old 64 character password to log in. As it is, I use so many different services (gmail, github, slack, aws, steam, dropbox, reddit, etc, etc) and that number is only going to increase. I think a password manager is a practical, scalable solution to both remembering login information and improving my security.
The security process that has really worked for me is using the "forget password" as means to get a "login token" into my mail, which is protected with 2-factor auth.
I don't have to deal with password managers, maintaining their files. Or deal with multiple passwords.
My current pet peeve with password resets goes like this:
1) Forgot the password, start the recovery process.
2) Get to the "create a new password" phase, look at the rules.
3) Rules require special characters, caps, etc. So I make one.
4) I get the "This password has been used before" error.
5) Now I have to think up a new random one.
If that password 'that was used before' was the current one, why can't I just continue to use it??? Now I remember the password (usually because of the silly special character requirements), so we're good, right? Wrong.
As a side note, if you are a website with arbitrary rules, as a general UI recommendation, please state your rules if a user inputs an incorrect password. I'm looking at you yahoo.
I gave up on this long ago. I login to various accounts from different machines often enough that a password manager doesn't always work for me. I keep a printed paper copy of some 60 different passwords in my laptop bag in case I need to remember one for a new machine. That printed copy gets handwritten notes on it from time to time, which I then use to update the text file on a thumb drive when I'm not connected to the Internet. I print a new copy about every two months, I guess.
To add to the bullshit, it is so common that a site will have some idiotic rule (like "must include a number," "must have at least one lower (or upper) case letter," "must include a special character," "must not include any of these special characters," "must change password every 30 / 45 / 60 / 90 days"), that I don't even get mad about it anymore. I can't even spend the mental energy to send them an email.
from a security standpoint. I hate the required special characters BS, especially since other sites will explicitly restrict you from using those same characters. Seriously, without a password manager of some kind I don't know how people can function online.
Travel to some other side of the world and France's CNIL recommends[0] the following password rules as of 27 Jan 2017 (abridged):
- if the system uses a login + password scheme: 12 chars min and mandatory mix of all among non-caps/caps/digit/special
- if the system uses a login + password + time-based exponential backoff rate limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 10 tries or a bot detector such as captcha: 8 chars min and mandatory mix of 3 among non-caps/caps/digit/special
- if the system uses login + password + environmental information (such as IP or MAC addr, etc...) + time-based exponential backoff rate limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 5 tries or a bot detector such as captcha: 5 chars
- if the system uses login + password + hardware second factor (SIM, U2F, YubiKey...) + lock out after 3 tries: 4 chars
To fend off in-transit and offline attacks, the document suggests that auth should transit sufficiently encrypted (using a cipher or method currently recognised as strong and non-vulnerable) and passwords should be stored obfuscated using a secure (similarly defined as strong and non-vulnerable) one-way cryptographic function with salt (and possibly pepper since they mention a "key", which makes no sense for one-way crypto functions).
Why don't we dispense with the pretense that passwords should be human readable strings of characters at all, and just make them a sequence of randomly generated bits.
Passwords often need to be human readable because, in practice, humans often need to memorize them and then enter them from memory, or write them down on a piece of paper first, which can be error prone with a complex password.
Using a password manager isn't always an option either - there is a vast amount of infrastructure, much of it corporate and nearly immutable - that simply presents the user with a password prompt and expects them to get it right.
It's only recently that some password prompts even let you view the password you've typed. With a terminal, you get no visual feedback at all.
Password managers suck as soon as you need to share a password - like the password for a SaaS admin panel used by several people at a business. Not all services support multiple users (or multiple admin) users.
I just yesterday had to sign up for some bullshit "secure email" service to read some email from my late uncle's bank. They had all the rules described in the article, and I could not use highly secure generated passwords. I finally settled on some super weak password with one of each requirement (char, case, symbol) tacked on to the end. Sigh.
To make matters worse, the email looked just like a phishing attempt. Right down to having you download some html attachment, which, after it opens, directs you to click on something which finally takes you to the "secure email". The whole process felt like something a scammer would come up with, and is really not how banks should condition their customers.
282 comments
[ 3.9 ms ] story [ 327 ms ] threadMeanwhile my organization is getting ready to mandate the use of a password manager that uses bullshit rules to produce analytics to surface at the director/VP level. So it goes. I look forward to automating the GI that's used to produce this GO.
Of course, that comes with its own set of issues: Lose access to the password manager = lose access to all your accounts. An attacker gets access to your password manager = they get access to all your accounts.
On the other hand, for users who use a single 6 character word as their password all over the web, that's essentially the same thing. You can far more easily educate someone in picking a very strong passphrase they will never forget, than get them to use different passwords on each website.
I have successfully converted several non-techies in my family to KeepassX [https://www.keepassx.org/], which I also strongly recommend to anyone here. I had to hold hands at first but after explaining how it works and making sure they understand how important it is, over two years, there's never been any issues.
[1] https://www.grc.com/haystack.htm
I use a command line tool to generate passwords, and I use a password database to store them. It has happened to me before that the maximum password length is something disconcertingly small, like 20 characters. I would copy and paste my password, submit, and then failed to be able to login. Why? Because my password in the "create" page was silently truncated on the front end, but the same truncation does not occur in all places, so I would type a longer password on the login page then what was registered in the system and it would fail.
Other times a password that was too long or contained whitespace would fail with a cryptic error message, or would tell me I failed to meet some other password rule that I know I did not fail to meet.
I don't understand how something with so many widely-recognized best practices associated with it can be implemented badly.
If there was a problem with password truncation I'll know straight away and I can either figure out what the truncated password should be and switch it to something that isn't truncated or if that's impossible I can create a new account. If I'm unable to create a new account at least I'll know to stay away from them without having done anything important yet.
This means you can successfully set your password to something you can never enter!
It has been raised in their forum but the discussion there is drowned out by people missing the point entirely. https://community.giffgaff.com/t5/Help-Support/Password-Limi...
Woo. Can't remember what clue the system gave me that let me figure out what had happened now.
Here's an even worse one than truncating the end of long passwords: truncating internal whitespace
The change/reset password dialog for Apple ID does this. If your password is "foo bar baz bam" then it will happily convert it to "foobarbazbam" but not tell you it did so. Then when you go to log into your Apple ID on your phone, you include the whitespace, you try repeatedly and then lock your account (temporarily). Then you do it again...
Some general advice is:
- Don't silently truncate anything (i.e. don't limit the length)
- Don't silently remove anything (i.e. don't remove whitespace)
- Don't silently transmute anything (i.e. don't convert to lowercase)
- Don't have a password max length with a limit less than $BIG_NUM chars[1]
- Do give the user feedback rather than silently doing anything.
[1]: You're hashing them anyway right? So the storage doesn't change. Though if you're using something like bcrypt be aware of the max hashed length: https://security.stackexchange.com/questions/39849/does-bcry.... Also you can work around that by hashing the entire uses password (with say SHA-512) prior to inputting into bcrypt.
I wonder why people are so eager to combine different hash algorithms, especially a strong with a weaker one. If this is isn't a well-established anti-pattern, it should become one.[1] Why? Because in some sense it combines the weaknesses of both algorithms.
Assume your password hash is:
h(p) = bcrypt(sha512(p))
Assume in the future somebody generates a sha512() collision with p and q, while bcrypt() holds water:
sha512(p) = sha512(q)
It follows that:
bcrypt(sha512(p)) = bcrypt(sha512(q))
and hence:
h(p) = h(q)
So any collision in sha512() translates directly to h(), bcrypt's strength is unable to protect you from that.
Had you just used bcrypt(), you would not have been affected.
Frankly, this is about collision and not about preimage attacks (the latter being more relevant for password cracking), but the former is usually a first step towards the latter. Also, this example demonstrates that combining a weaker and a stronger hash algorithms usually does not combine their strengths, but their weaknesses.
[1] It is almost like inventing your own crypto primitives, which actually is a well-established anti-pattern.
What I'd consider a much worse issue is considering the following to be the same by silently truncating things:
- some really long password ... that ends with foo
- some really long password ... that ends with bar
- some really long password ... that ends with baz
The only acceptable alternatives when using something like bcrypt are:
- Restrict user passwords to 72 bytes (not chars!)
- Hash with something like SHA-512 prior to passing them to bcrypt.
I see. If that wasn't a design goal, this construction is sound.
People are eager to combine different hash algorithms frequently because they desire to hedge against weaknesses in one of the algorithms. Or, in this case, because they want to shore up an existing 'weakness' in one of the algorithms (for bcrypt, its maximum input size).
You are correct that doing this ad-hoc should be an 'anti-pattern'. There are subtle details (see the papers linked above...). However, the idea itself is sound, if handled properly.
No, but the time spent computing the hash does change and you open yourself to denial of service attacks. Just pick a max password length of like 200, or whatever your hashing algorithm mandates (55 for bcrypt).
Model of first car? zSuI2LR9DvDYwr04 (drop top!)
First city visited? GGSrqPB78tcJ2WB9 (what a trip!)
Street you grew up on? 1pAXzzns5owXNYiU (very quiet!)
Favorite food? oEW5AQ738bkGf6rj (it's delicious!)
High school attended? 3i5OfyNhnWD0bQVy (go Nonces!)
(Love the name of the high school mascot, by the way!)
United Airlines does exactly this and it's hilariously insecure. The secret questions are preselected and the answers must be from their set of answers for each. There's only 8-10 choices for each (ex: Favorite music? pop / jazz / classical / etc).
> (Love the name of the high school mascot, by the way!)
There 10 types of people. Those that got that joke and ...
Impose your size limitation as a clear password rule. That means, write on your site that passwords must not exceed the 55, 255 or whatever characters, send back an error if the user tries to create a larger password.
1 - And completely avoid weaker hashes in general, it's not like a percent or two increase in CPU usage will have a greater impact on your bottom than having to adapt your software after it's out.
I thought they were locking me out for proxying or something until eventually by luck I noticed what was going on.
Recently I had another scenario happen to me: signing up for a job application login, use my password manager to make a password, everything's great. Then when I go to login, "please remove the disallowed symbol (") from the password input before continuing". Needless to say, I could not log in. And they made me wait 24 hours before resetting my password. I was much less keen on applying for jobs there after that.
The same reason why we have other kinds of crappy software: People try to do it themselves rather than using a robust, tested, third party solution.
So the system could basically fall back to being OTP?
It's a great one. Not only does i recommend against composition rules, but
> Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)
Oh, if there is a sin against passwords it is forcing quickly memoizable (i.e. simpler) passwords.
password1 -> password2 -> password3
https://www.reddit.com/r/Jokes/comments/1v4bpa/passwords/
The first rule for passwords, you don't talk about your password rules.
[1]: https://github.com/dropbox/zxcvbn
Bad UX is a defect. We need to stop giving a pass to crypto programmers who make such shitty software. Software that is not easy to use won't be used, and should therefore be considered as insecure as any other defective software.
(See rules here: https://csdashlane.zendesk.com/hc/en-us/articles/202698981-I...)
1 - won't make backup of the password manager (PM) database
2 - will forget sometimes the main password of the PM
3 - will loose the cellphone where the PM is installed
4 - will not update the PM
5 - will tell somebody else the PM password
And there will be many PM, some will have flaws, bugs or backdoors. Some will work on iOs but not on Android. Some will mess up in same point and make users lose trust.
And there will be sites with bad interface that won't accept copy-and-paste of the passwords. That will require things that your random-generated password doesn't contain. Will complain about something that it contains. Will do good on the password but will have those stupid questions (maiden name? grandfather name? pet name?) that you'll be able to find in any Facebook. Than the weak point becomes the password recovery.
I just found one type of requirement that was good enough to people take real care with the password: when the password is the one that allows anyone to withdraw cash from their account. When there is real money in the game, people take care.
Edit: misspelling, thanks for the warning!
> I had a bit of a sad when I realized that we were perfectly fine with users selecting a 10 character password that was literally "aaaaaaaaaa". In my opinion, the simplest way to do this is to ensure that there are at least (x) unique characters out of (y) total characters.
Isn't that exactly what you're complaining about with your arbitrary password restrictions to begin with?
I mean, I can imagine that a clueless user might have the illusion of safety if they're using something like "1q2w3e4r5t" but if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
I think there are two possible ways to look at this problem from a service provider perspective:
- if the user getting their password stolen is a bad thing for you (i.e., you're a bank or something like that, and getting an account compromised will put you in trouble), then IMO the only satisfactory solution is to impose a password to the user. In effect these ridiculous password requirements are exactly that, except less convenient and secure. Cut to the chase and say "your bank password is Axei5aoc0i, write it down somewhere safe".
- if the user getting their password stolen is not a problem for you because it's not your responsibility to handle these issues (like a hacker news account for instance) then just let the user pick whatever they want and deal with the consequences. If they care enough about it they'll care enough to pick a decent password. At most if you really want to be friendly give an indication that a password might be weak, but please don't disallow it.
I agree. Sometimes I'm just signing up to a site where I don't put any personal info up, or at least nothing more sensitive than my name. Why do I need high-level security there?
This is why all these accounts get an email account that doesn't include my real name, too. There are so many sites that have these signup dialogs that require an email address -- why? Oh yeah, that's right, user data is the oil that will fuel the future economy.
- Password Recovery (this can be optional though, for my sites it usually is)
- 'Legit Users', sending an email and having them confirmed through a code in them gives a bit more confidence in the user
There isn't a day that goes by that I don't get an email intended for someone else, often including personal information, due to a mistyped email address. Whoever decided that email verification was a poor user experience needs to be hit in the head with a shovel after he digs the appropriate sized hole.
If you know Catherin (PA) let her know her round trip to vegas is confirmed
Carolyn's (NYC) open table reservation was canceled by the restaurant.
Different Carolyn (CA) needs to correct email address with the walnut creak school district.
Possible the same Catherine (PA), your financial advisor needs a distribution form filled out.
Clint (OH), your repair at Kay jewelers in Akron is done.
Ann (FL), Thank you for scheduling an online appointment with Conley Subaru
sigh, you get the idea
Edit: Oh, and I'm going to start canceling Open Table reservations that show up in my inbox.
https://xkcd.com/1279/
My most entertaining email yet was a group thread that kept track of a young missionary's progress as he traveled through South America. He's home now, so I don't get weekly updates anymore :( I almost miss it.
That's a solid argument for business cards with vCard QR codes as I see it. Or a pack of stickers with QR codes that you could slap on whatever documents you needed.
It's too bad QR code adoption is so horrible. I'm just as guilty of it as anyone else, I assume that any QR code is probably just some marketing thing.
But vCards seem like one of the very legit use-cases. Now that I am imagining using stickers and never filling out my contact info on a form again, I realize that's definitely a world I want to live in.
I think it's more likely if you use an initial in your email address. I have a fairly unusual last name, but I used my first initial to create my gmail address, so I regularly get stuff meant for a couple of other people.
Business cards or sheets of stickers are not going to solve this problem. The former is not universal, and you're not going to get enough adoption for the latter (do you really want to carry them around in case you need to put your email on a form?).
The only solution that might actually work is to put some kind of financial penalty on certain classes of email sender to incentivize reasonable levels of validation.
Yes. Or my name/address/phone number. It's essentially a machine-readable address label, the email is just one part of the vCard.
Do you people really not keep a book of stamps in your car? Such inconvenience!
> Do you people really not keep a book of stamps in your car?
No, why would I do that?
What I really wish for is a link in emails that say "I am not the intended recipient of this letter." Normal mail works like that. You can ask the United States Postal Service to only deliver mail that has your name on it, and if you send back mail with someone else's name they will add that person's name to a database that says the mail is undeliverable.
I don't want to mark these organizations as spam, but that's basically what they are to me. I've started using the password reset to log in and change the email preferences so I don't get these emails anymore.
Plus, this individual who keeps signing me up lives in Australia. I cannot imagine our system is so dysfunctional that both the United States and Australia would agree that a) this is a criminal offense, and that b) it would be worth going through the effort of extraditing me to face justice.
I mean, I haven't even received another password reset request from those websites I logged in to fix that issue, so I half imagine that person is using my email address as a plausible address for email they don't care about.
I understand what you mean, but I don't think I'm going to have to spend the rest of my life looking over my shoulder. The few personal emails I've gotten with financial details (gym membership bills, etc) I've responded letting them know about the mix-up and they've been more than happy to fix the issue. Feel free to say I told you so when I end up in a jail full of kangaroos though.
I even tried calling Apple to get them to cancel the account, but they wouldn't let me because I couldn't answer any of the security questions on the account!
The guy on the phone acknowledged that of course I can't answer them, because I didn't create them, bit their policy forbids them from doing anything without the security questions...
Quick Edit: I just read the Wikipedia page, and individuals cannot bring suit against spammers (using CAN-SPAM in any case). Which is a shame really, because spam is really really annoying.
I found this out the hard way when someone else had created an account under my email address and because some of my friends had uploaded their address book, my friends were following this stranger, perhaps thinking it was me. When I eventually did choose to sign up, I had to jump through a bunch of hoops just to be able to use my own email address.
My last name is pretty uncommon, but there are at least a thousand of us or so in the US.
I probably get a dozen emails a month to people who are not me (not counting all the ones that end up in the spam folder after I'm on a damn list).
Susan. Stephen. Another Sam. So many damn S. Lastnames around.
On occasion I've tracked the people down. I've forwarded their emails if they seem important. And whenever I ask that they be more careful and memorize their own email address, they get defensive and tell me someone else made a mistake.
Buddy, this email was was an automated response from a computer after you signed up for something. No, it did not just randomly decide to send to my @gmail instead of your actual @yahoo address. YOU just don't know your own email.
If we didn't have a monoculture in email providing, this would be far less of an issue.
"Hi X. The £80 million for the new biomedical building is approved, please make the transfer ASAP."
It turned out I had the same unusual name as the most senior financial officer.
That's why you get send the verification email first, when creating the application user, and don't do anything until the email is verified.
The flow should be:
User: Please give me an account; my email address is jim@example.invalid
Server: I have sent an email to jim@example.invalid
Server → jim@example.invalid: Please go to https://server.invalid/register?token=KDU6dG9rZW4xOWppbUBleG...
User: visits URL, completes registration
Not to the extent of the above, but for instance, last year I received someone's job offer in Colorado. I did respond to the sender to let them know of the mistake of course.
Seems like the simplest solution is to have some basic password requirements.
You do. A lot of users don't consider automation when it comes to people hacking their account. I've heard "Nobody will ever guess it though" a few times during my career.
What attack vector is a password with high entropy protecting against? The only one I can think of is an unreported database leak. The attacker may be able to more easily reverse the password hash and use your account on that particular service, at least until the leak becomes discovered and the service does a full password reset.
While it would be ideal to defend against that attack, I think it's far more important to stress that users have a different password for every website. The real attack vector that we see every day is a DB leak from a poorly secured website, passwords cracked, and then reused on important services. That's where the problem lies, not in the user's password entropy.
Jeff isn't wrong here, he's just attacking a relatively unimportant problem.
I'm no security expert, but I start to wonder if the "practical" entropy of a given password is actually much higher than the theoretical entropy numbers people derive.
Serious question: when is the last time anyone has had an account compromised because of a weak password?
What is your definition of "weak"? I sometimes help my landlord fix their computer when they accumulate too much malware. One time I brought their tower home to do this and didn't get their Windows account password. Instead of calling them I decided to try a few things first, including their kids' names. Lo and behold, the second attempt was correct.
Brute forcing a weak password probably isn't what you have to worry about when it comes to targeted attacks against weak passwords, but social engineering is.
Come to think of it, I also had an old account with a very weak password that I hadn't used in years mysteriously hacked one day. The language settings were changed to Russian when I went to reset my password. The fact that no other account of mine appeared to be compromised and I hadn't used the site in years certainly suggests brute forcing.
Very many people. And not all systems stop them from doing so.
And database leaks happen all the time too...
Do you run any ssh or email servers? If so, your logs will tell you already. I've got bots brute forcing passwords on my blogs, that nobody even read, but did have account functionality, with email sending. People made the point of adapting their bots for different captcha schemes just so they could send some email.
There's a difference between random script kiddies and targeted attacks. People do all sorts of wacky things.
Weren't the celebrity iCloud account compromises due to Apple neglecting to rate-limit a certain authentication API endpoint, allowing the hacker to brute force passwords online?
Also, doesn't some of the current crop of IoT malware brute force device passwords as well (after trying the defaults)?
Login using the root account is disabled.
It's not an illusion, 1q2w3e4r5t is indeed better than aaaaaaaaa, even if it's just the numbers interleaved with qwerty (and probably easy to brute force generate up to it).
>if I use "aaaaaaaaa" as a password on a website I know full well what I'm doing. So why even bother?
Because not everyone who uses "aaaaaaaaa" (or "1q2w3e4r5t" for that matter) knows "full well" that it's insecure?
"COMMON PASSWORD: IN THE TOP 9635 MOST USED PASSWORDS
Your password is very commonly used. It would be cracked almost instantly[1]"
I do realise there's a difference between cracking a local system password vs a website password but always assume a site's database is going to be leaked at some point
[1] https://howsecureismypassword.net/ (Don't go putting real passwords in there..)
47 TREDECILLION YEARS to crack your password
Why not create even stronger passwords with Dashlane? It's free!
I didn't know that was a number!
It's a password that I postulate is more secure that the average and yet is only made of two different symbols and would've been rejected by the proposed "x amongst y" character policy.
It's a bit far fetched but not that much, you'll notice that the pattern is simply the first digits of pi, so it's fairly easy to remember. And the letters are "Hn", like hacker news.
That's my point, really. If you think you know better than the user how to pick a password, then just do it. Otherwise don't get in my way, you don't know how I generate my passwords.
Only they don't need to know how YOU generate your passwords. Just how most of their users generate their passwords. The suggestions and rules are not there to protect computer scientists from entering bad passwords...
I feel like the solution to everything in this thread is just to use zxcvbn and stop with the insane rules for things. In your two cases: the bank would disallow passwords below some limit while the blog would just show you a warning (in case you were ignorant of hacking enough to know that "aaaaaaaa" wasn't a good password), but let you use your awful password to spare you from having to remember it.
In this case, we're talking 'better' but still bullshit [1]. Calling it 'better' makes no meaningful distinction whatsoever in practice.
[1] https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht...
Surely that's a cop-out? If the user getting their data stolen is not a big deal for you, why bother securing any system at all?
The reason service providers set password rules is because there are many, many people who do not understand what a good password is, or the risks associated with losing them. There are people out there using the same password for everything, unaware that the compromise of one service can spell doom for their financial life.
Developers really need to start taking responsibility for their code. Setting password rules, while arbitrary, are about protecting users. This may upset those who are tech-savvy and know what they are doing, but that really weighs nothing compared to the benefits it brings to those who are not.
It is weird that he goes on to suggest a complex system of rules literally right after saying rules are bad, and that's the point where he lost me too.
If users don't understand what a good password is, they are going to eventually get an account compromised somewhere, if not on your site, then on another. In cases where there's no liability back to you, then there's no sense in babying them. If you do have liability, then two-factor authentication is probably a better way to go.
I personally would hate it if a company forced me to use their generated passwords because I like to manage my own passwords.
However I take offense at the notion of "babying" users. We are all babied in some aspect of our lives: if it weren't for the active work and intervention of those in other fields, we wouldn't know whether the food we eat is safe, or if the roof isn't going to collapse during the night. I'd like developers to assume some responsibility for their users in turn.
But I concede that may be beside the point in the case of password rules.
Also, the big question that's missing from the article is: who's the enemy? If the enemy are Russian genius hackers, then certainly very long passwords and maybe other measures are in order.
But the enemy is not always remote. I just bought a new iPad and had to reset my password and so-called "security questions".
In my experience, there are only two kinds of security questions: ones I don't know the answer to myself, and ones everyone around me knows the answer to (what was your first job, what was your surname when you were a child, etc.)
The problem is, in the case of the iPad, your enemy is not some James Bond villain in a cave in Ukraine, it's your 13 year old child who wants to use your account to buy apps, or your spouse during a nasty separation. And they both know, or can guess, answers to "security questions".
What I do personally is type random things as the answers, and write them down somewhere. But that doesn't improve security, it weakens it.
"What is your mother's maiden name?" - "gHk899iL@"
Oh, and they referred to these security questions as "2FA."
I love the ones that ask about one's favourite sports team (not everyone likes sports), or first girl (or boy) friend (not everyone has dated) or first car (not everyone has ever owned a car).
https://www.united.com/ual/en/us/account/enroll/default
Derp.
My solution is just to keep those answers in the "extra notes" section of my password manager.
So-called "security questions" are the dumbest security measure.
It weakens it to the extent of your physical security. But in practice how many crackers are breaking in to your flat [aka condo] to find your written down security responses, unless you're famous - or a target some other way (politician?) - in which case you should have sufficient physical security to protect the written answers.
Having security questions allows users to use hard passwords without the problem of losing an account. It increases the risk of personal attacks, for sure, but I'd warrant the chance of personal attack [ie by someone who knows you (or has gone through your bins)] is minimal for most people vs. the chance of an automated online attack.
I think it's right to minimise the online attack surface at the risk of the offline one for most users.
If you are willing to be brave about this then the best way of answering security questions is by typing a random string and NOT writing it down. You will never need that value again.
Today, years later, I still can't login to the damn payroll site because there isn't a procedure for just completely resetting the password state of the account and it wouldn't let you log in without those extra things.
Since that point I have recorded every annoying split-password (that's what the 'security questions' actually are, a forced split in the single real password)...
Totally agree about the "security questions". They're just insecurity questions. Everyone knows what street I used to live on and what my previous phone numbers were.
Regretfully Apple has an annoying bug that the dialogboxes accepts 5-word phrases, but only remember the first 32characters, 3 words or something alike. Very stressfull when you’re trying to recover a password.
[1] http://www.barclays.co.uk/Helpsupport/UpgradetoPINsentry/P12...
[FWIW I expect the reverse situation is probably the same, this is just my anecdotal experience].
> Verifiers SHOULD NOT impose other composition rules (e.g., mixtures of different character types) on memorized secrets.
> When processing requests to establish and change memorized secrets, verifiers SHALL compare the prospective secrets against a list that contains values known to be commonly-used, expected, or compromised. For example, the list MAY include (but is not limited to):
> * Passwords obtained from previous breach corpuses.
> * Dictionary words.
> * Repetitive or sequential characters (e.g. ‘aaaaaa’, ‘1234abcd’).
> * Context specific words, such as the name of the service, the username, and derivatives thereof.
I suppose you could open a pull request :) https://github.com/usnistgov/800-63-3
There's no substitute for length. "dog" is a bad password. "doooooooooooooooog" is much better. The entropy is still the same, but the latter takes much longer to brute force and is just as easy to remember.
Of course one should not use passwords one can remember for anything critical, but many passwords are for services where compromise is not a big deal.
We need to make passwords a much simpler thing to manage so that people don't create a bigger problem by putting it on post-its on their monitor. What I'm suggesting would take some effort but is where we need to go. Your username is your fingerprint. You won't forget that and it is very hard to fake/brute force. (Your phone already has one and a usb one for you computer would be trivial. A lot already have them.) Your password is always just 8 characters, alpha numeric only (62^8 is plenty big) and you must have 2FA on. It would be trivial for the phone manufacturer to add that at the OS level and it could be visible on your lock screen. Also, finally a good use for a smart watch. The rules are simple and you have removed the biggest security hole most companies have: people. Just my two cents....
So fingerprint gives you part 2 and password gives you part 1.
No need for an additional MFA device.
That's you. The average user thinks 'nobody will guess this password'. In other words don't assume they know about brute force attacks, rainbow tables, most common password lists and a host of other things that they haven't thought of or don't know even exist. They don't even know the complete group of actors that could potentially breach the account.
Yes! Please. Let users determine the value of their accounts for themselves. If I decide that say, my HN account isn't valuable and use a common password that is shared with many websites, I know the risk I'm taking and I'd rather take it than have to mark down a unique password for HN.
On sites I write I advocate for no password rules at all (hit enter is good enough for me, yes we can hash an empty string), have usually compromised on a simple length check.
Proper password storage is important, use the latest bcrypt/scrypt/argon2, don't cheap out there. You can cheap out on password rules. If you want to write a fancy entropy checker, run it client side and tell the user how secure their password is, let them choose whether they want that or not.
Nothing makes me immediately dismiss a site or piece of software faster than nannying me, especially from go.
"So I send it to my mail account for when I am on the go... that account with the qwerty password..."
The point being, you can't really protect users from themselves so a bank can't build it's security model upon the assumption of safe user accounts.
I've since had to change my random generator to avoid 3 of a kind, which actually makes it less random/secure i believe.. pruned some branches off of the search tree.. especially since i've now told everyone ;)
I don't want to trust a bank who knows my password.
[1] https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
They force you to come up with a new password that you probably haven't used before and so you will probably forget it.
There are websites that I don't use often where I literally have to reset the password (and go through all the i-forgot-my-password steps) every time I want to log in because they forced me to come up with an overly creative password.
I think most people have two or three passwords for all their apps/services; one very secure one, one medium security one and one low security one (where you literally don't care if you get hacked). It's not the company's business to tell you which of those classes of passwords it deserves for its website.
I think the future will be passwordless with biometric as a added layer of safety.
* Go to some service A.
* Get redirected to SSO and authenticate.
* SSO confirms your identity and A issues you a session token.
* You log out using your SSO.
* Go back to A where you're still logged in with your session token.
At a certain point I would not be willing to commit to maintaining lots of patches to every product we host and just tell our users to close their browser.
Indeed and then one's email potentially becomes the weakest link in one's password security.
This was exactly my point yes :)
Best to just use a password manager and keep unique per-site passwords.
Password managers are horrible - Whenever I change machines, I could never remember all my passwords and I certainly don't want to store my passwords in the cloud.
1Password can sync locally which is a nice plus:
https://support.1password.com/wlan-server/
But you're not. You're storing an encrypted blob in the cloud. You just need a good master password and a password manager that isn't broken.
Of course, it's a different situation when e.g. managing many sensitive servers which you only access from work or so.
True, though your handful of passwords can be stolen in the same way.
With a password manager, you:
- ensure your master password is not transmitted over a network
- ensure you never reuse passwords
- ensure you have long, strong passwords everywhere
- never forget login details and never worry about remembering yet another password
On the other hand,
- you _need_ access your password manager in order to login
- you now have a single point of failure
- cloud-based password managers are very attractive targets for hackers
I don't like these aspects of it.
Still, a password manger is incredibly convenient and I do feel a greater sense of security/confidence when I copy a big old 64 character password to log in. As it is, I use so many different services (gmail, github, slack, aws, steam, dropbox, reddit, etc, etc) and that number is only going to increase. I think a password manager is a practical, scalable solution to both remembering login information and improving my security.
I don't have to deal with password managers, maintaining their files. Or deal with multiple passwords.
1) Forgot the password, start the recovery process.
2) Get to the "create a new password" phase, look at the rules.
3) Rules require special characters, caps, etc. So I make one.
4) I get the "This password has been used before" error.
5) Now I have to think up a new random one.
If that password 'that was used before' was the current one, why can't I just continue to use it??? Now I remember the password (usually because of the silly special character requirements), so we're good, right? Wrong.
To add to the bullshit, it is so common that a site will have some idiotic rule (like "must include a number," "must have at least one lower (or upper) case letter," "must include a special character," "must not include any of these special characters," "must change password every 30 / 45 / 60 / 90 days"), that I don't even get mad about it anymore. I can't even spend the mental energy to send them an email.
Whew, thanks. I feel better now.
from a security standpoint. I hate the required special characters BS, especially since other sites will explicitly restrict you from using those same characters. Seriously, without a password manager of some kind I don't know how people can function online.
- if the system uses a login + password scheme: 12 chars min and mandatory mix of all among non-caps/caps/digit/special
- if the system uses a login + password + time-based exponential backoff rate limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 10 tries or a bot detector such as captcha: 8 chars min and mandatory mix of 3 among non-caps/caps/digit/special
- if the system uses login + password + environmental information (such as IP or MAC addr, etc...) + time-based exponential backoff rate limiting with a baseline of 1 min after 5 tries maxxing at 25 per 24h or lockout after 5 tries or a bot detector such as captcha: 5 chars
- if the system uses login + password + hardware second factor (SIM, U2F, YubiKey...) + lock out after 3 tries: 4 chars
To fend off in-transit and offline attacks, the document suggests that auth should transit sufficiently encrypted (using a cipher or method currently recognised as strong and non-vulnerable) and passwords should be stored obfuscated using a secure (similarly defined as strong and non-vulnerable) one-way cryptographic function with salt (and possibly pepper since they mention a "key", which makes no sense for one-way crypto functions).
[0]: https://www.legifrance.gouv.fr/affichTexte.do;jsessionid=DCF...
P a s s w o r d 2 0 1 7 .
Using a password manager isn't always an option either - there is a vast amount of infrastructure, much of it corporate and nearly immutable - that simply presents the user with a password prompt and expects them to get it right.
It's only recently that some password prompts even let you view the password you've typed. With a terminal, you get no visual feedback at all.
https://security.stackexchange.com/a/33471
Edit: and if you speak German, there is a short film about passphrases: https://passphrasen.de/
To make matters worse, the email looked just like a phishing attempt. Right down to having you download some html attachment, which, after it opens, directs you to click on something which finally takes you to the "secure email". The whole process felt like something a scammer would come up with, and is really not how banks should condition their customers.