Simple passwordless authentication for web projects(matthewc.dev)
matthewc.dev
Simple passwordless authentication for web projects
https://matthewc.dev/projects/webdev/passwordless-auth/
114 comments
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?
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
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.
My email is already synced. There is no extra work.
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.
> 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.
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.
> 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.
> 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.
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.
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.
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.
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. ;)
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.
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".
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".
Can password managers deliver OTPs or other 2FAs?
1Password can do TOTP
Though it defeats the point of TOTP to some extent.
(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.
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.
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
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.
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.
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.
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".
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.
> 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.
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.
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.
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.
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?
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)
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.
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.
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.
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.
I believe all modern browsers have buikt-in easy-to-use passwords managers with nukti-device synchronization.
Bitwarden.
The overview is the very last paragraph:
> 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.
> 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.
Yes, lol.
So, why not cut out the middle man?!
So, why not cut out the middle man?!
I hate logging in with emails.
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).
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).
A password manager is also an additional tool, isn't it?
No. It's a password _manager_ - I can log in without it, it's just less comfortable.
Meta: The HackerNews submission correctly titles this as "authentication", but the blog post itself is incorrectly titled as "Simple Passwordless User Authorization"
If I'm checking my email, I may as well use 2FA.
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.
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.
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]
Thanks for this, totally I forgot I submitted this and then started playing around with reorganizing my hugo content :)
Perhaps "delayed password authorization" is better than "passwordless" here since the magic code the user is getting via e-mail just becomes their (auto-rotating) password.
I wrote a Django library to do this easily:
https://github.com/skorokithakis/django-tokenauth
It's the easiest login method by far to deploy, though I think users seem to slightly dislike it.
It's the easiest login method by far to deploy, though I think users seem to slightly dislike it.
Execute Program[1] uses this, and while I was initially annoyed at having to check my email to log in, it has grown on me. I only have to do the email step once in a while since the auth cookie is long-lived. And even though the traditional password approach would be marginally easier for me since I use 1Password, I can't help but appreciate the simplicity that comes with eliminating the password altogether.
1. https://www.executeprogram.com/
1. https://www.executeprogram.com/
That's exactly the vibe that this project is going for. Ideally you should only have to do the email login dance when signing in from a new computer
This is actually kind of a vulnerability in itself.
It would be very easy for a competitor or random bag of dicks to cause your server to flood an email server with emails. Not that this will harm the recipient server, but you can easily find your email server blacklisted because of it, effectively locking every single one of your users out of their accounts.
I don't know what's a good mitigation strategy, since this can come from a botnet. Maybe just a global rate limit across all users that allows for some bursts.
It would be very easy for a competitor or random bag of dicks to cause your server to flood an email server with emails. Not that this will harm the recipient server, but you can easily find your email server blacklisted because of it, effectively locking every single one of your users out of their accounts.
I don't know what's a good mitigation strategy, since this can come from a botnet. Maybe just a global rate limit across all users that allows for some bursts.
How is this any more of a problem than the conventional password reset email?
If you try to reset your password too often, especially without logging in, you often end up with a "try again in 48 hours or contact support here", to prevent this type of attack. That doesn't really work if this is how you log into your account. The expected rate of these emails is much higher, so you can't be as restrictive in sending them out.
Another difference is that the ramifications are much bigger. If your password reset doesn't work, the minuscule fraction of users that can't remember their password can't log in. In this scheme, none of your users can log in.
Another difference is that the ramifications are much bigger. If your password reset doesn't work, the minuscule fraction of users that can't remember their password can't log in. In this scheme, none of your users can log in.
Why not limit it to one email every five minutes or something?
Well let's hypothesize I have a botnet and either I've spent a few months creating accounts, or I just have a list of email addresses from some breached site, and my army of 30,000 color changing lightbulbs and smart fridges are spamming login requests as fast as you'll let them. That's still a lot of emails even if just some are legit. Your option at that point is basically shutting down logins for everyone, or find yourself blacklisted.
I was thinking something like this, but instead of no pwd at all, replace pwd with OTP.
Many sites require some kind of OTP anyway. Is it secure to use email+otp only for login authentication?
Many sites require some kind of OTP anyway. Is it secure to use email+otp only for login authentication?
E-Mails are unencrypted and can be intercepted.
When speaking of E-Mail as a user authentication method, it's just as unsecure as SMS.
I'd heavily disrecommend the author's method of sending 2FA codes unencrypted through the internet.
While it is an unlikely attack surface for private hackers, it is a very likely attack scenario of state level actors.
Also: gpg as encryption isn't worth anything when everybody has your public key and/or sent it before via an unencrypted transport layer.
When speaking of E-Mail as a user authentication method, it's just as unsecure as SMS.
I'd heavily disrecommend the author's method of sending 2FA codes unencrypted through the internet.
While it is an unlikely attack surface for private hackers, it is a very likely attack scenario of state level actors.
Also: gpg as encryption isn't worth anything when everybody has your public key and/or sent it before via an unencrypted transport layer.
I use a similar technique to this author's on my site (for about 5 years now) but it is a variant where even if someone got the email or you forward it accidentally to someone, they won't be able to use it to login.
Technique described here - http://sriku.org/blog/2017/04/29/forget-password/
... basically when use provides email to signin, a cookie stores a part of the token while the server send the other part via email. Both parts need to be put together and validated for a login to get through. So the link sent in the email will work only in the browser session where the cookie stored at login time is accessible ... which is how it is configured for most of the users of my small site.
Another side effect of this technique is that bad login attempts do not need a database hit to be rejected.
Technique described here - http://sriku.org/blog/2017/04/29/forget-password/
... basically when use provides email to signin, a cookie stores a part of the token while the server send the other part via email. Both parts need to be put together and validated for a login to get through. So the link sent in the email will work only in the browser session where the cookie stored at login time is accessible ... which is how it is configured for most of the users of my small site.
Another side effect of this technique is that bad login attempts do not need a database hit to be rejected.
What happens with people using the phone for email but a computer for work?
You can adjust this by simply requiring user to type a code from their email.
That said, if an attacker had persistent access to your email, you’d still be compromised through this method.
That said, if an attacker had persistent access to your email, you’d still be compromised through this method.
Not necessarily. The code could be a part of what's combined with the cookie for the login. And the site could trash the cookie if tried once with an invalid code just as it would replace it with an auth cookie on success. A real attack would be through a programmatic request though. A captcha might help protect from that or you an use a redis instance or whatever to invalidate bad login cookies.
Or you could just use normal generated passwords that are synced between devices in your firefox and never have to bother again with logging in on any device.
This is fantastic, I might steal this technique since it's so good.
> E-Mails are unencrypted and can be intercepted
Hu, yes they are. I don't think there's still non ssl mail transport nowadays.
> gpg as encryption isn't worth anything when everybody has your public key and/or sent it before via an unencrypted transport layer.
Interesting how a grammatically correct English sentence can have 0 meaning.
Hu, yes they are. I don't think there's still non ssl mail transport nowadays.
> gpg as encryption isn't worth anything when everybody has your public key and/or sent it before via an unencrypted transport layer.
Interesting how a grammatically correct English sentence can have 0 meaning.
> I don't think there's still non ssl mail transport nowadays.
You might be off by 10%, unfortunately, but let's hope that 10% is just spam or other non-sensitive data.
https://transparencyreport.google.com/safer-email/overview
You might be off by 10%, unfortunately, but let's hope that 10% is just spam or other non-sensitive data.
https://transparencyreport.google.com/safer-email/overview
> Also: gpg as encryption isn't worth anything when everybody has your public key and/or sent it before via an unencrypted transport layer.
I think you need to read more about how asymmetric cryptography works.
I think you need to read more about how asymmetric cryptography works.
[deleted]
Even with passwords, e-mail is a likely password reset flow. If that’s the case, using a password only reduces security.
If emails can be intercepted most password based sites with an email based Forgot Password flow are vulnerable.
Ah, Math.random for generating credentials. In 25 separate function calls.
I know v8 probably inlines them, but that just feels very wrong. We got base58 for these cases.
I know v8 probably inlines them, but that just feels very wrong. We got base58 for these cases.
There are safer and more convenient passwordless authentication than this: crypto wallets (Metamask, Phantom, Terra Wallet just to name a few). It's all about the same, the user is prompted to sign a message with his private key, which can be verified on the back-end (and before someone asks: it doesn't involve a transaction with any blockchain thus is free and immediate).
Yes, but going with email is probably the best for Web2.
I’ve been doing this for a while now with many projects.
Essentially we have three ways to login: Google, Facebook and E-mail.
In all cases it delegates authority to an external place that you’ve setup before.
For the social networks we use the e-mail as the key.
For e-mail we decided to just send a code instead of using a url. Since the pattern of checking your e-mail on your device while working on your desktop is quite common.
Essentially we have three ways to login: Google, Facebook and E-mail.
In all cases it delegates authority to an external place that you’ve setup before.
For the social networks we use the e-mail as the key.
For e-mail we decided to just send a code instead of using a url. Since the pattern of checking your e-mail on your device while working on your desktop is quite common.
[deleted]
This looks pretty secure to me. Most of the time, I just have to click forgot password and it is basically the same thing.
I wonder why we have username/password. It seems to me, if you have a properly randomized password then you only need that. It's completely identifying. Copy your 256-bit key in from your password vault and voila.
Usernames are pretty lame anyway. They're just a 'guess a cute name nobody else used yet' game.
Usernames are pretty lame anyway. They're just a 'guess a cute name nobody else used yet' game.
How would you address other users? Using SHA of the password?
You can say what is suggested is similar to tripcodes used in some imageboards. If you put `User##password` (where `User` is optional) in the name field when you post something your name will be displayed (differs in each site) like `User!!rEkSWzi2+mz`. So your "account" is the password, no username is needed, and you can have a nickname if you want.
Folks could/should have as many contact aliases as they desire. They can send them securely to others whom they want contact with. A single username per customer is a lame approximation to what humans really want/need.
Further, it's not necessary to be a unique name - there are plenty of Joe's in the world already. It's not ambiguous if you're contacting the Joe you know.
In any case the username is unnecessary when authenticating. Why not prompt for address, or mother's maiden name too? It's all the same sort of weak 'authentication' that could be eliminated with a proper password/access key.
Further, it's not necessary to be a unique name - there are plenty of Joe's in the world already. It's not ambiguous if you're contacting the Joe you know.
In any case the username is unnecessary when authenticating. Why not prompt for address, or mother's maiden name too? It's all the same sort of weak 'authentication' that could be eliminated with a proper password/access key.
[deleted]
The first app I used that implements this is a great little campsite reservation app.
I usually come there from an email notification anyways and I find it much less annoying than fumbling for my phone to dig out a 2fa code.
Isn't it even more secure, because you don't have any password that could be leaked?
I was thinking about simplifying my setup by replacing Auth0 with Mailgun.
I was thinking about simplifying my setup by replacing Auth0 with Mailgun.
This creates a dependency on the email. If your email gets compromised/locked, your account gets too. OTP passwords are better
Sometimes, that’s exactly what you want though: you don’t care (and the user has bigger issues if their email is compromised) if the email is compromised. In the terms you might say “access is granted based on access to email that you register with” and if someone loses access to their email, you don’t need to do any id verification or “proof” to recover the account. You can just say “tough.”
> OTP passwords are better
For accounts which hold something of value (monetary and/or personal data) then sure.
But every once in a while when I need to login to GitHub it blocks my logon and demand what I give it a code sent to my e-mail. In essence this doean't seems that different from the scheme in the article.
For accounts which hold something of value (monetary and/or personal data) then sure.
But every once in a while when I need to login to GitHub it blocks my logon and demand what I give it a code sent to my e-mail. In essence this doean't seems that different from the scheme in the article.
Is there any evidence that email accounts have done anything besides become stickier?
Credential stuffers will have a feast on this one.
Another site that uses this method is mmm.page.
Sounds pretty cool! Anyone libraries for this yet
The last project I did sends the important URL to the users email. It’s Craigslist-style auth and it works pretty well.
It's convenient, yes. Unless you don't have mail setup on the machine you want to log in from. Then it's annoying at it's best...
Juste use Firebase/Auth0/anything else.
What a I missing ?
Generally speaking the 'just use X' reply, where X is a technology with more friction than whatever it's meant to replace it's a sure sign of not understanding the problem.
In this case it's right in the title: "Simple". Setting up connectivity to third party services like Firebase or Auth0 is not that.
In this case it's right in the title: "Simple". Setting up connectivity to third party services like Firebase or Auth0 is not that.
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.