Hacker News Reader

I think password managers could be easier to use, but that the fundamental problem here is, well, fundamental. The major security win of a password manager is that you end up randomizing your passwords across all your accounts; it does no good to "manage" a series of related passwords that will get credential-stuffed as soon as one of your providers has a breach. To get specialized passwords for all your accounts, you have to be able to reliably use the password manager on all your devices, which means not only configuring it and regenerating passwords the first time, but getting it to work again and synchronize it on every new device you use.

If you're motivated, you can get this to work. But people are not generally motivated.

Password managers are a thing I could confidently roll out as a security officer for a startup, where people are in effect being paid to take what I tell them about opsec seriously. They're not something I could confidently roll out in a campaign.

If you're going to get a campaign to do 2, maybe 3 things, you're going to tackle 2FA, phishing (security keys) and attachments (Chromebooks, iPads, and GDrive viewers). If you could do a 4th thing, I don't know that password managers would make that list.

(For the record, I did one training with Maciej, at an NGO, not a campaign, with rooms full of people who were, if not well-motivated, at least super respectful of our time and who had at least the appearance of being attentive to what we were telling them. And getting 1Password working for any of them proved hopeless. I think even I stopped being able to make 1Password work for a couple days after trying it with them. Unlike me, Maciej has a gift for talking to people about this stuff, and also unlike me, he did these trainings dozens of times. If the best password manager he could roll out was Notes.app, people who make password managers might want to figure out why that is.)

I want to be able to pass authentications from my phone to my laptop or tablet.

The interaction model seems better there, but there's so much missing integration.

What exactly does 'pass authentications' mean?

Apple has app handoff which does this. Or do you just mean keychain/password sync? Which most if not all the major password managers have.

What’s your opinion on the password management that chrome offers these days?

Browser password management is simply not enough. For one, they just save the terrible password that the user entered (the same password they use everywhere else, incl. their bank), they don't generate one. And sure it's really easy to use with websites, but what about apps? What about computer logins? What if the website changed their login domain? What if they changed to a 2-step form and it doesn't autofill anymore? What if you tried to change your password and the browser updated but the website didn't? (Hint: you need history.)

Browser password managers are terrible as soon as you inch a tiny bit off of the "happy path" and need anything above "autofill the same password I used last time".

Both Chrome and Safari generate passwords for you. In Safari's case, it also uses the OS/platform-provided secret storage and sync facilities, works in mobile apps, etc. I don't think you're accurately describing the current state of in-browser password management at all.

One of the things that made switching to a password manager difficult was the lack of a smooth and secure automation workflow.

Do you think a standard/protocol for communication between platforms and password managers would help solve this problem? Basically your password manager could hook into events from Android/Chrome/iOS like "login requested", "new account created" and "password updated" allowing increased automation from password mangers.

Obviously using lots of signing/certificates/encryption/platform verification(to become a registered password manager for chrome/iOS/android would require a much more extensive check than a standard plugin/app) to ensure security?

keepass2android added this some time ago and it has certainly helped wonders for me there with the automation of passwords in apps on my phone and tablet. That said it's only there on android. I'd love similar kinds of integrations/apis available on other platforms too.

Password managers seem like somewhat wasted effort when you pass all the plaintext around on Android. Feels like a security minefield; only a matter of time until a vulnerability or outright malicious app starts reading them.

Obviously if you can't use the password manager on mobile it's functionally worthless.

That is getting better with better clipboard APIs.

That's one of the reasons that android added the autofill system, so you no longer have to pass them around in plain text on the clipboard.

https://developer.android.com/guide/topics/text/autofill-ser...

> Do you think a standard/protocol for communication between platforms and password managers would help solve this problem?

Does the Freedesktop Secrets API Specification resemble at all the type of thing that you're envisioning?

https://standards.freedesktop.org/secret-service/ch01.html

Don't iOS and Android have some sort of support for at least the first event? I seem to recall them allowing third-party password managers to present their passwords when requested.

At least in iOS you can set one or multiple Password Managers which will provide login info whenever required. It works well.

> I think password managers could be easier to use, but that the fundamental problem here is, well, fundamental. [...] To get specialized passwords for all your accounts, you have to be able to reliably use the password manager on all your devices, which means not only configuring it and regenerating passwords the first time, but getting it to work again and synchronize it on every new device you use.

All of the major password managers pretty much have the "work again" (use of a saved password) and synchronize part pretty much nailed by now -- good enough for government work anyway. (that's an old US idiom for non-US or millenial folks.) It's really just the first time (enrollment) problem that is the UX bugaboo. It could be solved. So I wouldn't call it a fundamental problem, in the sense that it can't be overcome.

I think a solution hasn't been pushed because being able to more thoroughly decipher enrollment forms is a competitive edge. And as long as it's a problem everyone (all password managers) have, that edge can be honed. Password managers are companies also. They need revenue and market share, not universal solutions that also make the job easier for their competitors.

Are these issues that a "dumber" password manager would have? I'm thinking of one that would run in a standalone app and only have the ability to generate passwords and save them for a given website identifier (presumably the domain name), look up passwords given the identifier, and delete entries when no longer needed. The passwords here could be all encrypted with a single password that the user has to remember, and then the user can just copy/paste the password from the manager to the browser as needed. I think OS X has something like this built-in (I think it's called Keychain, although I'm not a Mac user, so I'm not sure if it actually has the exact semantics described here). My guess is that a lot of the issues you're talking about mostly stem from trying to interact directly with the webpage, which I'm not convinced is a robust model if the goal is to optimize for non-technical users.

That is certainly easier to use, but comes with higher risks of phishing. The Holy Grail would somehow do both.

I use one of those. It's open source software and I have the password safe file on my Dropbox account so it is everywhere and backed up. That way I need to remember at most two passwords (Dropbox and my password manager).

Works great for me and I have used it for small teams as well.

https://www.pwsafe.org/

Sounds like pass [0]. Which is dead simple, GPG. (And optionally git for sync).

Whilst pass itself is a CLI, meaning non-technical users, it also has a ton of web browser extensions that target it and are dead simple to use.

[0] https://www.passwordstore.org/

Current versions of iOS have a built-in password manager as part of Mobile Safari - it feels like this could be a much more user-friendly option, I'd love to see some formal usability studies of how it compares to 1Password et al.

It works really well provided you enable iCloud and use safari as both desktop and mobile browser, which I think is probably a lot of people in the author’s orbit.

On desktop Mac, you can copy password from keychain to chrome. Kinda crappy, but gets job done in slightly more secure manner as Notes.

You can do this on iOS as well, but it's somewhat more complicated.

Not that much more. Good point!

The iOS password manager also works in properly designed apps as well.

Websites and apps must test themselves with the popular password managers and ensure it is a smooth experience — otherwise they are being security hostile.

The other dumb thing is forcing there to be a password for an account. If I reset my password via an email reset, just let me click on a link to login into the app (ensure things like deep linking into apps work). A one time token is way better than any password. Let me go through that flow on multiple devices without resetting the first device. Send me an email every time a new device receives a sign in.

If email is weakest link (password reset) don’t make me even less secure by requiring me to dream up another password. Now there are two vectors to crack me.

Outside of what you describe (the little edge case issue that pop up 5% of the time), I found the biggest problem for on boarding for password managers is just time.

I was able to successfully get my Dad to switch to LastPass, but it took a lot of time to recontextualize what he knew about passwords before, and how to work LastPass into his daily life. After the initial setup (which involved setting up the account, showing how it works, and migrating about 25% of his passwords), he would ask me questions about it every few days. Just basic stuff like what to do when some sites don't work nice with it, LastPass not saving a password correctly, and other stuff.

Once he did learn it though, it has been pretty much smooth sailing. I am only really familiar with KeePass and LastPass, but both programs have pretty terrible on boarding. LastPass has an ok 'how it works' [1] page, but what these apps really need is a guided tour/tutorial explaining what a password manager is, how to use it, and how to migrate your current password setup over to theirs. Using a password manager almost has it's own language, and teaching the users that language is the hardest part in my limited experience.

[1]: https://www.lastpass.com/how-lastpass-works

I tried getting an older friend of mine to use a password manager. After a few hours, we were back to using one password. I'm now convinced that the way forward with the technically unsophisticated is indeed abstinence. Do not bank online, treat the internet as a place where everything you do is public, and deal with threats as they arise. As far as password managers have come, they're still only usable by power users, normal users can be educated to use them, but the truly unsophisticated really should just stay offline. Fear is a far easier sell than mastery.

Banking is one of the safer things you can do online, thanks to the high level of regulation and consumer protection around the financial industry.

Though they tend to be the ones that have password length and character restrictions.

For better or worse, banks tend to use back-end risk-prediction and risk-prevention methods. Those stop-loss much, though by no means all, fraud losses.

One unified model of understanding all the FIRE sector (finance, insurance, real estate) is to consider them as fundamentally attendant to the question of managing risk. To a vastly greater extant than any other economic sector.

I just introduced 1Password in our company, to our mostly non-technical staff and being a long time 1Password user myself it was indeed surprisingly complicated and involved more friction than most of us here would expect.

One of the major barriers was explaining that the actual process of moving to secure, unique passwords requires changing them manually at every service in a repeated sequence of back and forth between the service' configuration and 1Password. Users expected the changes made in 1Password to apply and automatically sync to whatever service they were changing at the moment, which is of course not possible.

Another issue were domains, which are basically the only way to connect a 1Password entry to a website. Naturally I had to explain to keep the website/domain attribute as short as possible to avoid problems like 1Password not recognizing that the current website at foo.ebay.com does in fact belong to the entry with the attribute bar.ebay.com. This isn't helped by the fact that 1Password automatically suggest creating entries it recognizes as new, which often include specific login domains and urls. Setting ebay.com as website attribute is the right way to do it, but of course this is rather confusing for most people.

I'd argue that most people might be better off without the browser extension and should instead start with the simplified copy and paste process of manually opening 1Password whenever a sign in is required.

> Users expected the changes made in 1Password to apply and automatically sync to whatever service they were changing at the moment, which is of course not possible.

Of course it is possible, it's just not implemented. There have been proposals for standard URLs that would accomplish this, but none of these have taken off.

Just wasn't sure if you meant not possible "today" or not possible "at all".

Yes, I know - we had this discussion about a potential standard set of user configuration URLs just recently here on HN, but in my comment it was meant as not possible right now.

I put my mom on LastPass. She has 2FA enabled and working, we can share passwords to each other, she’s happy to access via PC browser extension or iPhone, and she can’t possibly screw it up.

I think the easy system already exists.

Many of them stay out of the way. I use a more technical one (Browserpass) and even that is a generate password once and it automatically syncs with Google Drive or whatever file sync service you want.

A password manager provides the exact same benefits as the website hashing the users password client side with a salt - before sending the password as per usual (over SSL and then hashing the hashed password server side also).

Why is this not done?

Huh? If I log out, how does the website let me log in again?

Insert your password, it is appended with a salt and hashed, and then sent to the server which logs you in.

What is the salt based on?

Then your password is just the hash and salt. And presumeably you're generating those with JavaScript, which adds a surface to target to exfiltrate passwords. No need to get into the server, just inject some JS or redirect a CDN or...

It doesn't actually add any security is the short story.

> Then your password is just the hash and salt.

Yes, and by that it appears random. Which is exactly what we want and what password managers provide.

> just inject some JS or redirect a CDN or...

This is the case anyway with regular passwords.

> It doesn't actually add any security is the short story.

Are you sure?

> Yes, and by that it appears random. Which is exactly what we want and what password managers provide.

Good sources of randomness, that aren't susceptible to side-channel attacks have only really appeared in browsers (Crypto.getRandomValues) in March of _this_ year.

Random is only good if it is a decent CRNG, and we haven't had time to roadtest if we can rely on that yet.

Bad random is predictable, in which case you're removing security.

> Are you sure?

Yes. You're _adding_ a platform that can be attacked, but not introducing anything that is more secure than what is already possible.

I don't see what security we would be removing. I am for keeping SSL and server side hashing. I am just suggesting the addition of client side hashing also.

I do this with the sites I admin. I don't know why it's not more widespread.

If I key in the same password "PAssword123" for site A and site B, it makes absolutely zero difference if it's hashed before sending on site A if site B is storing it in plain text, because once retrieved from site B it can be used to log in to site A regardless of A's password handling process.

The only way round this is to make sure that B doesn't have any information which can be used to compromise A, by sending the password from an external program.

(You could just about achieve this from client-side salt+hash as an external program instead of a password manager, but then it's a big pain to change passwords when B is compromised.)

I'm stipulating that we use a salt, so the (password+websitesUniqueSalt) equals a different hash each time.

Most people wouldn't do that because it's effectively redundant if you trust TLS and that the server is not compromised. However I think your proposed technique would be useful in cases where TLS is broken or the server is in some way compromised, running on low trust hardware, etc. So it's a good precautionary measure.

Grandparent is also right that your users password can still be compromised on other services, giving an attacker a way into your own. Password managers don't have that problem.