Hacker News Reader

The built-in browser password managers (Chrome, iOS Safari, Firefox) are pretty popular.

But I agree that the real moral of this story is: test your login page with browser password managers. They all support multi-page login flows if you tag them correctly. (Google uses one, so they can't just ignore this problem.)

If your login page works with the built-in password managers in Chrome, Firefox, and Safari, it will also work with LastPass and 1Password, too. And you're done!

In my experience, and from the people I've talked to; in-browser password managers are useful only when they work without messing with. People don't rely on them, they just use them when they autofill.

The difference being, if you're not relying on them, then you're probably not actually using them to generate unique passwords on each site. So all its doing is remembering the few different passwords you use across many sites. Its a convenience tool, not a security tool.

The one exception might be Safari's, which is without a doubt the best in-browser password manager of any of them. It proactively generates new passwords, and will INTERRUPT the user from entering their own password in order to use one it generates. That's huge for average users.

Chrome's password manager suggests unique passwords when creating new accounts.

As someone in another thread mentioned, this case you’re explaining can be handled super easily by making a request to the server to figure out which flow they’re in as soon as they’ve entered a valid email (regex test). Dropbox was cited as an example of this in the wild.

What’s hilarious to me is that people mention the reason for this less than great UX decision and basically leave it at QED. There are always better solutions, we shouldn’t just say “Well, that’s just how it is cause X”. We’re engineers, let’s engineer something better!

Mutating the page based on what is dynamically entered into it is just about as bad, if not worse, than splitting the login into multiple screens. And is still a form of being "clever with login forms".

An possible solution is simply to support multiple different login pages (at their own dedicated URLs) for the different styles of logging in instead of trying to cram everything into one.

Kind of like multiple functions in a library under different names, rather than one big one with 15 arguments.

> Its absolutely hilarious to me that all of these Suggestions are motivated by the use of password managers. The number of people using password managers is literally a rounding error.

I'm not so sure you're right in the general case, modern password managers are aimed at fairly normal people, there may very well be millions of password manager users.

Nevertheless, even if we're a "rounding error" we are often decision makers. So deliberately not supporting our workflow may make it surprisingly hard to get us on board, or to keep us from recommending one of your competitors just because it annoyed us to use your workflow instead of ours.

Several people below have suggested tricks that preserve your desired behaviour (people don't go down rabbit holes for other auth methods that weren't for them anyway) while making password managers still work. Those are better than what you do now, so, do that.

Users who use their own password manager are also amongst the most technical. Optimising login UI so they can login a little quicker, at the cost of confusing the average user, is a terrible trade off.

For example Office365 uses a single email input on the login form. For enterprise users clicking "next" triggers an SSO flow that skips any password prompt.

If Office365 adopted the suggestions from the article and added a password field Brad Frost would be able to log in to his personal account from a single button press - a small optimisation for him - but many more users would be confused about the presence of a password input and potentially even be stopped from using the product at all.

> The number of people using password managers is literally a rounding error.

Given that they're present out of the box in all major browsers, I find it hard to believe. Maybe it's true for the user base of that enterprise app, but on the web as a whole?

And Chrome particularly is very aggressive at pushing the password manager. It will detect login forms and ask to remember passwords even without people interacting with it at all. It will offer to pre-fill a login form as soon as you start typing your login.

And recently, it's even offering to auto-generate strong passwords when it sees what looks like an account registration form - and those passwords then get saved straight to the password manager, so any person that takes the easiest route and clicks "OK, sure" is going to be tied to said manager thereafter.

There needs to be a standard or something here to facilitate password mangers. Everyone should be using one and not reusing the same password.

Password managers largely assume that you personally own or control all the devices you login from. The problem is what if you want people to be able to login from multiple devices or your colleagues devices? This frequently comes up in business and personal contexta eg.login and show someone something on a device not yours. Normal office folks don't carry around their work laptop wherever they go unlike developers. I never carry laptops to meetings unless I'm presenting though I occasionally do development. I don't carry my laptop when meeting friends or relatives.

You'll then need an internet synced password manager with a web interface because you can't install programs on other people's laptops and it introduces a pre-step in the middle of the meeting any anyways you are trusting all passwords in the cloud. You could come up with more secure solutions like do client side decryption using symmetric keys but now you have a login step and a decryption step before you even use the password.

Basically this is why password managers don't really work for normal people - there is no good workflow when you need to use devices other than the ones you personally control.

Two factor authentication using fingerprint with mobile phone trends to be much better because generally people carry their mobile phones around and it's one touch.

I personally use my own algorithm that lets me create unique passwords with little mental effort for each use case.

What I do is to combine the password manager (to store the passwords) with a web macro tool (kantu) to automate the clicks through the pages. I can trigger the kantu macro from a bookmark.

I hate password managers with passion. In general passwords are hard to remember. Especially when every site has their own requirements. Password managers add too much friction.

I very much like login in with google. Even two factor TOTP is nice. I don’t have to remember things. I just need to carry a device with me.

The trick is to install a password manager browser extension, not to use a password manager that operates as an isolated app / CLI tool / website / etc. Then you unlock it once at the beginning of your session (or whatever frequency you feel like) and it will fill in passwords for you when you click, without having to copy/paste them. It's about as easy as external login / login with Google.

(inb4 "but password manager extensions have bugs that cause them to fill in the password on the wrong site": get one that doesn't. https://news.ycombinator.com/item?id=18984582)

Having auto-fill may be rather dangerous even if your password manager extension has no bugs whatsoever. I would not recommend this configuration.

Having one touch form fill for credentials is good enough. It adds one touch to every intended login, but deletes the risk of credentials being captured when you weren't actually even trying to log in.

Regarding auto-fill, I second this. Password managers are great, but I would go so far as to advise against using password manager browser extensions entirely. You're adding several more vectors to be compromised, and imo the risk is not worth it.

Navigate to the site, open the password manager, copy and paste the username and password into their respective fields. Yes, it's less convenient, but as we know convenience is the bane of security.

With authorization we have a few things available to us - something you know, something you have, something you are. To remain secure you will always use at least two of these when authorizing with a service.

The login information for my password manager is stored in my brain - something I know. The 2FA code I enter from my phone is gathered from not only something I have (my phone), but must be authenticated to with something I am (my face (although they could probably just brute force my pin)). I take it a step further by storing the 2FA codes for my most valued accounts on a completely separate device that I leave at home. /protip

> Navigate to the site, open the password manager, copy and paste the username and password into their respective fields.

This leaves you vulnerable to (at least) two attacks:

1) Phishing. The password manager extension will refuse to send the password to the wrong site; it can't be fooled when tired the same way you can be fooled when tired.

2) The password stays around in your clipboard. There's a general risk of accidentally pasting it (e.g. to the next site you log into). There's a specific risk of sites that capture activity on unsubmitted form fields, which is becoming way too common.

You should decide for yourself how you weigh these risks, but I'm a pretty paranoid person (e.g., I have a Chromebook in a corner of my room which I use as an SSH / web client for certain high-security sites like my domain registration and maintaining certain servers) and my conclusion is that the risk of phishing and mispastes is high and the risk of my particular password manager extension having serious bugs is much lower.

> Yes, it's less convenient, but as we know convenience is the bane of security.

I'll be honest, I don't know that. Security keys are more convenient than SMS-based 2FA, and significantly more secure. Signal is more convenient than PGP, and (depending on threat model) more secure in real-world use. Doing string processing in Python is way more convenient than doing it in C, and way more secure.

"It's annoying, therefore it must be secure" is a fallacy. Sure, there's some correlation, but it's not a perfect correlation.

Yeah, Security Keys definitely illustrate that "more convenient" isn't "less secure". Signing in with a Security Key is so painless, it's just a shame I can't do it in more places.

Use the clipboard as interprocess communications for secrets does seem dangerous. The 'pass' password manager I use has an option to do that if you want that, but I've rarely used it. However it may be less dangerous than you realise - by default pass will destroy clipboard items it added after 45 seconds. This is easy on X and, as far as I know, any modern graphical desktop, because the "clipboard" isn't (usually) really a static buffer, it's a live negotiated relationship between desktop clients, so "pasting" is an operation in which the copying software is itself actively involved, so if it were to crash, the content is gone, not left on the clipboard.

Yes but when you’re constantly switching devices and machines. It’s a pain

Most password managers don’t do jack inside a native app (for good security reasons - thank you Apple)

I don’t want to go through 5 mins of clicking and pasting on my phone.

A number of services force you to change passwords every couple of months. They save (may be hash) the old passwords so you can’t use them.

How many goddamn passwords is one supposed to remember?

I care about passwords for important sites and they are all unique. For everything else, it’s yolo!

> Most password managers don’t do jack inside a native app (for good security reasons - thank you Apple)

This isn't true on iOS 12; there's a pretty good OS-wide password manager API. (And older versions of iOS don't get security updates so your device is pretty easy to compromise if you're not upgrading.) It securely pops up the password manager similar to popping up a share screen, so no copying and pasting is involved.

> A number of services force you to change passwords every couple of months. They save (may be hash) the old passwords so you can’t use them. How many goddamn passwords is one supposed to remember?

One. You put the changed passwords in your password manager, too.

I really think it's counterproductive to downvote posts such as this one. Effective security absolutely must be based around user experience - your application needs users, and if you give them friction, they will vote with their feet. It's not about an emotional decision or stubbornness or unwillingness to learn, it's a statistical inevitability.

I'm confident experienced security professionals know this idea well: I'd posit that no one hates passwords more than the person who has to design the training explaining to everyone why they need to use unique passwords, of a certain length, of a certain complexity, and how the risk behind those changes in different environments. I hope mostly everyone would agree passwords are a terrible security solution. So if somebody wants to post that's how they feel about this, and their experience with a solution to get away from passwords, or minimizing them, let's have a discussion about what better options are out there (as some have already done in this thread).

In my view, the most important posts in the discussion of user-accessible security management are these posts that identify what makes every user need to be a hashing expert to select and manage the ever-expanding repository of account credentials we have today.

half the point of a password manager is to generate passwords so you don't have to think of (or repeat) them and the other half is to store them so you don't have to remember them. I'm not sure where the friction is coming from? In my experience they're easier than remembering a user/password combo by a long shot.

Companies should be making this easier by giving their users URLs that redirect to cloud services using their company's SSO service.

For example, employees access their email on office 365 via https://example.com/email which redirects to outlook.office365.com/?realm=example.com.

Microsoft login solves this by having the email and password field together, but once the focus is changed to the password field a request is made and you're either redirected or not.

So why not have an automatic login button next to the password that, when clicked, checks your e-mail to use the correct one?