What about forcing some set of users to change their password if it shows up in a breach?
Why [Insert Thing Here] Is Not a Password Killer
191–200 of 277 posts
Re: Why [Insert Thing Here] Is Not a Password Killer
#192Earlier quoted context omitted.
Exporting the passwords is also possible, so it's not really much lock-in. Not to the kind of person who'd care, and want to switch browsers.
You got it backwards. Vendor lock-in rarely applies to experts. It is the people who "don't care" that _we_ should care about protecting from lock-in. After all, that is how we got internet explorer 6.
Those, in my experience, are the same people who can't switch browsers. They aren't capable of learning new things, and can often barely keep going with what they have.
Re: Why [Insert Thing Here] Is Not a Password Killer
#193Earlier 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.
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…
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#194Earlier quoted context omitted.
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…
> 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. This has been tried. While it initially sounds appealing, it is a monumentally terrible idea. * You need software to impl…
> * If a site stores password data in cleartext or weakly hashed, your master password/passphrase can potentially be cracked.
It all comes down to the threat model you are defending against. The threat model I'm defending against is automated attempts to catch me reusing the same password with different accounts.
Even if you were defending against a motivated actor putting human eyes on your passwords, something like`XXXXXXsXXXXXXsssXX` where the X are reused across sites and the s is a derived, site-specific chunk is a) as good as completely random until your adversary is manually correlating multiple leaked passwords for you and b) not trivially obvious to derive once they are correlating multiple leaked passwords.
Re: Why [Insert Thing Here] Is Not a Password Killer
#195Earlier 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.
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 suppor…
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.
Re: Why [Insert Thing Here] Is Not a Password Killer
#196Why I like passwords (and various key locked/unlocked with passwords? Simply because I can change them, I control them.
Biometrics is unsafe by design because our body can change outside our control and our body is public enough and unchangeable enough to be a REALLY unsafe authentication system for anything but human being interacting together.
External other-factor auths like OTP, side verification, port-knocking, ... are good, but they still need a password somewhere in the chain.
So no, it's not only a matter of reactionary users not willing to change but also a matter of rational safety reasoning.
Re: Why [Insert Thing Here] Is Not a Password Killer
#197What about forcing some set of users to change their password if it shows up in a breach?
Troy hunt created a service for this. He provides an API where you can securely check if a user's password is pwned without revealing the password to his server.
He's written about it several times, here's one of the posts: https://www.troyhunt.com/enhancing-pwned-passwords-privacy-b...
Re: Why [Insert Thing Here] Is Not a Password Killer
#198Why I like passwords (and various key locked/unlocked with passwords? Simply because I can change them, I control them. Biometrics is unsafe by design because our body can change outside our control and our body is public enough and unchangeable enough to be a REALLY unsafe authentication system for anything but human being interacting together. External other-factor auths like OTP, side verification, port-knocking,…
When current bio-related credentials are stolen, they're not stealing your hand or your iris or your face.
They're stealing destructive hashes of those things.
It'd be like having someone sketch a stick figure version of you, and then you claim your identity was stolen.
No, it wasn't. Stick figure drawings only work in stick figure readers.
Re: Why [Insert Thing Here] Is Not a Password Killer
#199Earlier quoted context omitted.
Except that people won't be able to remember them, so expect massive churn when it's time for them to enter the password the very first time.
Just set a never-expiring authentication cookie in the browser, so they never need to enter the password in typical one-device use. When they need to change devices, have the standard e-mail based password reset as well as "show password" in the account settings (make the password reset not reset login, unless the user explicitly elects to "log me out on all devices").
If you're doing that, you might as well do the "magic email" link as medium does now (and as mozilla's now-defunct 'persona' did [0]). In that case, you don't have any passwords at all, merely long-lived tokens which the user mints by using a unique one-time nonce in an email link. To login on a new device, they get an email and click a link, and that's it. No passwords ever.
[0]: https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Per...
Re: Why [Insert Thing Here] Is Not a Password Killer
#200Earlier quoted context omitted.
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)
I'm not certain regular users will, but I do believe that this should probably be practical knowledge that could be taught in schools considering the far reaching impacts of having financial accounts or email accounts hacked.
Alternatively teaching about the use of password managers might not be a bad idea.
But digital literacy should certainly be something that our society focuses on teaching it's young adults and keeping your accounts secure is one big component of that.
But considering our schools don't teach us about credit scores, and a myriad of other very useful things that can impact you in large ways down the line, I guess I'm not so hopeful.