I hate email-based authorization. It is an extra step and requires access to a working email. Sure 95% of the time I get that email in a second and then it is only a window switch, copy/click, delete and switch back (maybe paste). But 5% of the time it is even worse and the email gets marked spam, or greylisted for 15min.
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.
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?
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
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.
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 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).
"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?
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.
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.
> 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)
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.
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.
> User creates an account with just their email or can create a temporary
> account. Their session lasts for a long time. If it expires or they try to
> login from a different browser, they get a code to their email. It’s a great
> solution for a simple site that doesn’t get much traffic.
Hah! from the point of view of the user, this is already possible even with password-based sites. Instead of logging-in with your previous password (which of course you forgot), you just claim that you lost it and request a recovery email each and every time. I do this almost systematically and I'm happy with that.
Password manager is the best solution. I prefer not to make login dependent on phone/email access.
I always use login + password, I don't need additional devices / tools (which make the whole process more difficult).
Meta: The HackerNews submission correctly titles this as "authentication", but the blog post itself is incorrectly titled as "Simple Passwordless User Authorization"
What I want is smarter auth systems that are better at determining how weird something is. Is it completely secure, no, but for example Heroku now has a ridiculously short session timeout, even when I'm logging in from the same browser, same machine, same IP address, come back to check something a few hours later and I'm completely logged out. Why?
I must say I'm confused about hating passwords as a /developer/ though. Even the smallest web frameworks generally have well-documented frequently used auth solutions. Setting up users/passwords and even 2FA at this point is basically a lego block everywhere.
I did that for a side-project a few years back. This was very elegant to implement: I was happy not having to store any password hashes (which is a dangerous thing to store as password reuse is prevalent) while still ensuring that my users had a secure way to interact with my service.
Still, this confused the heck out of some users. Some people kept forgetting the email address they used to sign up and were asking me why their account had been 'duplicated'. I had deliberately blurred the line between signing in and signing up and in practice it backfired a bit. I would not try that for a mainstream service nowadays.
Readit News
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.
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
> 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.
Is synchronisation a problem? 1Password does it all for me, I don't even notice it.
Authentication, not authorization. ;)
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.
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)
> User creates an account with just their email or can create a temporary > account. Their session lasts for a long time. If it expires or they try to > login from a different browser, they get a code to their email. It’s a great > solution for a simple site that doesn’t get much traffic.
So, why not cut out the middle man?!
Password manager is the best solution. I prefer not to make login dependent on phone/email access. I always use login + password, I don't need additional devices / tools (which make the whole process more difficult).
What I want is smarter auth systems that are better at determining how weird something is. Is it completely secure, no, but for example Heroku now has a ridiculously short session timeout, even when I'm logging in from the same browser, same machine, same IP address, come back to check something a few hours later and I'm completely logged out. Why?
I must say I'm confused about hating passwords as a /developer/ though. Even the smallest web frameworks generally have well-documented frequently used auth solutions. Setting up users/passwords and even 2FA at this point is basically a lego block everywhere.
Still, this confused the heck out of some users. Some people kept forgetting the email address they used to sign up and were asking me why their account had been 'duplicated'. I had deliberately blurred the line between signing in and signing up and in practice it backfired a bit. I would not try that for a mainstream service nowadays.
Deleted Comment