There is another passwordless system called SQRL which is automated and more secure. From the user's perspective, they scan a QR code or click a browser extension and are signed into the site. Behind the scenes, a cryptographic challenge (a response URL + nonce) is presented to the user's phone or browser extension. The client signs the challenge using a per-site private key and sends the result to the provided URL.
Tiqr predates it and does the same thing. However, U2F and UAF from FIDO alliance are the new protocols that are being standardized, and they're looking good too.
It is even designed to inherently resist tracking across services by using unique keypairs per service in a clever way. No device identifier is ever shared.
According to Steve Gibson (SQRL's inventor) tiQr is quite different:
"It superficially appears to offer a user experience similar to SQRL. However, as is every other such system, what's going on is actually far more complex and involves/requires establishing “shared secret” account credentials with the authenticating website. As they explain on their technical page, TiQr is based on the OATH (open authentication) OCRA protocol suite, which was standardized by RFC6287."
I like the idea, but doesn't it come with a few security concerns? One blaring issue is that email is sent in plain text, so anyone can intercept it and log in as you.
I was originally going to complain that anyone who has access to your email now has access to all of your accounts, but upon further thought I don't know how much of a concern this really. First, the vast majority of people use the same password everywhere anyways. Second, most services use your email to reset your password anyways. The only security difference I can think of is if someone uses your email for a password reset and changes your password, it becomes very obvious there might have been a security issue when you try to log in and your password doesn't work. If all someone has to do is follow the link, there's nothing to create that suspicion.
A few other things to consider:
- How long does the token emailed to you last for?
- If I send a new token, do previous sessions expire?
---- If so, how can I be logged in via multiple browsers/computers?
---- If not, does an attacker have permanent access to my account if they got access to a single link?
When I implemented this, I made the following choices:
1 hour login email expire time by default, tunable. I'd make it shorter, but it has to get around greylisting.
Sending a login mail and logging in does not affect existing browser sessions.
Only allow a login email to be used one time.
Only allow the last login email sent to be used, not old ones. This and the expiry keep email archives from becoming a problem.
Another thing you could do is set a cookie and have the login link check for the cookie. That makes the link worthless even if the attacker intercepts it. But, it lets the attacker DOS a user and prevent them from logging in by continually requesting new login emails, so you'd probably want to allow previous login emails to be used.
Of course, as a user, how do I know which of these security tradeoffs a site has chosen? It's as bad as using a password and hoping they don't store in clear text. It would be better to have a protocol for login that makes clear choices.
I did the same with my app Piclr too. I have a timed expiry as I found people do not immediately sign up. Still tweaking it a bit. True now the email is a single point of failure, but 2 factor will help here. (https://itunes.apple.com/app/id889978045) Improving the world - with one password less at a time :-)
I don't see any mention of how log out works. Is it as soon as the browser window is closed? I'd find that a little annoying on my own device, but it would be essential on a shared computer-- at the library for example.
I'm thinking a checkbox saying "Shared Computer" and issues a link with a different session length (or logout on window close) if checked?
Personally I love this idea as managing passwords has become really unwieldy and I don't trust any password manager service. Plus for a few sites that require really bizarre password length/character requirements/etc., I just reset them overtime I want to log in anyway.
The article explains an alternative authentication scheme, it has no bearing on how session is managed after authentication took place. That's a fancy way of saying "same as before": some sites will stop session when the browser is closed, some will keep the session for days or weeks, and some will offer a "remember me" option at login.
I don't think this pattern requires a change to how log out works. It's just a change to creating a session and shouldn't impact ending one.
I'm definitely in favor of making people create fewer passwords. It's a nuisance that probably has a net negative affect on security by encouraging people to re-use weak passwords.
Incognito Mode, In Private Mode, whatever you want to call it. Browsers now give you a spiffy, hard to miss logo when in such a mode these days now too.
As the article said, this is a replacement for the password login system. The 'mailed-token' login system is just another way to receive a session that is logged in with that user, and therefore has the same limitations and possibilities as the password login system.
These are one-time use tokens, just like you should use for a "Forgot Your Password" email login. It's literally the same steps, just there's no new password to input, the website just gives you a login cookie and you can go about your day.
The point is that the most commonly used e-mail protocols do not have safety built in. The solutions for this problem (e.g. PGP signing) are not adapted widely enough to be considered adapted by the market.
If you'd want to use two-factor authentication by verifying access to the mailbox, you have to make sure that that (the connection to) the mail box is safe as well, which can potentially be very hard.
The mailbox still is a safe, but only from the moment that the mail has been sent to the moment the page has been requested. Mind that a safe connection to your mailbox does not also mean a safe connection to the server, but that is something that is covered by https+certificates (mostly).
As elcapitan pointed out, if your email, or even the route mail takes to get to you, was compromised then an attacker would already have access to your accounts by simply forcing a password reset.
This is no worse a security footprint than the existing, requisite "Forgot Your Password" flow. It's the exact same security footprint.
TLS is already an under-spoken requisite of SMTP communications from any webserver doing "Forgot Your Password" workflows. TLS between mail servers is also already a de facto SMTP requirement for most bare minimum spam fighting mechanisms.
True that the password reset and the "login" using this proposal travel the same path and present the same attack vector but there is some disadvantage to the frequency in which the "login" system would travel down this less-than-secure path. The more times you use this the more likely that someone will just happen to be watching and waiting at the right time.
Let's not forget that most of the email system is still not encrypted (last time I checked anyway) even though the last mile between your mail server and your client may be.
Frequency is also essentially the same: you can request a new login token equally as often as you can request a new "Forgot Your Password" token in that they are both manually requested with only an email address.
There are also already a growing number of users that use "Forgot Your Password"-only login (most accidentally; human memory is porous) day to day.
Which is not to say that we shouldn't make email better and more secure, but that the security of our email infrastructure is a red herring of sorts in the larger security discussions of "passwordless" login, given that we are already equally insecure in every website that has a "Forgot Your Password" button that accepts anyone's email address.
This is inherently a password in the form of a url similar to using REST which still requires a password to obtain the link in the first place (email) I only see this as a partial solution.
All non-PK cryptography eventually boils down to a 'password' if you call it that.
But this isn't a password, it's a shared secret. Which IS a good solution (not GREAT, but better), it just shifts the problem into communicating the shared secret. This is where TOTP comes in for most 2FA implementations. This particular scheme just uses email.
This is clearly a Worse is Better solution. Where the "worse" is the complicated and often not user-visible process involved in getting the login email to them in a timely manner.
That said, I implemented it a while ago, since there's no widely deployed distributed alternative, and as seen with OpenID, attempts to create one will be frustrated by entrenched interests and technical debt.
I still think that Mozilla could have gotten around that problem with Persona if they had built it right into the browser. Pity.
So does this mean one has to go into their email everytime they need to log in, or just until the cookie expires? I assume it's the latter.
It's a little more inconvenient in the second instance that traditional password entry (given that all my passwords are saved in Chrome), but sounds a lot more secure. Especially since I use a hard gmail password and two factor authentication to access email.
Would be nice to add a 'log out on all machines' link to the email with the password button as well.
Just until a session cookie expires. Session management can/should be much the same as you would expect.
The benefit here for you, though, is that you get "free two factor" on these sorts of sites, without those sites having to implement it, simply because you use a two factor email. It's a rising security tide, of a sort.
It would be cool if someone does an A/B testing over a significantly big population of users and show us the dropoffs on each version. I would love to have no password login (temp token), but if the users don't receive them on time (email deliverability might be laggy at times), or they don't get the idea, or they don't care/like the method.. Well, you got my point.
It introduces the idea of a "signed URL", which can be verified or rejected based on checking a signature query parameter. You can send such a signed URL via email, text message, etc.
Any reasons why this cant be done using push messages?
Another way could be to send an intent to the right app using some special email header (X-App-Scheme) by the mail app.
The current email login flows force the user to open the mail app and to click the link inside the mail (which then normally opens the app using a registered scheme).
Paswordless login actually fits even nicer in mobile.
You can make the email link open as a deep link in the app and continue right where you left. Context switching in the app is minimal and in mobile apps sessions are usually more persistent anyway
I described the way it is currently done on mobile devices but i was thinking about a way to even cut that context switch by letting an app react to an email rather than handling the link scheme.
These tokens should not be able to be reused, even if found in browser history. Additionally, the HTTP flow is to 301 redirect to the user's homepage or dashboard and browsers tend not to bother storing URLs that result in 301 redirects.
Great, so now instead of a password to remember, I have to remember a link? How is that substantially different from carrying around emails with passwords in them? Or with dynamic links, I now have to go through a separate application with an extra click-link-to-login-then-close-tab-and-find-original-tab motion?
Instead of logging in by opening a password safe, I now have to log in by opening email... and have a new source of email clutter... and can't share an account with other people... and disposable emails for signing up to less reputable services becomes less of an option.
And what happens when you move email addresses? Or there's a problem with email (delays are common)? A password safe that relies on an asynchronous messaging protocol? Yuck.
Login on new machine (Email + password)
They send me an email with a short code (~6 characters)
I copy/paste those few characters
They remember that machine for ${a-long-time}
https://www.grc.com/sqrl/sqrl.htm