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?
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
My email is already synced. There is no extra work.
> 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.
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.
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.
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.
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.
Authentication, not authorization. ;)
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".
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.
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
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.
When I day the future I mean years down the road. Not next week.
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 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.
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.
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.
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.
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.
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?
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)
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.
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.
Password authentication is literally just clicking "Login" because my password-manager fills in the field. In this happy path it is also unphishable whereas the email-based example provided here is trivial to phish.
The main problem with password login is the "bad" users who haven't bothered to set up a password manager 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.
Honestly I'm excited that we are getting 2FA pretty mainstream but honestly I think passwords are a going to be a good long-term solution. The main differences will be:
1. The browser will generate all your passwords. The UX to pick your own password will be awkward.
2. You won't give your password to the site (or server) but it will be exchanged via a PAKE.