Live data from Hacker News

Why [Insert Thing Here] Is Not a Password Killer

troyhunt.com

171–180 of 277 posts

Re: Why [Insert Thing Here] Is Not a Password Killer

#171
post #5

It is not just that everyone knows how passwords work. It is also that you can always enter a password. What if I don't have my phone to scan a qr-code? What if I want to use a minimalistic browser that doesn't implement a key pair store and I don't want to or can't set up one external? What if my minimal browser is text only? What if I'm on another device and don't have my stuff on there? I will pretty much always b…

"It is also that you can always enter a password."

You are correct, as long as you throw out all the other password advice that, ironically, Troy Hunt has given us about not reusing passwords, making them long or full of hard-to-memorize characters, etc.

Once you use secure passwords by making them long and/or hard to memorize, unique for each website, etc., you can't just rely on your brain, fingers, and an awkward on-screen keyboard to "always enter a password." You need your password manager with you, you need privacy so nobody can shoulder surf while you agonizingly peck out your password on your touch screen keyboard (remember everyone learning Kanye's cell phone password recently?), etc.

Your statement about universality is only technically true.

Re: Why [Insert Thing Here] Is Not a Password Killer

#173
post #171
post #5

It is not just that everyone knows how passwords work. It is also that you can always enter a password. What if I don't have my phone to scan a qr-code? What if I want to use a minimalistic browser that doesn't implement a key pair store and I don't want to or can't set up one external? What if my minimal browser is text only? What if I'm on another device and don't have my stuff on there? I will pretty much always b…

"It is also that you can always enter a password." You are correct, as long as you throw out all the other password advice that, ironically, Troy Hunt has given us about not reusing passwords, making them long or full of hard-to-memorize characters, etc. Once you use secure passwords by making them long and/or hard to memorize, unique for each website, etc., you can't just rely on your brain, fingers, and an awkward…

I'm not sure it has to be so difficult. It took me about an hour to come up with a scheme for creating long, unique, and random looking passwords that are very easy to remember.

Basically I have a prefix of length 7 which is two words, where some of the letters get converted to numbers, and then I use shift to make them into special characters.

Then for each website I append a different word that has some meaning for me, and convert the letters to numbers. Then I add a special character at the end.

A typical password might look like

P!^^w)r$M19175r?

Which is very easy for me to remember and type, reasonably long, and certainly not on any lists of most commonly used passwords.

Ways you could improve this method would be to have different prefixes for different industries (banking, social media, etc).

Re: Why [Insert Thing Here] Is Not a Password Killer

#174
post #95

Earlier quoted context omitted.

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#175

Earlier quoted context omitted.

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.

Re: Why [Insert Thing Here] Is Not a Password Killer

#176
post #151

Earlier quoted context omitted.

As opposed to "Oh, they want a password? I guess I'll use the same one I use for every other website." I agree that the business makes the decision, growth is the top priority and friction reduces growth, but in reality this is how most of the world already works. If you rent a hotel room you don't get to provide your own key and if you lose their key then you must prove who you are to get another one issued. In the…

Your hotel example is pretty absurd, because there's no friction involved in carrying around a hotel room key. There is significant friction involved in memorizing a long password. So no, it's not "how most of the world already works".

I will admit that it's not quite equivalent, but there was a learning curve that happened when hotels switched from metallic keys to magnetic keycards. I don't think that it's absurd.

I guess a more direct example would be an employer trusting you with the combination of a safe. You would need to remember the combination which presumably would be changed periodically.

The point I think I'm trying to make is that it's rare for a business to leave the responsibility on the consumer to secure the property of that business whether it's access to a server, a hotel room, or a safe.

Re: Why [Insert Thing Here] Is Not a Password Killer

#177

Earlier quoted context omitted.

And now that person is forever locked in to the browser they were using at sign up time. What happens if they move from Mac → Windows or Android → iOS?

Or use more than one device to login?

All major browsers can sync their passwords across their desktop and mobile versions. I use Firefox Sync on two laptops, one desktop and an Android phone.

Re: Why [Insert Thing Here] Is Not a Password Killer

#178
post #173
post #171

Earlier quoted context omitted.

"It is also that you can always enter a password." You are correct, as long as you throw out all the other password advice that, ironically, Troy Hunt has given us about not reusing passwords, making them long or full of hard-to-memorize characters, etc. Once you use secure passwords by making them long and/or hard to memorize, unique for each website, etc., you can't just rely on your brain, fingers, and an awkward…

I'm not sure it has to be so difficult. It took me about an hour to come up with a scheme for creating long, unique, and random looking passwords that are very easy to remember. Basically I have a prefix of length 7 which is two words, where some of the letters get converted to numbers, and then I use shift to make them into special characters. Then for each website I append a different word that has some meaning for…

Yes, there are this and myriad other schemes to accomplish the same thing.

This doesn't much help the average customer service worker who struggles to give correct change if you hand them cash in an amount that's not a round number.

Passwords are a thing that need to work for everyone, which means they need to work for the lowest common denominator too, which means the GP is correct to point out that password advice is contradictory: the lowest common denominator cannot both use strong, unique passwords and avoid using some other kind of technology to assist with that.

Re: Why [Insert Thing Here] Is Not a Password Killer

#179
post #173
post #171

Earlier quoted context omitted.

"It is also that you can always enter a password." You are correct, as long as you throw out all the other password advice that, ironically, Troy Hunt has given us about not reusing passwords, making them long or full of hard-to-memorize characters, etc. Once you use secure passwords by making them long and/or hard to memorize, unique for each website, etc., you can't just rely on your brain, fingers, and an awkward…

I'm not sure it has to be so difficult. It took me about an hour to come up with a scheme for creating long, unique, and random looking passwords that are very easy to remember. Basically I have a prefix of length 7 which is two words, where some of the letters get converted to numbers, and then I use shift to make them into special characters. Then for each website I append a different word that has some meaning for…

Do you really think regular users will do anything remotely close to this? Based on my interactions with normal/regular users, the chance for this to happen at any meaningful scale is zero (0)

Re: Why [Insert Thing Here] Is Not a Password Killer

#180
post #149

Earlier quoted context omitted.

I don't believe so, I remember learning about Public Key Infrastructure a while ago. It's one of those things (kind of like git) where there is a steep learning curve up front, but once you understand it seems simple. A password manager on the other hand is just a place to store credentials. Credentials is a concept that most people understand. A password manager in this context could be as simple as a text file on y…

Ok lets compare these approaches rationally, especially from a user perspective. If you let the service provider choose/generate the password it might as well generate your keys for you, there really isn't much of a difference. From a credential management perspective there really isn't a difference either between a long non-human readable password and a long non-human readable private key. They basically suffer from…

I understand what you are saying, but the fundamental difference here is that for PKI, the browser has to be configured properly as your key pair must exist and the correct public certificate must be used in TLS negotiation. The advantage here is that the password can be copy and pasted into a password form after TLS has been negotiated.

Coupling authentication with encryption has its place, but I would think that it would work better when accessing a service through an app rather than a browser since the app publisher can create unique a key pair and sign the certificate with their own CA and use that for authentication, but in the context of a web app accessed through the browser copy-and-paste beats having to configure your client certificate per domain at least from a "user friction" point of view.

Post reply on HN