Closest to a password killer I've used so far is the built-in iCloud Keychain. My iPhone and MacBook both have access to the same passwords and most of the are randomly generated.
Why [Insert Thing Here] Is Not a Password Killer
81–90 of 277 posts
Re: Why [Insert Thing Here] Is Not a Password Killer
#82Earlier quoted context omitted.
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#83It 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 generally always a trade-off between security and convenience. You can demand that a site allow passwords but you also aren't memorizing a 24 character nonsense password for each site login. The holy grail is can you bend the line and have something that is super secure and mostly convenient.
I currently work in an environment where I don't have access to a password manager, yet I am expected to have unique passwords for each service, and rotate passwords every month, and am not allowed to store passwords somewhere. Of course, this method requires you to remember more passwords than practically possible.
If all accounts would have sane restrictions on the password it would become trivial to have something both secure and convenient. I have been looking for a system that allows me to: 1. Does not require me to remember an absurd amount of information. 2. Allows me to login to services, even from other devices. 3. Has a unique password for each service (so that it is not disastrous if one password leaks).
We could have one master password, use site and username (and maybe a counter, to make it easy to rotate passwords) as salt, and use a hashing or password derivation algorithm to derive a unique password for each service. This would only require you to pick and remember a strong master password.
Re: Why [Insert Thing Here] Is Not a Password Killer
#84Earlier quoted context omitted.
pki is a barrier to entry for most. the user would have to set their browser up to present a unique key pair for each site they use. I think mutual auth is better suited to automated administrative tasks.
but isn't a password manager just as much of a barrier in this context?
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 your desktop (not a great idea), or the one included with your browser (a little better, but make sure you set a master password), but if you want more features there are more sophisticated options available.
Re: Why [Insert Thing Here] Is Not a Password Killer
#85It 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…
Medium is frustratingly guilty here. Your login choices are limited to sharing data with Google/Facebook/Twitter or clicking a magic link in an email. If you don't like to share your data with third parties then you are basically restricted to logging in on devices that have access to your email. Which means you're stuffed when that doesn't apply. Security at the expense of usability is fine when it's warranted. All…
What about a throwaway email? Does that leak device data?
(This whole thing reminds me of “Your post advocates a ... approach to spam. Your idea will not work. Here is why...” And maybe warrants a similar parody.)
Re: Why [Insert Thing Here] Is Not a Password Killer
#86Earlier quoted context omitted.
It is generally always a trade-off between security and convenience. You can demand that a site allow passwords but you also aren't memorizing a 24 character nonsense password for each site login. The holy grail is can you bend the line and have something that is super secure and mostly convenient.
I currently work in an environment where I don't have access to a password manager, yet I am expected to have unique passwords for each service, and rotate passwords every month, and am not allowed to store passwords somewhere. Of course, this method requires you to remember more passwords than practically possible. If all accounts would have sane restrictions on the password it would become trivial to have something…
I know that environment well, you pretty much have to come up with a hash function you can do in your head. Is it secure? Maybe you can pull it off. I think most people can't, and that's what leads to people writing down passwords.
Re: Why [Insert Thing Here] Is Not a Password Killer
#87I signed up for something recently and on the password screen it popped up with something along the lines of "Hey, can we generate a secure password for you, don't worry, your browser will remember it for you?" I said yes, sure enough a strong password appeared and Chrome offered to remember it. Seemed like a nice introduction to using secure passwords. The next thing I signed up for I manually generated a secure pas…
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?
Re: Why [Insert Thing Here] Is Not a Password Killer
#88Earlier quoted context omitted.
> I think the problem is that people don't understand how to use passwords. They do understand it. They just trade security for laziness.
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 h…
> They think that the inconveniences of secure password practices are not worth it.
And they're probably right from their own perspective.
Re: Why [Insert Thing Here] Is Not a Password Killer
#89Earlier quoted context omitted.
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…
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).
Re: Why [Insert Thing Here] Is Not a Password Killer
#90WebAuthn is coming. In fact, it's actually already here. There are only two things it needs before it can start to take over the world: a cross-browser, cross-platform implementation with synced credentials, and server-side implementations from a few large companies like Google and Facebook.
A cross-browser, cross-platform implementation with synced credentials will solve the one remaining usability issue WebAuthn has; the need for users to register every device with the site they want to sign up on. It's not acceptable for users to sign up on their PCs and then have to jump through a bunch of hoops to sign in on their phones; and bootstrapping with passwords eliminates many of the benefits of Web Authn.
Implementations from major companies will solve the chicken-egg problem that Troy mentions. Once the system is commonplace, smaller sites will be less hesitant to jump on board with an authentication solution that's different from the password-based one that users are used to.