Hacker News Reader

I think you're ignoring the fact that people like to access their accounts from different devices. Using a password manager means you either only use a single device for all your internet, or you deal with the synchronisation problem yourself.

Both of those are a worse UX than either using a password (with constraints enforced by the site) or email-based auth.

> 1. The browser will generate all your passwords. The UX to pick your own password will be awkward.

So, not only will the user be locked into a single device, they'll be locked into a single browser on that device? That's hardly an improvement, is it?

All popular password managers and browsers have built in sync features. I don't see multi device as a problem with passwords. And don't people need to sync their email? How is that any different?

> they'll be locked into a single browser on that device?

I don't know where you saw this conclusion from. Their are multi-browser password managers and you can always copy+paste.

> And don't people need to sync their email? How is that any different?

It's different because it is already done. I don't know of anyone who hasn't already set up their email on all their devices.

Literally, not a single person I know that has a desktop, laptop, tablet and/or phone or any combination of the above that hasn't already got their email on their devices working.

Maybe you use a computing device that doesn't already receive your email, but you're in a minority.

Note when using multiple devices in the case of the email-based auth if the code is not simple enough then you end up with having to setup email sync on all devices ...

And even if simple enough it relies a lot on cookies to avoid the hassle of the flow and become absolute crap when using private session or a cookie cleaner.

For the "personal project where security isn’t critical" use-case half the time the site would be better without authentication and the other half I'll probably use my default crapshot password because it's not worth more effort.

Edit: on the dev part it's not even simpler than a password solution since in the example the token is stored server-side and you still need to send emails. If you don't care about session invalidation then you could just rely on the token with a bit of encryption/hashing.

Another edit: you could probably just add an optional password field to the flow and obtain something more flexible for the user without adding much complexity.

-> When creating an account not much diff

-> When logging if you have the correct password then great otherwise send the token

-> When entering the token add optional password to update

> Note when using multiple devices in the case of the email-based auth if the code is not simple enough then you end up with having to setup email sync on all devices ...

My email is already synced. There is no extra work.

> Using a password manager means you either only use a single device for all your internet, or you deal with the synchronisation problem yourself.

Is synchronisation a problem? 1Password does it all for me, I don't even notice it.

> Is synchronisation a problem? 1Password does it all for me, I don't even notice it.

It is for me. I use a command line password manager using the `pass` tool. I choose not to use any browser extensions or sync these passwords in a way where they leave my main workstation.

It's really inconvenient when I need to use my phone to login to some site. It involves manually typing in some password that looks like this: aC6)&hahi*`9$Ik+WU7xA[igDfw\w'"VC_^VKh{<|PU~EQb{. You have any idea how tedious that is to do on a phone, especially when the site doesn't offer a way to see the password with a toggle? :D, on my workstation my password manager copies it to my clipboard for a short period of time so there's no typing involved.

Magic links solve this problem because all I have to do is be logged into my email account to be able to access any site that uses magic links.

So you don't want to sync passwords to your phone, but are happy syncing email, which would allow a far greater compromise (beyond just being able to magic link or password reset you)?

I'm not sure how that falls inline with passwords vs magic links?

Personally I have my email password remembered, I don't sync anything between my workstation and phone such as browser accounts or anything like that.

All I know is, logging into a site using a magic link on a phone for me is much easier since all I have to do is check my email and click a link instead of typing a ~50 character randomly generated password that I made on my workstation when using the site originally.

If someone already has access to my email then it's game over.

It’s great if that is an option for you, but for many of us, if a site requires email logins, it is a fail. Much of the time, by the time the authentication email arrives, the login timeout has expired.

If a site makes it time out after 5-10 minutes that's on them.

An hour should be ample time for it to be delivered while offering a decent amount of security around token availability, especially since it should be revoked as soon as it's been used once.

Everything you hate about email login is what I hate about 2FA, as a user.

i mean it’s not much different it’s just email code/link vs an all generating a code but 2fa is unphishable as well

2fa totp\sms is phishable, 2fa FIDO is unphishable

Absolutely. I'd happily use password-only services. Because I'm willing to take responsibility of losing my own password. I hate it when someone forces me to use 3rd party services, usually not very secure, when it's not really required by logic.

I'm happy to jump through 2FA hoops for my banking app. I'm not so enthusiastic to do the same for every news or social media site.

I also hate password emails. I use a password manager and find it much more efficient. However, I can see how this solution is interesting for small projects where users might create an account once and forget about it. I wouldn’t want that setup for a site I use often, and especially not for a site where I have multiple accounts (Twitter for example).

> I hate email-based authorization.

Authentication, not authorization. ;)

"Honestly I'm excited that we are getting 2FA pretty mainstream" Doesn't that have those extra steps included as well that you critizised on email-based auth?

No, password managers can take care of that.

Can password managers deliver OTPs or other 2FAs?

1Password can do TOTP

Though it defeats the point of TOTP to some extent.

It still proves you’re giving the password right this moment, and that it hasn’t been popped from a DB.

On the other hand it doesn’t prove that someone has stolen your phone/laptop, defeated all of its own security, and then defeated the security of the password manager.

For my personal risk propensity, the former is worth having, the latter is too unlikely to worry about

No, it just depends on your case.

(I work for a company that makes a password manager that have this feature too)

I used to think that but I changed my mind.

First, you can set TOTP (or other second factors) authentication on your password manager account, which I think is good philosophically at least, because you gotta have access to your second factor to get access to you website TOTP.

Secondly, using a password manager with strong unique passwords that you don't know brings already a lot of benefits that pushes websites and administrator to push using a second factor (it's very often a way to avoid attacks using reused or bad passwords).

You do lose a bit of security (there is now a risk that your TOTP seed get stollen), but the extra convenience (especially when you lose your TOTP device) means you can enable it on more websites without too much annoyances.

Wait, are we talking about the same 2FA? I meant logging in with password and then 2FA with something like Google Authenticator from another device (mobile phone). If the password manager would do both of it, where would be the extra security?

Form a corporate perspective: 2FA would still force a unique secret per user. That can be useful when your users tend to reuse passwords for different sites or choose poor ones.

I have seen folks use password managers to store their poor non-autogenerated passwords.

For users that do use the PW manager properly, having the PW manager store the TOTP secrets is indeed "putting all of your eggs in one basket".

Your "Browsers and PAKE" suggestion requires everybody gets new browsers with this special feature and every web site upgrades to rely on that feature for user authentication.

So that's a Big Bang change and thus not at all practical for the Internet. The Internet's last successful Big Bang change was 1 January 1983, almost 40 years ago.

We can get where we want to go, without passwords, incrementally with WebAuthn.

People need to update their browsers regularly for security updates anyways. And I didn't say anything about a big-bang change. It would obviously be a new API that slowly becomes the default choice. Maybe <input type=password-pake algo=opaque> rather than type=password.

When I day the future I mean years down the road. Not next week.

> Maybe <input type=password-pake algo=opaque> rather than type=password.

That's not how OPAQUE (or similar things) works. You cannot, in fact, just drop this in and "slowly" change. You need an enrolment step where the server does not learn the password (but does end up able to ascertain whether the client knows the password), and from then on all clients must not reveal the password to the server. The sign-in process now needs a phase where the client has identified itself in order to receive parameters it will need to deliver live proof of having the credentials, so that means re-designing many single-step sign-in processes (e.g. username and password on same form)

And all the hard work is destroyed the moment either the user types their password in to a conventional web form, anywhere, or the server ends up actually storing passwords and not OPAQUE's "envelope" data, both of which are almost certain to occur if you try to introduce this "slowly".

You are assuming a lot about the implementation that I didn't specify. I'm also not saying that I have fully designed the API for this, just giving a very rough idea of what it could look like.

> You need an enrolment step where the server does not learn the password

Of course, there would be something similar to new-password that can be used on password set and change forms that would do the enrollment dance.

> The sign-in process now needs a phase where the client has identified itself in order to receive parameters it will need to deliver live proof of having the credentials, so that means re-designing many single-step sign-in processes (e.g. username and password on same form)

IIUC the browser could get the user id and password in one step then do the back-and-forth with the server afterwards.

> both of which are almost certain to occur if you try to introduce this "slowly".

I don't see why this is certain to happen. For passwords that use OPAQUE the password manager would set a flag that prevents it from being filled into any field that is accessible to the website. In practice this means that it would refuse to fill in any input that isn't `type=password-pake` and the value of that input wouldn't be accessible to the site. For the user to work around this they would need to copy-paste or retype the password themselves. It won't stop everyone but there is lots of room for good UX warnings.

But again, I'm not claiming that I have designed the perfect protocol, but I think passwords have value because they can easily be typed, written down and re-imported by users whereas most key systems make this very difficult (although maybe shorter keys and more efficient encodings can mitigate this). The ability to pick your own password is also valuable for the few passwords that you do need to memorize. My point is that I think that there are significant upsides to passwords and most of the downsides can be worked around such that users would barely notice the difference.

> My point is that I think that there are significant upsides to passwords and most of the downsides can be worked around such that users would barely notice the difference.

That's barely a "point" and more an abstract notion that you're correct although you're aware the evidence suggests otherwise. The supposed "strengths" of passwords are in tension with any attempts, like yours, to make them actually useful for authentication. We have something that actually works, today, WebAuthn. If you care about the authentication problem use WebAuthn.

Maybe I haven't seen a good implementation but I wouldn't say WebAuthn works. I have yet to seen a version that syncs across devices which is a fundamental requirement for me. I'm also not sure how I can type in a WebAuthn credential to someone else's computer or how I can memorize it so that I can use it when I am away from my phone+computer.

Both approaches clearly have gaps right now, all I am saying is that long term I think the password+PAKE looks more promising than what WebAuthn offers.

Most sites will require you to confirm your account before being able to do anything which involves receiving an email and clicking a link which is the same workflow as a passwordless system. I don't really see a magic link system as being worse in this regard, especially if you use cookies to persist the login. The user experience is the same except for cases where you want them to login again without a cookie, I'd make a case that using a passwordless system here is better because each time you login you are verifying that you still own the email address -- this isn't bad if it only needs to be done a few times per year. For a lot of sites it's reasonable to keep a user logged in for months at a time or even permanently.

Using email to verify the account is a one time operation and if it takes a long time to get the email, that can be endured.

Having to depend on email for authentication each time is unworkable. Frequently the email never arrives or takes a long time to arrive.

I would much prefer to use the passwords that I keep in a password manager and can do an immediate login without depending on email’s duct tape and bailing wire approach.

It could be a near 1 time operation with magic links too. The cookie can be saved for 6 months, a year or even 20 years on your device.

> or prefer to use their dog's name as their password on every site. It really sucks that a great workflow is being punished just because some users are irresponsible.

Actually I'm more in favour of using a "throwaway" password in the sites I care less. Exactly because I don't know if they store this on plaintext or weakly hashed.

Sure, it's still a secret, but it's something that's not hard to remember if needed (or even type on mobile, because if you think I'm generating something like a random string of characters for any website that wants me to login you're mistaken)

Password managers are great but I don't have it (or want it) installed in every device.

I'm just a little worried about everyone having all their passwords in a single basket like 1password.

It just doesn't seem a smart thing to do. There are certainly dozens of ways to hack 1password that they don't know yet. What happens when someone decides to exploit one of these?

(I work for a 1password competitor, my answer is pretty generic)

Serious password managers (like 1password) encrypt data client side, with a secret not known to them. If the master password is good enough and the cryptographic part well done (for example with a hard enough password derivation function) passwords are probably relatively safe even if the servers of the password manager were to be hacked.

Now you could argue that a malware could be injected in the client side code and steal your password this way.

The bad news is that any software you use probably have broad access to your computer, and could probably steal your passwords in a way or another. So yes there is a risk to using a password manager, but it's not terribly different from the risk of using any software.

Maybe there are some passwords you never input on a given computer, and having them in "the same basket" as the others would be a problem. In that case you'd probably want to use a separate password manager account for those passwords.

On the other hand, not using a password manager means you either use the same password everywhere (or some derivative of the same), or use weak enough passwords that you can remember them all. It also means you input your passwords yourself, meaning that you could easily get phished, which is a pretty common problem these days, etc etc. So not using a password manager is itself a risk (and in my biased opinion, a much bigger risk than getting your passwords stollen from a PM vault)

I'm sure you guys have pretty high security standards, I just think the incentive to break you is too high (and I'd bet anything there are at least a dozen ways to break your security).

The incentive to break my personal security perimeter is quite low. That being said, I do reuse my passwords. The strategy is having 5-6 different levels of pass, depending on the service. Level 1 is the highest security. I only use in very few services, usually financial-related. Level 5 or 6 are the lowest, I use loosely on services that I don't trust and don't hold too sensitive information.

EDIT: another side of this strategy is also having levels of email addresses. So the address I use in level 5-6 services is not the same I use in Level 1, and certainly not my public email address. For lower levels of security, I use browser "remember pass" feature to offload my memory.

"remember pass" of the browser definitely counts as a password manager for me, so that's good too :)

I agree that there are probably strong incentive to hack popular password managers, but I'm sure it's true of all popular software. And a soon as you manage to inject a backdoor in a software, even if it's a cat picture sharing software, you might be able to steal very sensitive passwords from the victim (via keylogger or other means).

Having said that, if you want to steal passwords, are you going to attack the password manager where security might be taken seriously or target the cat picture software whose incentive to do good security are much lower? Personally I'd choose the cat picture one ^^ (if it's very popular)

Also I just want to note that you might very well get hacked even if you are an uninteresting target. Most attacks are not targetted I think, they just send phishing emails to list leaked from miscellaneous website. And protecting against good phishing attacks is extremely hard, and I personally wouldn't ever dare saying "I would never fall for this" or blame victims for getting tricked.

How do you sync your password manager state? This is not easy for a typical user to setup, whereas their email is probably already syncing across all of their devices.

Really? For me, password sync just works in my browser without any adding or anything. Just had to log in once when I got each device. I use Firefox, but I would be surprised if it was more difficult on other browsers.

Bitwarden.

I believe all modern browsers have buikt-in easy-to-use passwords managers with nukti-device synchronization.

I use 1Password, so it just happens when I sign into my account on a new device. The same is true of the built in password managers from Apple, Google, and Microsoft.