Hacker News Reader

Comment by jrockway | Hacker News Reader

> Despite it's [sic] many flaws, the one thing that the humble password has going for it over technically superior alternatives is that everyone understands how to use it. Everyone.

I think the problem is that people don't understand how to use passwords. They will reuse them among sites. They pick easily-guessable and low entropy ones. They will type them into any website that asks. The end result is that not much security is provided.

(Things are just as bad on the server side, of course. Developers store them in plain text. They will email them to you. They delete entropy so that you can use your password to log in over the phone or from a computer terminal that apparently only has capital letters. I've even seen a website where the password is sent to the browser and the password checking happens in Javascript. Not great guys, not great.)

View on HN

> I think the problem is that people don't understand how to use passwords

From the looks of it, neither do the authenticators. The capital letter + symbol + number requirement had led to the current predicament. Just asking for really long passwords would have been a lot better.

As it stands, people either use a predictable string of num-symbol to satisfy requirements or remember that one strong password,.which qualifies for all of the above.

Software like Lastpass are great, but I don't always have access to them. They also make all of my.online security have a single point of failure.

I think it would be a lot better if companies just changed password requirements to a decently large length eg: min 20.

This eliminates the likely hood of password like abc123, qwerty and the oh so lovely "password".

Just by itself, long passwords will result in people using "franklymydearIdontgiveadamn" and other things susceptible to a dictionary attack.

Long passwords plus a bad password check (https://www.troyhunt.com/ive-just-launched-pwned-passwords-v...) might suffice. However, without that check, I suspect requiring special characters marginally improves entropy in practice.

Pretty much everybody I know and asked in the office just sticks some punctuation at the end, e.g. "Passw0rd$". IDK how much of an "improvement" that is, compared to e.g. 4 extra characters.

That's definitely a thing, and you're right, it doesn't add much entropy (people choose from a few numbers, a few special characters, not that many substitutions). Four extra characters that are truly random (even just out of 26 letters) is way better. However, that's not the alternative I'm worried about. I'm worried about people using phrases that will be in the first few thousand entries in a phrase dictionary.

And that's still better than a crappy, short password. I use lyrics, quotes, etc for my important passwords (password manager, email, etc), and my passwords are >20 characters (usually >30) and really easy to remember (and I can secure it by placing one extra symbol in there).

The attacker doesn't know what I'm using for my password, so they have to attack all valid combinations up to the max length the server supports.

Song lyrics are not safe https://arstechnica.com/information-technology/2013/08/there...

I don’t know exactly where the breakeven point is, but there is some point where a song lyric or other phrase provides less entropy than a relatively short password.

Bottom line: use a lot of random ascii characters(at least 14 or 16, or 4 random words) and you’re probably set. Use less, or a found phrase and it’s not good.

You can't talk about safe without a threat-model, especially distinguishing between whether you're trying to prevent offline attacks against stored data or brute-forcing a running login system. If you can rate-limit many things are fine, especially if you have some confirmations at key points (“Your account was just accessed from …”) with restrictions which make it hard for an attacker to permanently wrest control of the account or incur large costs immediately after gaining access — think about how Amazon.com doesn't require 30 character passwords because adding a new shipping address requires you to re-confirm the credit card information first.

That's definitely true, though you can simplify matters by saying "I'm always going to try to have passwords that are safe against offline attacks".

I would ask what’s the cost benefit ratio for defending against offline attacks with increasingly unpleasant password requirements versus things like increased KDF rounds, general server security improvements, and the defense in depth measures which increase the costs of actually profiting from a user account compromise.

I think we’ve historically been shaped by classic Unix crypt() memories where something couldn’t easily be fixed without breaking compatibility even though that era is largely in the past.

I see how this wasn’t obvious, but I never actually said anyone should implement any particular password requirements, just that certain requirements might not increase entropy as much as you might think.

My above comment about offline attacks was my personal stance/ideal: I use a password manager for just about everything, not something I’d mandate.

As a developer, in many contexts I might implement min 8 chars with no special char requirements. I think the bad password check is also a good idea.

People aren't good at memorizing long lists of things, so just requiring long passwords isn't sufficient unless you are willing to also allow everyone to use the same password everywhere, and that's worse than the single point of failure problem than password managers because that's a distributed point of failure (just one breach of any site/application that you use; your security there is only as good as the weakest link).

>People aren't good at memorizing long lists of things

It's much easier to remember a 40 character passphrase of real words than a 12 character password of random symbols including punctuation

A 40 character password of real words is usually easier to crack than a random 12 character string, though.

Citation needed (that sounds wrong without seeing the maths).

But also missing the point. It just has to be better than the usual 8 + some punctuation at the end that most people resort to when faced with these shitty, asinine password rules.

English words are ~1.5 bits per character, random ascii garbage is ~6.5 bits per character.

It really starts to depend on the details. If there are 10,000 words and you use 5 of them, that is 1.1x more than 12 characters where you only use lowercase letters, numbers, and shifted numbers. Tweak the allowed symbols, length, and your dictionary and you can make either one look better than the other.

I think there are probably less than 10,000 words that people would choose for their password, and that people use capital letters... maybe, but don't use 12 character passwords (8 more reasonable) so it could really go either way.

Yes, but it doesn't solve the problem of memorizing a list of 40 character passphrases for every single website/app that you use. Length alone as a password strength requirement is not sufficient. Length alone only further encourages password reuse, because people won't memorize more than one or two passwords, especially as they get longer.

screye is almost certainly referring to XKCD-style passwords, like "correct horse battery staple" [1] which are memorable and comparatively high-entropy, but don't have symbols or numbers.

[1] https://xkcd.com/936/

Yes, one is memorable, which is why it is a great password for your password manager of choice. Again, the problem is if screye is advocating that password managers are a "single point of failure" and that length should be sufficient: people don't have the mental hardware to remember an XKCD-style password for every single website or application they use.

The problem with that is that in quite some cases I don't care about the security so I can just use a crap password.

But a sufficiently long password could literally just be 'a', repeated. Would that really be more secure?

Honestly if you want somebody to have a secure password, make it for them and e-mail it to 'em. Virtually no chance they are going to use it for anything else, and if somebody has their e-mail, they can recreate one anyway.

> I think the problem is that people don't understand how to use passwords.

They do understand it. They just trade security for laziness.

Exactly. The thing is, they keep doing it because... it works.

The vast majority of the time, for the vast majority of people, it never results in any issue at all. And solve plenty of their problems.

Agreed.

I've tried educating non-technical friends and family about insecure passwords and how random long strings are more secure. Their responses are:

1. "I can't remember that password! / I don't want to type that!"

2. "I'm a nobody, hackers wouldn't be interested in me. My account has no interesting data." [explanations about botnets doing damage to others go way over their heads]

3. "If someone REALLY wants to hack me then I can't stop them anyway."

They think that the inconveniences of secure password practices are not worth it.

I don't think a password manager will solve it for them. Especially older family members are "afraid of technology" - they are constantly worried that they will break something, and when something is written on the screen 9 out of 10 times they have no idea what it means. I have enough trouble explaining how copy-paste works — I don't think I can explain them what a password manager is, or how to keep in in sync across their devices, let alone convincing them to pay for such a thing.

I've tried the low-tech way. Advising them to use XKCD-style password and writing them down on paper. The result: they keep passwords over multiple pieces of paper/notebooks and they always lose them.

I've resorted to PMaaS — Password Management as a Service. In other words: I dictate what passwords they use, and I manage it for them in my password manager. Their login method is to call me to retrieve their login credentials.

This does not work, you're a single point of failure. If you say, get sick, family members will override security.

Nice try though. I'd recommend an actual password manager instead. Authenticated with biometrics and a simpler local password.

Your service does the same, using voice and phone number as biometrics. (Perhaps with recovery question.) Feel free to replace it with sufficiently advanced AI.

Please, try to be in my shoes. Even teaching copy-paste is so difficult, how do you want me to teach them biometrics?

The "I'll manage all your passwords for you" is the only solution that actually works. The ONLY other alternative is that they use 123456 as password everywhere. I already explained why I can't get them to use a password manager.

So what if 123456 is a sensible password for them? Explain them why they should use a more secure password. If they don't get it's maybe they really don't need a more secure password (they don't care who has access to their accounts, and the likelihood of them being hacked is very low).

People get killed every day making similar assumptions with automobile safety. The ability for a person to "get it" is not a good indicator of their susceptibility to harm.

What about going back to the notebook idea? You give them a notebook that's called 'Passwords' and it sits on the desk beside their computer. They only write passwords in that notebook, and you can explain to them to write at least 20 random numbers and letters for new passwords.

When you visit, you can write those passwords down in your password manager. This way if the book goes missing or there is a disaster, you have a backup.

They lose the entire notebook. The thing is, they only need login credentials a couple of times a year or so. Things like social media and email are apps that are logged in all the time so they only need to reauthenticate when something is wrong or when a special event happens (like buying a new phone). So that only leaves a thousand different boring things that they only rarely access, like the government ID, the utility company account, the insurance company account, etc. So every time they have no idea where that particular notebook is among their tens of other notebooks, pieces of papers etc.

> They think that the inconveniences of secure password practices are not worth it.

And they're probably right from their own perspective.

I honestly don't give a shit about 90% of the services I sign up to that require passwords

I do this for sites that I don't particularly care about. My wife and I have something we call our default password and it's protecting our Hulu account, our newspaper login, our Pandora login, etc...

> They will type them into any website that asks. maybe off-topic but on many linux distro the prompt to unlock your keyring does not mention what application is asking.

i had a theory a few years back that human-chosen passwords would get simpler due to mobile keyboards. Not sure if anyone has compared leaked password dumps from before and after the great mobile-migration to see if that's happened or not.

Seems like a pretty logical theory. If you ever use a password manager on desktop and then decide you need to access the same service on mobile... well typing in that 20 character string of random characters becomes a real pain in the behind.

Though it's also quite likely a lot of users don't even remember their passwords at all now and just use password reset every time they want to log in.

Why is it not great for the password checking to happen client-side? What is the security risk? You can do client-side hashing safely as well.

I presume GP is talking about the plaintext password, not the hashed one. If plaintext, then every client gets to see the password so they can use it on the second attempt. If hashed, it still leaks more information than is otherwise necessary, and opens the door to rainbow tables (if inadequately salted) etc., since the server can no longer rate-limit validation requests.

Sorry but I'm still not really following...where is the leak if it's hashed client-side? And the client will see the plaintext password regardless of whether there is processing or not.

I guess what I'm asking is this: can someone walk me through the attack scenario? I don't really get it.

Consider: Mallory wants to access Alice's account on a website.

1. Mallory enters Alice's username and a random password

2. Website sends back Alice's plaintext password to be checked client side

3. Mallory inspects network traffic and retrieves Alice's plaintext password

It's also bad if the hash is sent back; now Mallory can run all sorts of attacks on the hash itself without worrying about rate limits or any other protection the site operator could implement.

Wait why is the password being sent back by the server to the client? Is that what the commenter originally meant?

If that's the case I completely misunderstood what they meant by processing the password with JavaScript. What you've described is insane; I thought the critique was in regards to processing a password locally before sending it to the server (e.g. local hashing).

I believe so. This was the original description (emphasis mine):

> I've even seen a website where the password is sent to the browser and the password checking happens in Javascript.

i.e. the server sends the (plaintext or hashed) password to the client, and the client verifies it locally.

Edit: the original commenter replied as a sibling to you: https://news.ycombinator.com/item?id=18382949

In the case I was talking about, it was even worse. The Javascript just set a GET param that said the password is OK. You can then log in as anyone with this method.

As I recall, it did send you the plaintext password too, of course.

Because if it happens client-side, then I can completely bypass your site's security by opening the dev console and changing `if (enteredPassword === correctPassword)` to `if (true)`.

Reply on news.ycombinator.com