Simple passwordless authentication for web projects
matthewc.dev
matthewc.dev
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.
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
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 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".
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.
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.
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?
> 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.
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.
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.
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.
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 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.
> 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.
It's the easiest login method by far to deploy, though I think users seem to slightly dislike it.
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.
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.
Many sites require some kind of OTP anyway. Is it secure to use email+otp only for login authentication?
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.
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.
You might be off by 10%, unfortunately, but let's hope that 10% is just spam or other non-sensitive data.
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.
That said, if an attacker had persistent access to your email, you’d still be compromised through this method.
I think you need to read more about how asymmetric cryptography works.
I know v8 probably inlines them, but that just feels very wrong. We got base58 for these cases.
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.
Usernames are pretty lame anyway. They're just a 'guess a cute name nobody else used yet' game.
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.
I was thinking about simplifying my setup by replacing Auth0 with Mailgun.
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.
In this case it's right in the title: "Simple". Setting up connectivity to third party services like Firebase or Auth0 is not that.