Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

That's because web developers are not great at sticking to conventions and standards for this stuff. Product owners and UX designers seem to ignore aligning their signup and signin UX with obvious requirements for enabling people to use a password manager. If they'd make this a hard requirement, it would happen.

It's not that hard even; we did that for our login form. Works great with Bitwarden. And on mobile too. But you have to know how to name things so that password managers can do their magic.

Frequent mistakes caused by essentially ignorance on this front:

- Splitting the email and password form across two screens. That somehow became fashionable. There are ways to do this and not break password managers. But why do this at all? Having to click the fill button twice is ugly and should be flagged as a bug if you ever see that. There's no need for that regardless of the UX.

- Having a login form but then not using field names like "email" and "password" that a password manager would recognize as such. There are a few more things you need to think about: https://hiddedevries.nl/en/blog/2018-01-13-making-password-m.... Just do it right.

- Not having password managers on the radar as a thing that the UX MUST support (not optional). Non technical people like designers and product owners tend to be a bit sloppy with their own security and they won't necessarily even be aware this is a thing that they need to worry about. So, they don't notice when it doesn't work. They probably don't even use a password manager themselves. And they certainly won't test it.

- Developers not caring enough to do anything about this unprompted; by e.g. just raising the topic with their PMs or just implementing things correctly to begin with. I've actually brought up this topic and usually this is not controversial at all and simple to resolve.



FWIW I'm a developer, and I think password managers are awful to code against. They don't document their expectations (to the best of my knowledge), it's hard to test because you need multiple password managers installed, plus the browser's built-in ones. I mean, even the link you shared feels more like alchemy than engineering (through no fault of the author, I might add): "do it kinda sorta like this and then hopefully it'll work most of the time!"

And it's hard to figure out why it doesn't work when it doesn't. The feedback cycle is nonexistent.


> Splitting the email and password form across two screens.

Just wanted to note that Google handles this right, which I've always appreciated.

They have two-screen login, and if you use a password manager, the password is prefilled when the second screen loads.

I assume the two-screen login is to ensure the name is valid before asking for a password. Without the clunkiness of doing it "onBlur".


> Splitting the email and password form across two screens.

This is done because it's an easier way to support both local login and SSO(like oauth or saml). By taking the username first you can determine whether to ask them for a password or send them to a sso provider.

It doesn't have to be implemented this way but it is seen as easier.


Yes, unfortunately a lot of implementations for this break password managers. It doesn't have to be that way and there are ways to fix it. But it complicates things a bit. And it's a pattern that actually gets copied a lot by products that definitely don't do any form of SSO.

Also, a typical opendid flow or SSO would not actually require an email field at all. So splitting the screens is kind of redundant in that case. E.g. a Github signin would be done with a button click and a few redirects.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: