17 ms·

Passwordless authentication: Secure, simple, and fast to deploy

279 points by bpierre 12y ago

ravloony 12y ago
Doesn't this mean that an attacker now only needs the password to the email account and all these passswordless services get compromised as well?
- rikkus 12y ago
  Yes. But this is the case with the current 'forgotten password' system. Securing your email account can be done without 'only' using a password. I use 2 factor auth on my google accounts, for example.
  - ravloony 12y ago
    As do I. But I would love to see the stats on the active account (used by a real person) vs active account with 2-factor ratio on GMail. I'm willing to bet the takeup is fairly low. As I mentioned elsewhere in the thread, I missed the password reset link point. I stand corrected.
  - peterwwillis 12y ago
    Forgotten password systems are supposed to use challenge questions to authenticate the user before resetting the password. (Of course, those same sites often provide a way to reset using challenge questions and without an e-mail confirmation, which is how celebrity accounts get compromised)
- alnorth 12y ago
  Yeah, but you're not introducing a new failure point. Most services already let you reset your password - as long as you can click a link they send to you in an email.
  - ravloony 12y ago
    Of course, missed that somehow. With that out the way, this is really interesting stuff, although some people may end up with crowded inboxes.
  - edwintorok 12y ago
    If you reset the password the user would notice that he can't login next time. If you steal&delete the email with the one-time login token the user won't notice, so there is a difference...
- Sekhmet 12y ago
  If you have someone else's mail you can compromise standard (with password) services as well.
  - edwintorok 12y ago
    Except in that case you would know it got compromised. If you reset someone else's password via email you would notice yourself when you want to login that your old password is not accepted anymore. With these one-time auth tokens there is no way to know you got compromised, since sending another one-time token will 'just work'. This would be great as part of a 2-factor scheme though.
- pillfill 12y ago
  Sure, but you're missing the bigger picture- The point is to reduce the total number of passwords a user has to manage in general. The fewer passwords you have to remember, the more likely you are to protect those few 'root identity' accounts (by using a strong auth/password).
  - ravloony 12y ago
    One assumes. I am not sure that that would be the case. I remember when my non-tech friends only had email and maybe MSN and their passwords were not secure in any way, even for the time. There is more awareness now, though, so maybe.
scrollaway 12y ago
I really believe in Persona. This is an interesting evolution of it. Any Passwordless dev around? Care to shime in on this? Edit: To be more specific, "token-based auth" is an interesting take on the browser-based auth concept. I still think the latter is what will eventually be the solution to the growing auth needs of the web: Authenticate to your browser and your browser authenticates to web apps for you. We see the same thing happening on mobile with apps (eg. on Android, users log into their google account on the android system itself).
- AhtiK 12y ago
  Persona is no longer developed by Mozilla -- Persona team has been moved to other Mozilla projects: http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership http://identity.mozilla.com/post/78873831485/transitioning-p...
  - scrollaway 12y ago
    I'm well aware it's no longer funded but it is still maintained.
  - callahad 12y ago
    Maintenance of Persona is funded (and staffed), new development is on a volunteer basis. However, there has been some renewed interest in hacking on the codebase (including some pretty significant cleanup). Our immediate goals are separating out Persona's various components into discrete modules and getting new contributor documentation into place. If you're interested in diving in, join the dev-identity mailing list and drop me a line: https://lists.mozilla.org/listinfo/dev-identity https://lists.mozilla.org/listinfo/dev-identity
    - scrollaway 12y ago
      Dan, what do you guys need help with? I've attempted joining you guys in the past but the IRC channel was dead for three days and the dev-identity list looks overrun with spam.
wiremine 12y ago
While this feels similar to a password reset process, it is different: a. you're sending the auth credentials every single time a user wants to login. If email was secure, that might be fine, but it's not. b. On a password reset, you typically require a user to actually reset their credentials, and then allow them to continue. In this case, if someone accidentally forwards the email, or enters the wrong email address, the recipient automatically gets access to the account, no questions asked. It is an interesting concept, though. I don't really know if I like it yet, but it's nice to see people trying to work on this problem.
- thesumofall 12y ago
  b.) wouldn't make a difference if the account is compromised
  - wiremine 12y ago
    It would in cases where there wasn't an _intentional_ attack. If I accidentally sent a log in email to my Mom, and she clicked it, odds are she wouldn't know what was going on: there is no challenge screen asking for a new password. She's just see my account.
- dbla 12y ago
  Account recovery emails should probably use one time tokens, meaning that after you click on the link once, the link becomes invalidated. This would largely solve the issue with point b.
  - PythonicAlpha 12y ago
    Not only one time tokens, but with limited life-span. So after a while the token expires and is useless. This is a must for such a scheme.
    - sturadnidge 12y ago
      Both of these, plus a differentiator between 'current' and 'new' token requests - without that, it's an easy way to log people out of sites by simply knowing their email address. To the point about not always having access to email, it's a pretty simple denial of service vector.
s369610 12y ago
just needs a browser plugin to check your mail via imap for any email containing a token link to any of your open tabs and to automatically auth you...
- ttty 12y ago
  That seems amazing (:
steakejjs 12y ago
FD I work for a password manager...but I would still think password managers are better even if I didn't. 1) Password managers have security qualities built into them, example forced logoff after X amount of time. Someone who leaves their email up is still leaving themselves available for an account theft. The password requires a key to decrpyt. This isn't the case for email 2) Email is not meant to be secure and attempts to do so have gone pretty badly. A lot of the big email providers are leaps and bounds ahead of where they were 5 years ago but email as a whole is still broken. I think this is really cool and has a lot of potential, but these things still need some work. You probably shouldn't be rolling this out on things that require a high level of security.
- thesumofall 12y ago
  Yes, password managers are absolutely the better solution, if we can convince every person to use one :-)
  - robomartin 12y ago
    How about a review of the top password managers. I've been using Keeper but the last software update spooked me (couldn't access db). Thinking about migrating to LastPass. Ideally want to store more than just passwords. For example, images of personal and business documents.
- netcan 12y ago
  Would it be better if password managers were built into devices in the first place, laptops, phones, etc.?
  - thisishugo 12y ago
    OS X and iOS have this, it's called Keychain, and it even works cross-device[0] totally securely[1]. Safari recently (I can't remember when) started suggesting passwords, too. Being built into the OS makes it an order of magnitude more likely to be used than a third party application, in my opinion. [0] http://support.apple.com/kb/ht5813 http://support.apple.com/kb/ht5813 [1] i.e. Apple (claims it) can't access your passwords, despite syncing them across devices.
deleted 12y ago
[deleted]
smackfu 12y ago
Using SMS for this may work better than email. Email passwordless tends to get bogged down in little problems. Like the email is slow or goes to the spam folder. Or on mobile, clicking a link in an email may not take you into the web browser you actually want to use the app in. SMS at least should improve on these two problems.
- thesumofall 12y ago
  Passwordless would allow you to do that quite easily. Only risk are the shorter tokens (can be balanced by shorter validity, though). There is a short description of how to do it in the documentation
- mikevm 12y ago
  SMS is unreliable. It may arrive in an hour, the next day, or not at all.
  - smackfu 12y ago
    In practice, it seems about as reliable as email, and faster to get to me.
mtck 12y ago
Is there any advantage of this over using Oauth to 'Sign-in with Google/FB' other than being platform agnostic? similar workflow except tokens are being exchanged between server-server vs sever-email.
- marco1 12y ago
  No, except that SSO via such a service is more secure than the email approach. However, being platform agnostic is quite an important reason.
- anywherenotes 12y ago
  A lot of times websites start requesting permission to know your name. With email only, they wouldn't have the option.
marco1 12y ago
The very website they link to [1] via its HN thread [2] states correctly that: "No, email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Users might also have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). And what about if their email provider gets hacked or their backups stolen?" Mozilla should know that email is not an adequate medium for one-time password delivery. They are replacing strong authentication (2 factors) with its second factor alone. [1] http://plaintextoffenders.com/faq/devs http://plaintextoffenders.com/faq/devs [2] https://news.ycombinator.com/item?id=7943365 https://news.ycombinator.com/item?id=7943365
- okbutnormally 12y ago
  > They are replacing strong authentication (2 factors) with its second factor alone. Are they? They don't mention anything about replacing 2 factor here. A typical login is compromised if you know the password or if the email is compromised. This is not increasing the attack surface.
  - andrewstuart2 12y ago
    One problem is that SMTP itself [1] is just a plaintext email format. Sure, you can send it over a secure connection and most do, but that's left completely up to the provider to decide and therefore never guaranteed. [1] https://www.ietf.org/rfc/rfc0821.txt https://www.ietf.org/rfc/rfc0821.txt
    - Fuxy 12y ago
      This is by no means a very secure option but do you really care if your www.anime-planet.com or konachan.com account don't use 2 factor authentication. Some websites just don't need such a high level of security plus you could argue they are probably less careful with your password than say Google is with your email. Now it can still be hacked but you could argue this is probably an increase in security although it does create a central point of failure just like password managers. Nobody says Google or Amazon should start using this but websites with a lower requirement of security shouldn't inconvenience their users unnecessarily. If you're only need is to identify the user for something banal that couldn't do much damage if it gets hacked then this is a good solution.
pdkl95 12y ago
This looks suspiciously like OpenID with the identifiers changed from URLs to email addresses and updated to use modern pop development tools. I really liked OpenID, even though it had a few issues. The best part was that you could put a few HTML tags at the URL you used as your identity and delegate the authentication - but not the identity - to a 3rd party. Because you controlled the identity, you could drop the 3rd party and use someone else (or implement the OpenID protocol yourself locally) just by changing some tags. If "Passwordless" can provide this can provide the same level of autonomy, it could easily become my authenticator of choice. It looks like it's tied to an email account? Slightly annoying, but trivially worked around if necessary.
- tomp 12y ago
  I don't know how it's implemented, but I see no reason why adding/removing emails to/from an existing account (while logged in) wouldn't be trivial to implement. The only thing you need to be careful with is to send a notification to the email being removed, send notification to all emails when a new one is added, and enforce some kind of expiry period before a removed email becomes inactive/added email becomes active.
- thesumofall 12y ago
  It is not necessarily linked to an email account. It's up to the lookup middleware that has to be programmed by the implementer how to translate the login into an email address / phone numbers
mixedbit 12y ago
One of drawbacks of this mechanism compared to Persona is that a web server needs to be configured to send emails with tokens using site's own email credentials. This isn't easy to setup reliably for a small site. A malicious user can easily trick the server to send many tokens to different accounts and cause the sending email to be included on spam blacklists.
- tomp 12y ago
  How is that different from registering many user accounts with many different emails, or using the "Forgot Password" feature using many different emails?
  - mixedbit 12y ago
    If you use Persona, the site doesn't need to send any emails (As I wrote this is a drawback in comparison to Persona, a traditional password based mechanism has the same problem).
trvz 12y ago
Is this the fourth or fifth try of Mozilla to replace passwords? Surely it will work _this_ time… Edit: …which makes it totally sensible to invest time building your site up relying on this stuff.
- mixedbit 12y ago
  I only hope that an intention of this project isn't to "smoothly" kill support for Persona. From a PR perspective this could look nicely: we kill the project that you depend on, but here is some quite inferior alternative that has zero maintenance cost for us.
  - callahad 12y ago
    I don't believe that's at all the intention. However, I am quite interested in this approach, and will be watching Webmaker closely as they roll out a similar scheme. If it works, I'd likely be in favor of transitioning the Persona fallback from long-lived passwords to single-use email tokens. After discussion on the mailing list, of course. (FWIW, dochtman and I maintain Persona)
- jaredsohn 12y ago
  >Is this the fourth or fifth try of Mozilla to replace passwords? No. https://news.ycombinator.com/item?id=8459114 https://news.ycombinator.com/item?id=8459114
mankins 12y ago
I implemented something like this as an alternative to the OpenId logins when I was at Fast Company. I believe it's still in use there if you click the person icon to login at the top right, select other options, and then "send me a one time link". Try it out? We did this because we had people that didn't have Twitter or Facebook logins and needed to use some service that we had. I didn't want to build out a password database so came up with this work around. Surprisingly we didn't receive that much hate mail about it, and we have a fair amount using it per day, so I'd say that people like it.
Xeoncross 12y ago
The main problem I have with this approach is a theoretical one: What if I can't get a cell phone or permanent email address? You have to pay to have a phone and possibly have approval from the network/government to join. Email is a lot better since it's a totally open network. However, Even then I'm leaving myself open to MITM attacks, being locked out of my email by government orders, ISP complaints, company lawsuits. I will never be locked out of my passphrase. With that said, after almost creating swiftlogin to do this very thing, I would support this effort as long as this does not become the one true way.
- deleted 12y ago
  [deleted]
throwaway9724 12y ago
At my company we've been using this technique for years. Users have always hated it and after waiting a long time for people to come around, we are now transitioning back to traditional login mechanisms. The basic reasons users hated it was that a login mechanism needs to be reliable. In particular, we make business software, so if the user was ever unable to get into the system it was a big problem. While it may seem that you "always" have access to your email, or sms. Not all users (especially non-technical users) always have access to these things. Meaning, even if they have access 98% of the time, that other 2% of the time infuriates them. It was also a usability nightmare among non-technical users. Traditional login mechanisms dont necessarily mean a more usable experience, but its a pattern that everyone knows. I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it.
- tngme 12y ago
  This is a fair point considering the use scenario that you describe. For other website this might look very different: Think of all those small websites for which you had to create logins but that you rarely use. They are a huge risk due to people's tendency to reuse passwords across important & unimportant sites. For those smaller sites people might not even recognize this system as a traditional login: They simply come back to the site, are asked for their email address if they want to get back to their information, and shortly thereafter they have a link in their inbox to their details/comments/favorites/...
- tracker1 12y ago
  This really affected me the one day in the past 3 years that I forgot my phone in the morning... There was one site I had enabled 2FA (two factor authentication) on that I hadn't logged in from work yet, and it was really a pain not being able to access it. Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites... Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.
  - 12y ago
abalone 12y ago
Previous HN discussion: https://news.ycombinator.com/item?id=8446232 https://news.ycombinator.com/item?id=8446232 A major drawback here is that it's incompatible with password managers which are a better, more generally-applicable solution. Relying on email means that if your email delivery is high latency or having an outage or an aggressive spam filter then your account access in impacted. Keep in mind not everyone gets their email right away -- many people (my mom) are on >10 minute pull intervals.
- PythonicAlpha 12y ago
  I agree, that eMail as transport media is far from optimal, but it is the only general available media currently. I still think that from the point of usability a passwordless solution is better for many applications, where security is not the top priority. Because so many applications in the web force you to have a password, security in general is at risk. Most people get tired of passwords and use either bad passwords or just one for all. And those passwords are endangering those applications that are really security sensitive. I would rather like to see, that only a few services (like banks, ...) want to have a password and the others just authenticate their users with less intrusive means.
  - abalone 12y ago
    > Most people get tired of passwords and use either bad passwords or just one for all. That is what password managers fix. iCloud Keychain has gone a long way towards mainstreaming this. It's built in to Safari and securely stored, encrypted with your OS/device's master password -- which is an improvement on Firefox & Chrome's approach, where master passwords are optional. From a usability standpoint that email method is way worse, at a minimum due to the latency issues. Waiting a minute for an email to arrive can feel like an hour when you're trying to log in to do something urgent. Password managers work "magically". For a security standpoint the email method is also worse, because it is only usable with very long-lived sessions -- which is not the best security practice. The article even heavily qualifies this method as not appropriate for sites users "visit frequently". So by the author's own logic, this method is only appropriate for sites that NO users visit frequently. Which is no sites. Finally, the nail in the coffin for the email approach is that it's incompatible with the more general password manager solution. So those users who do need to visit a given site frequently can't use a password manager (at least without redirecting themselves to an alternative method, which is also poor usability).
harshreality 12y ago
The FIDO alliance has a working solution to the annoyance of the 2nd factor. It requires mobile device support or a hardware token (Yubikey Neo as of October supports the FIDO protocol), but it's much better than standard existing 2-factor because it doesn't require typing in a code from a dongle or app. Instead, the app or dongle authenticates directly once user presence (or in some cases, depending on the dongle or app, biometrics) are confirmed. That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications). For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually. Email or text message, even if secure (text messages are not, and emails are probably not) require internet access. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened. A good presentation on FIDO is here: http://www.yubico.com/2014/07/future-online-authentication/ http://www.yubico.com/2014/07/future-online-authentication/ There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.
- peterwwillis 12y ago
  Sorry, I don't watch hour-long presentations when all I want is a bullet list of features and requirements. So I have no idea how FIDO actually works. Here's what I will say: the best combination of security and usability would come in the form of an app that bridges an automatic communication (such as from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider (either in software or hardware) and a prompt to the user to submit the token over a secured connection to the requesting provider. For internet-less use, you'd simply generate and copy the token the way Google Authenticator works now. From the looks of the NEO & U2F yubico page, it sounds like this is similar to what they're going for; is that correct?
tylerg 12y ago
Kudos to Mozilla for trying a new way to simplify passwords. Very similar to something we implemented at Shop It To Me in June and that appeared in Hacker News. Here's the link with the conversation: https://news.ycombinator.com/item?id=7818584 https://news.ycombinator.com/item?id=7818584 And here's the announcement. http://blog.shopittome.com/2014/05/29/bye-bye-passwords/ http://blog.shopittome.com/2014/05/29/bye-bye-passwords/ Overall it has worked very well for us and is no less secure in my opinion than all the reset password options. 2-factor authentication is still better though and should be used for the sites requiring the most security.
- thesumofall 12y ago
  It's not a Mozilla solution, though, says the developer :-) Hacks is simply publishing about it
anywherenotes 12y ago
There are a lot of websites that are not worth the hassle of registering for, but this can make registering on them easy and they may get more registrations. For important accounts I would still prefer a password only stored in your head and two phase authentication. But for various forums, this type of a setup is better than using third party password manager or same-username-password combination for general purpose.
drikerf 12y ago
Great idea, I can see that this would be awesome on services I use seldom and often forget my password anyway. But do the average user really care enough to bother with email? or for SMS, will they give away their phone number? Remembering users for a long time also opens up for other breaches. Anyway it is awesome that people are working alternatives!
adventured 12y ago
I've tried throw-away email based passwords twice in the last five years. Every time I try it I run into the same problem: guaranteed speed and guaranteed delivery of email (both in general and that it'll always arrive in the inbox). Average users get annoyed very quickly when they have to wait even minutes for an email to show up. I still run into this problem even when using quality services such as Mailgun. For this approach to work, it requires at least three things 1) Much greater security for email 2) Guaranteed speed of delivery for every email, such that the throw-away password arrives in seconds at a 99.x% rate 3) Guaranteed delivery, such that throw-away passwords arrive in the inbox at an extremely high rate of success (at least 99.9%) Email will never be able to deliver on these requirements. As such this system will never be effective for deployment on a service that average users use.
INIT_6 12y ago
I think a good middle ground would be to implement this idea into a password manager. You have one strong password to unlock your manager. Sites that support passwordless Would send it to the password manager. Otherwise use it as normal. As long as the password manager is supported on all platforms I think this would be the best solution. As for how it would communicate I always prefer pull rather than push.
peterwwillis 12y ago
Passwordless logins, as implemented today, are less secure than password logins. Flaws in the passwordless login system: 1. Authentication is done on unsecured connections. With all of the shouting over privacy and security, here we are abandoning secured, encrypted connections for SMSes and e-mail, two unencrypted, unauthenticated, somewhat unreliable, easily intercepted, plaintext messaging systems. 2. Replacing an out-of-bound token with one stored purely online. Any actor who controls the network (or your computing device) can subvert the login. 3. Depends on a pre-existing authentication, which itself uses passwords (or none at all), leaving you at the exact same state of security as you had before. Instead of two passwords that are the same, you have one password (the e-mail password) that is the same, or zero authentication with SMS. 4. No mandate for multiple-factor auth, nor out-of-bounds auth. 5. Zero security for the tokens (cookies) stored on the user's system, so data at rest is at risk, unless your browser encrypts cookies with a master password. Of course this is moot considering the total lack of encryption on the smtp/sms side and the lack of out-of-bounds auth. Reasons why password logins are more secure: 1. Uses secured, encrypted connections to transmit secrets. Prevents man in the middle attacks and interception of logins. 2. Provides an out of bounds auth token. The only way to subvert this is to intercept it as it goes into a computing device, meaning either the client or server would have to be compromised at the time of login. 3. Data at rest is encrypted and only the user's cached token (cookie) can be used to steal a pre-authenticated login. 4. Password can be unique to the service, so a compromise of one system does not compromise all. 5. Industry standard is already to require multiple-factor authentication to be combined with this method for increased security.
xnull 12y ago
Why not PAKE? "The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a." You can salt/password manager/email retrieve on the client side however you want to strengthen you passwords or escrow keys without needing to share state with third party services at all. And they never get a copy of your creds. The server side can easily rate limit guesses per account, report access times, and/or require CAPTCHA challenges. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...
e0m 12y ago
I think we sometimes forget the number of users who would try and get to your service, then bail because they need to boot-up Outlook, or work in a building with no cell reception.
passfree 12y ago
A similar idea was discussed here (http://www.gnucitizen.org/blog/simple-universal-authentication-system/ http://www.gnucitizen.org/blog/simple-universal-authenticati...) in 2008.
SoftwareMaven 12y ago
With the exception of automatically grabbing the token, it's pretty much the same as BYU's SAW[0]. I worked for a startup that was trying to commercialize this technology, but it's nearly impossible to commercialize an authentication tech. It's unfortunate, too, because I think it would make a much better option than most password managers. 0. http://isrl.byu.edu/projects/simple-authentication-for-the-web/ http://isrl.byu.edu/projects/simple-authentication-for-the-w...
codezero 12y ago
This is interesting. A lot of social networks use this sort of authentication for their email notifications, and weekly/daily digests, but don't treat it as a first class login. Facebook, LinkedIn, Twitter, Quora, etc... use a short expiration on these, but if you ever forward one of your new notifs to a friend, they will end up logged into your account, which is surprising. It usually only lasts for the session, and some are pretty good about double checking if you are coming from a new location or have cookies for another account set :) For longer lasting sessions, email security seems like a big concern, especially since most people keep all their email forever (gmail) and it's easy to search through.
- thesumofall 12y ago
  Almost :-) The tokens are one-time only. Afterwards the session is keeping track of the user. Another login requires a different token. Regarding the emails of Facebook, etc.: Great example, actually! I guess the problem really is that they don't make it obvious to users that they actually hold an authentication token in their hands.
  - codezero 12y ago
    Yeah I assumed they were one-time only. In examples I've seen, each link had a different token, so if you forwarded something, one of the links may work if you hadn't clicked that particular one. When ever I explain this to people, and forward them one of my notifs from Facebook, they get pretty paranoid and shocked, then eventually accept it because of the convenience :)
Oblouk 12y ago
I do not see the benefit of this from a usability standpoint. From a security standpoint it seems like an absolute nightmare. If you lose the password to your email you could lose access to all your accounts. Most people do not own their own email server and so this could have catastrophic security consequences. Of course the sites could check for IP location consistency but in order to spot security threats early you would need to track logins to multiple sites. The only way to do this would be to either give another third party company the ability to track logins and implement fail safes. At that point it begins to operate a lot like the companies which allow third party authentication through Facebook/Twitter/Email.
- penprog 12y ago
  Considering that for most websites one can easily reset the password to your account if they have access to your email, this adds no extra security risk (for those situations which are most common websites eg. Amazon, facebook, twitter etc). So this is NOT catastrophic for security because the current situation is already like this. For websites where security is a larger issue, this obviously wouldn't be the solution.
thesumofall 12y ago
Someone just made me aware of www.cotap.com - It's probably using a different middleware, but I think a perfect example of where passwordless login makes great sense!
konceptz 12y ago
One thing I like about having different passwords and logins for each site is that I don't have to worry about cascading failures. This seems like it isn't getting rid of user/pass authentication, it's just pushing it onto someone else, in this case your cell or email provider. Other users have correctly stated that this doesn't increase the attack surface, however it does increase the value of a single vector. Please correct me if I've missed a key point in the OP, I didn't spend lots of time reading the finer points of the implementation.
- twodayslate 12y ago
  Your email is already a single vector. Most sites have a "forget my password" link and all you need is the email account to reset the password and access the account.
throw7 12y ago
This requires javascript on the client no? That's a no go for me. The little demo site fails for me.

279 points by bpierre 12y ago

Doesn't this mean that an attacker now only needs the password to the email account and all these passswordless services get compromised as well?

rikkus 12y ago
Yes. But this is the case with the current 'forgotten password' system. Securing your email account can be done without 'only' using a password. I use 2 factor auth on my google accounts, for example.
- ravloony 12y ago
  As do I. But I would love to see the stats on the active account (used by a real person) vs active account with 2-factor ratio on GMail. I'm willing to bet the takeup is fairly low. As I mentioned elsewhere in the thread, I missed the password reset link point. I stand corrected.
- peterwwillis 12y ago
  Forgotten password systems are supposed to use challenge questions to authenticate the user before resetting the password. (Of course, those same sites often provide a way to reset using challenge questions and without an e-mail confirmation, which is how celebrity accounts get compromised)
alnorth 12y ago
Yeah, but you're not introducing a new failure point. Most services already let you reset your password - as long as you can click a link they send to you in an email.
- ravloony 12y ago
  Of course, missed that somehow. With that out the way, this is really interesting stuff, although some people may end up with crowded inboxes.
- edwintorok 12y ago
  If you reset the password the user would notice that he can't login next time. If you steal&delete the email with the one-time login token the user won't notice, so there is a difference...
Sekhmet 12y ago
If you have someone else's mail you can compromise standard (with password) services as well.
- edwintorok 12y ago
  Except in that case you would know it got compromised. If you reset someone else's password via email you would notice yourself when you want to login that your old password is not accepted anymore. With these one-time auth tokens there is no way to know you got compromised, since sending another one-time token will 'just work'. This would be great as part of a 2-factor scheme though.
pillfill 12y ago
Sure, but you're missing the bigger picture- The point is to reduce the total number of passwords a user has to manage in general. The fewer passwords you have to remember, the more likely you are to protect those few 'root identity' accounts (by using a strong auth/password).
- ravloony 12y ago
  One assumes. I am not sure that that would be the case. I remember when my non-tech friends only had email and maybe MSN and their passwords were not secure in any way, even for the time. There is more awareness now, though, so maybe.

scrollaway 12y ago

I really believe in Persona. This is an interesting evolution of it. Any Passwordless dev around? Care to shime in on this? Edit: To be more specific, "token-based auth" is an interesting take on the browser-based auth concept. I still think the latter is what will eventually be the solution to the growing auth needs of the web: Authenticate to your browser and your browser authenticates to web apps for you. We see the same thing happening on mobile with apps (eg. on Android, users log into their google account on the android system itself).

AhtiK 12y ago
Persona is no longer developed by Mozilla -- Persona team has been moved to other Mozilla projects: http://identity.mozilla.com/post/78873831485/transitioning-persona-to-community-ownership http://identity.mozilla.com/post/78873831485/transitioning-p...
- scrollaway 12y ago
  I'm well aware it's no longer funded but it is still maintained.
- callahad 12y ago
  Maintenance of Persona is funded (and staffed), new development is on a volunteer basis. However, there has been some renewed interest in hacking on the codebase (including some pretty significant cleanup). Our immediate goals are separating out Persona's various components into discrete modules and getting new contributor documentation into place. If you're interested in diving in, join the dev-identity mailing list and drop me a line: https://lists.mozilla.org/listinfo/dev-identity https://lists.mozilla.org/listinfo/dev-identity
  - scrollaway 12y ago
    Dan, what do you guys need help with? I've attempted joining you guys in the past but the IRC channel was dead for three days and the dev-identity list looks overrun with spam.

wiremine 12y ago

While this feels similar to a password reset process, it is different: a. you're sending the auth credentials every single time a user wants to login. If email was secure, that might be fine, but it's not. b. On a password reset, you typically require a user to actually reset their credentials, and then allow them to continue. In this case, if someone accidentally forwards the email, or enters the wrong email address, the recipient automatically gets access to the account, no questions asked. It is an interesting concept, though. I don't really know if I like it yet, but it's nice to see people trying to work on this problem.

thesumofall 12y ago
b.) wouldn't make a difference if the account is compromised
- wiremine 12y ago
  It would in cases where there wasn't an _intentional_ attack. If I accidentally sent a log in email to my Mom, and she clicked it, odds are she wouldn't know what was going on: there is no challenge screen asking for a new password. She's just see my account.
dbla 12y ago
Account recovery emails should probably use one time tokens, meaning that after you click on the link once, the link becomes invalidated. This would largely solve the issue with point b.
- PythonicAlpha 12y ago
  Not only one time tokens, but with limited life-span. So after a while the token expires and is useless. This is a must for such a scheme.
  - sturadnidge 12y ago
    Both of these, plus a differentiator between 'current' and 'new' token requests - without that, it's an easy way to log people out of sites by simply knowing their email address. To the point about not always having access to email, it's a pretty simple denial of service vector.

s369610 12y ago

just needs a browser plugin to check your mail via imap for any email containing a token link to any of your open tabs and to automatically auth you...

ttty 12y ago
That seems amazing (:

steakejjs 12y ago

FD I work for a password manager...but I would still think password managers are better even if I didn't. 1) Password managers have security qualities built into them, example forced logoff after X amount of time. Someone who leaves their email up is still leaving themselves available for an account theft. The password requires a key to decrpyt. This isn't the case for email 2) Email is not meant to be secure and attempts to do so have gone pretty badly. A lot of the big email providers are leaps and bounds ahead of where they were 5 years ago but email as a whole is still broken. I think this is really cool and has a lot of potential, but these things still need some work. You probably shouldn't be rolling this out on things that require a high level of security.

thesumofall 12y ago
Yes, password managers are absolutely the better solution, if we can convince every person to use one :-)
- robomartin 12y ago
  How about a review of the top password managers. I've been using Keeper but the last software update spooked me (couldn't access db). Thinking about migrating to LastPass. Ideally want to store more than just passwords. For example, images of personal and business documents.
netcan 12y ago
Would it be better if password managers were built into devices in the first place, laptops, phones, etc.?
- thisishugo 12y ago
  OS X and iOS have this, it's called Keychain, and it even works cross-device[0] totally securely[1]. Safari recently (I can't remember when) started suggesting passwords, too. Being built into the OS makes it an order of magnitude more likely to be used than a third party application, in my opinion. [0] http://support.apple.com/kb/ht5813 http://support.apple.com/kb/ht5813 [1] i.e. Apple (claims it) can't access your passwords, despite syncing them across devices.

deleted 12y ago

[deleted]

smackfu 12y ago

Using SMS for this may work better than email. Email passwordless tends to get bogged down in little problems. Like the email is slow or goes to the spam folder. Or on mobile, clicking a link in an email may not take you into the web browser you actually want to use the app in. SMS at least should improve on these two problems.

thesumofall 12y ago
Passwordless would allow you to do that quite easily. Only risk are the shorter tokens (can be balanced by shorter validity, though). There is a short description of how to do it in the documentation
mikevm 12y ago
SMS is unreliable. It may arrive in an hour, the next day, or not at all.
- smackfu 12y ago
  In practice, it seems about as reliable as email, and faster to get to me.

mtck 12y ago

Is there any advantage of this over using Oauth to 'Sign-in with Google/FB' other than being platform agnostic? similar workflow except tokens are being exchanged between server-server vs sever-email.

marco1 12y ago
No, except that SSO via such a service is more secure than the email approach. However, being platform agnostic is quite an important reason.
anywherenotes 12y ago
A lot of times websites start requesting permission to know your name. With email only, they wouldn't have the option.

marco1 12y ago

The very website they link to [1] via its HN thread [2] states correctly that: "No, email is not a secure medium. It was never designed to be one. It’s susceptible to Man In The Middle (MITM) attacks and a slew of other issues. Users might also have their email accounts abused or hacked into (how many people do you know who have left their GMail logged in on a public computer?). And what about if their email provider gets hacked or their backups stolen?" Mozilla should know that email is not an adequate medium for one-time password delivery. They are replacing strong authentication (2 factors) with its second factor alone. [1] http://plaintextoffenders.com/faq/devs http://plaintextoffenders.com/faq/devs [2] https://news.ycombinator.com/item?id=7943365 https://news.ycombinator.com/item?id=7943365

okbutnormally 12y ago
> They are replacing strong authentication (2 factors) with its second factor alone. Are they? They don't mention anything about replacing 2 factor here. A typical login is compromised if you know the password or if the email is compromised. This is not increasing the attack surface.
- andrewstuart2 12y ago
  One problem is that SMTP itself [1] is just a plaintext email format. Sure, you can send it over a secure connection and most do, but that's left completely up to the provider to decide and therefore never guaranteed. [1] https://www.ietf.org/rfc/rfc0821.txt https://www.ietf.org/rfc/rfc0821.txt
  - Fuxy 12y ago
    This is by no means a very secure option but do you really care if your www.anime-planet.com or konachan.com account don't use 2 factor authentication. Some websites just don't need such a high level of security plus you could argue they are probably less careful with your password than say Google is with your email. Now it can still be hacked but you could argue this is probably an increase in security although it does create a central point of failure just like password managers. Nobody says Google or Amazon should start using this but websites with a lower requirement of security shouldn't inconvenience their users unnecessarily. If you're only need is to identify the user for something banal that couldn't do much damage if it gets hacked then this is a good solution.

pdkl95 12y ago

This looks suspiciously like OpenID with the identifiers changed from URLs to email addresses and updated to use modern pop development tools. I really liked OpenID, even though it had a few issues. The best part was that you could put a few HTML tags at the URL you used as your identity and delegate the authentication - but not the identity - to a 3rd party. Because you controlled the identity, you could drop the 3rd party and use someone else (or implement the OpenID protocol yourself locally) just by changing some tags. If "Passwordless" can provide this can provide the same level of autonomy, it could easily become my authenticator of choice. It looks like it's tied to an email account? Slightly annoying, but trivially worked around if necessary.

tomp 12y ago
I don't know how it's implemented, but I see no reason why adding/removing emails to/from an existing account (while logged in) wouldn't be trivial to implement. The only thing you need to be careful with is to send a notification to the email being removed, send notification to all emails when a new one is added, and enforce some kind of expiry period before a removed email becomes inactive/added email becomes active.
thesumofall 12y ago
It is not necessarily linked to an email account. It's up to the lookup middleware that has to be programmed by the implementer how to translate the login into an email address / phone numbers

mixedbit 12y ago

One of drawbacks of this mechanism compared to Persona is that a web server needs to be configured to send emails with tokens using site's own email credentials. This isn't easy to setup reliably for a small site. A malicious user can easily trick the server to send many tokens to different accounts and cause the sending email to be included on spam blacklists.

tomp 12y ago
How is that different from registering many user accounts with many different emails, or using the "Forgot Password" feature using many different emails?
- mixedbit 12y ago
  If you use Persona, the site doesn't need to send any emails (As I wrote this is a drawback in comparison to Persona, a traditional password based mechanism has the same problem).

trvz 12y ago

Is this the fourth or fifth try of Mozilla to replace passwords? Surely it will work _this_ time… Edit: …which makes it totally sensible to invest time building your site up relying on this stuff.

mixedbit 12y ago
I only hope that an intention of this project isn't to "smoothly" kill support for Persona. From a PR perspective this could look nicely: we kill the project that you depend on, but here is some quite inferior alternative that has zero maintenance cost for us.
- callahad 12y ago
  I don't believe that's at all the intention. However, I am quite interested in this approach, and will be watching Webmaker closely as they roll out a similar scheme. If it works, I'd likely be in favor of transitioning the Persona fallback from long-lived passwords to single-use email tokens. After discussion on the mailing list, of course. (FWIW, dochtman and I maintain Persona)
jaredsohn 12y ago
>Is this the fourth or fifth try of Mozilla to replace passwords? No. https://news.ycombinator.com/item?id=8459114 https://news.ycombinator.com/item?id=8459114

mankins 12y ago

I implemented something like this as an alternative to the OpenId logins when I was at Fast Company. I believe it's still in use there if you click the person icon to login at the top right, select other options, and then "send me a one time link". Try it out? We did this because we had people that didn't have Twitter or Facebook logins and needed to use some service that we had. I didn't want to build out a password database so came up with this work around. Surprisingly we didn't receive that much hate mail about it, and we have a fair amount using it per day, so I'd say that people like it.

Xeoncross 12y ago

The main problem I have with this approach is a theoretical one: What if I can't get a cell phone or permanent email address? You have to pay to have a phone and possibly have approval from the network/government to join. Email is a lot better since it's a totally open network. However, Even then I'm leaving myself open to MITM attacks, being locked out of my email by government orders, ISP complaints, company lawsuits. I will never be locked out of my passphrase. With that said, after almost creating swiftlogin to do this very thing, I would support this effort as long as this does not become the one true way.

deleted 12y ago
[deleted]

throwaway9724 12y ago

At my company we've been using this technique for years. Users have always hated it and after waiting a long time for people to come around, we are now transitioning back to traditional login mechanisms. The basic reasons users hated it was that a login mechanism needs to be reliable. In particular, we make business software, so if the user was ever unable to get into the system it was a big problem. While it may seem that you "always" have access to your email, or sms. Not all users (especially non-technical users) always have access to these things. Meaning, even if they have access 98% of the time, that other 2% of the time infuriates them. It was also a usability nightmare among non-technical users. Traditional login mechanisms dont necessarily mean a more usable experience, but its a pattern that everyone knows. I think login mechanisms on the web can be improved, but not like this. As someone who has a lot of experience with this, I strongly recommend against it.

tngme 12y ago
This is a fair point considering the use scenario that you describe. For other website this might look very different: Think of all those small websites for which you had to create logins but that you rarely use. They are a huge risk due to people's tendency to reuse passwords across important & unimportant sites. For those smaller sites people might not even recognize this system as a traditional login: They simply come back to the site, are asked for their email address if they want to get back to their information, and shortly thereafter they have a link in their inbox to their details/comments/favorites/...
tracker1 12y ago
This really affected me the one day in the past 3 years that I forgot my phone in the morning... There was one site I had enabled 2FA (two factor authentication) on that I hadn't logged in from work yet, and it was really a pain not being able to access it. Honestly, I've been pretty happy simply using LastPass (with a really long passphrase that I haven't shared with anyone) and generating more complex passwords for sites... Just the same, not sure what the best answer is... Especially considering shared computers, portable devices and other devices which may get stolen or hacked.
- 12y ago

abalone 12y ago

Previous HN discussion: https://news.ycombinator.com/item?id=8446232 https://news.ycombinator.com/item?id=8446232 A major drawback here is that it's incompatible with password managers which are a better, more generally-applicable solution. Relying on email means that if your email delivery is high latency or having an outage or an aggressive spam filter then your account access in impacted. Keep in mind not everyone gets their email right away -- many people (my mom) are on >10 minute pull intervals.

PythonicAlpha 12y ago
I agree, that eMail as transport media is far from optimal, but it is the only general available media currently. I still think that from the point of usability a passwordless solution is better for many applications, where security is not the top priority. Because so many applications in the web force you to have a password, security in general is at risk. Most people get tired of passwords and use either bad passwords or just one for all. And those passwords are endangering those applications that are really security sensitive. I would rather like to see, that only a few services (like banks, ...) want to have a password and the others just authenticate their users with less intrusive means.
- abalone 12y ago
  > Most people get tired of passwords and use either bad passwords or just one for all. That is what password managers fix. iCloud Keychain has gone a long way towards mainstreaming this. It's built in to Safari and securely stored, encrypted with your OS/device's master password -- which is an improvement on Firefox & Chrome's approach, where master passwords are optional. From a usability standpoint that email method is way worse, at a minimum due to the latency issues. Waiting a minute for an email to arrive can feel like an hour when you're trying to log in to do something urgent. Password managers work "magically". For a security standpoint the email method is also worse, because it is only usable with very long-lived sessions -- which is not the best security practice. The article even heavily qualifies this method as not appropriate for sites users "visit frequently". So by the author's own logic, this method is only appropriate for sites that NO users visit frequently. Which is no sites. Finally, the nail in the coffin for the email approach is that it's incompatible with the more general password manager solution. So those users who do need to visit a given site frequently can't use a password manager (at least without redirecting themselves to an alternative method, which is also poor usability).

harshreality 12y ago

The FIDO alliance has a working solution to the annoyance of the 2nd factor. It requires mobile device support or a hardware token (Yubikey Neo as of October supports the FIDO protocol), but it's much better than standard existing 2-factor because it doesn't require typing in a code from a dongle or app. Instead, the app or dongle authenticates directly once user presence (or in some cases, depending on the dongle or app, biometrics) are confirmed. That means, for low-security applications, users can reuse passwords, or not have passwords, using only this second one-time-password factor, as long as they don't lose their FIDO dongle or FIDO-enabled mobile device (recovery protocols are at the discretion of different services, but a recovery code that you keep in a secure location is one way way to do it, or emails or text messages for less secure applications). For high security applications, it avoids the annoying scrolling through a list of 2-factor accounts to get the right code, then typing it in manually. Email or text message, even if secure (text messages are not, and emails are probably not) require internet access. Mobile internet access isn't always available when logging into a service from some other device that has a different internet connection. Similarly, the mobile network (for text messages) is not always available, either. Even if it's done through email, email service might be down; the machine used to login could be compromised so you wouldn't want to input your (hopefully very secure) email password on the same machine you're using to access some other service. If you don't have internet access via a separate more trusted device, the rationale for having 2 factor is weakened. A good presentation on FIDO is here: http://www.yubico.com/2014/07/future-online-authentication/ http://www.yubico.com/2014/07/future-online-authentication/ There's nothing preventing a FIDO-enabled service from also using email or text message for users that don't have FIDO devices, and account recovery can be done via recovery code, text, email, backup FIDO device, phone call, or a combination. It's all up to the service.

peterwwillis 12y ago
Sorry, I don't watch hour-long presentations when all I want is a bullet list of features and requirements. So I have no idea how FIDO actually works. Here's what I will say: the best combination of security and usability would come in the form of an app that bridges an automatic communication (such as from an SMS, e-mail, or existing [https?] connection) to a TOTP token provider (either in software or hardware) and a prompt to the user to submit the token over a secured connection to the requesting provider. For internet-less use, you'd simply generate and copy the token the way Google Authenticator works now. From the looks of the NEO & U2F yubico page, it sounds like this is similar to what they're going for; is that correct?

tylerg 12y ago

Kudos to Mozilla for trying a new way to simplify passwords. Very similar to something we implemented at Shop It To Me in June and that appeared in Hacker News. Here's the link with the conversation: https://news.ycombinator.com/item?id=7818584 https://news.ycombinator.com/item?id=7818584 And here's the announcement. http://blog.shopittome.com/2014/05/29/bye-bye-passwords/ http://blog.shopittome.com/2014/05/29/bye-bye-passwords/ Overall it has worked very well for us and is no less secure in my opinion than all the reset password options. 2-factor authentication is still better though and should be used for the sites requiring the most security.

thesumofall 12y ago
It's not a Mozilla solution, though, says the developer :-) Hacks is simply publishing about it

anywherenotes 12y ago

There are a lot of websites that are not worth the hassle of registering for, but this can make registering on them easy and they may get more registrations. For important accounts I would still prefer a password only stored in your head and two phase authentication. But for various forums, this type of a setup is better than using third party password manager or same-username-password combination for general purpose.

drikerf 12y ago

Great idea, I can see that this would be awesome on services I use seldom and often forget my password anyway. But do the average user really care enough to bother with email? or for SMS, will they give away their phone number? Remembering users for a long time also opens up for other breaches. Anyway it is awesome that people are working alternatives!

adventured 12y ago

I've tried throw-away email based passwords twice in the last five years. Every time I try it I run into the same problem: guaranteed speed and guaranteed delivery of email (both in general and that it'll always arrive in the inbox). Average users get annoyed very quickly when they have to wait even minutes for an email to show up. I still run into this problem even when using quality services such as Mailgun. For this approach to work, it requires at least three things 1) Much greater security for email 2) Guaranteed speed of delivery for every email, such that the throw-away password arrives in seconds at a 99.x% rate 3) Guaranteed delivery, such that throw-away passwords arrive in the inbox at an extremely high rate of success (at least 99.9%) Email will never be able to deliver on these requirements. As such this system will never be effective for deployment on a service that average users use.

INIT_6 12y ago

I think a good middle ground would be to implement this idea into a password manager. You have one strong password to unlock your manager. Sites that support passwordless Would send it to the password manager. Otherwise use it as normal. As long as the password manager is supported on all platforms I think this would be the best solution. As for how it would communicate I always prefer pull rather than push.

peterwwillis 12y ago

Passwordless logins, as implemented today, are less secure than password logins. Flaws in the passwordless login system: 1. Authentication is done on unsecured connections. With all of the shouting over privacy and security, here we are abandoning secured, encrypted connections for SMSes and e-mail, two unencrypted, unauthenticated, somewhat unreliable, easily intercepted, plaintext messaging systems. 2. Replacing an out-of-bound token with one stored purely online. Any actor who controls the network (or your computing device) can subvert the login. 3. Depends on a pre-existing authentication, which itself uses passwords (or none at all), leaving you at the exact same state of security as you had before. Instead of two passwords that are the same, you have one password (the e-mail password) that is the same, or zero authentication with SMS. 4. No mandate for multiple-factor auth, nor out-of-bounds auth. 5. Zero security for the tokens (cookies) stored on the user's system, so data at rest is at risk, unless your browser encrypts cookies with a master password. Of course this is moot considering the total lack of encryption on the smtp/sms side and the lack of out-of-bounds auth. Reasons why password logins are more secure: 1. Uses secured, encrypted connections to transmit secrets. Prevents man in the middle attacks and interception of logins. 2. Provides an out of bounds auth token. The only way to subvert this is to intercept it as it goes into a computing device, meaning either the client or server would have to be compromised at the time of login. 3. Data at rest is encrypted and only the user's cached token (cookie) can be used to steal a pre-authenticated login. 4. Password can be unique to the service, so a compromise of one system does not compromise all. 5. Industry standard is already to require multiple-factor authentication to be combined with this method for increased security.

xnull 12y ago

Why not PAKE? "The SRP protocol has a number of desirable properties: it allows a user to authenticate themselves to a server, it is resistant to dictionary attacks mounted by an eavesdropper, and it does not require a trusted third party. It effectively conveys a zero-knowledge password proof from the user to the server. In revision 6 of the protocol only one password can be guessed per connection attempt. One of the interesting properties of the protocol is that even if one or two of the cryptographic primitives it uses are attacked, it is still secure. The SRP protocol has been revised several times, and is currently at revision 6a." You can salt/password manager/email retrieve on the client side however you want to strengthen you passwords or escrow keys without needing to share state with third party services at all. And they never get a copy of your creds. The server side can easily rate limit guesses per account, report access times, and/or require CAPTCHA challenges. https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol https://en.wikipedia.org/wiki/Secure_Remote_Password_protoco...

e0m 12y ago

I think we sometimes forget the number of users who would try and get to your service, then bail because they need to boot-up Outlook, or work in a building with no cell reception.

passfree 12y ago

A similar idea was discussed here (http://www.gnucitizen.org/blog/simple-universal-authentication-system/ http://www.gnucitizen.org/blog/simple-universal-authenticati...) in 2008.

SoftwareMaven 12y ago

With the exception of automatically grabbing the token, it's pretty much the same as BYU's SAW[0]. I worked for a startup that was trying to commercialize this technology, but it's nearly impossible to commercialize an authentication tech. It's unfortunate, too, because I think it would make a much better option than most password managers. 0. http://isrl.byu.edu/projects/simple-authentication-for-the-web/ http://isrl.byu.edu/projects/simple-authentication-for-the-w...

codezero 12y ago

This is interesting. A lot of social networks use this sort of authentication for their email notifications, and weekly/daily digests, but don't treat it as a first class login. Facebook, LinkedIn, Twitter, Quora, etc... use a short expiration on these, but if you ever forward one of your new notifs to a friend, they will end up logged into your account, which is surprising. It usually only lasts for the session, and some are pretty good about double checking if you are coming from a new location or have cookies for another account set :) For longer lasting sessions, email security seems like a big concern, especially since most people keep all their email forever (gmail) and it's easy to search through.

thesumofall 12y ago
Almost :-) The tokens are one-time only. Afterwards the session is keeping track of the user. Another login requires a different token. Regarding the emails of Facebook, etc.: Great example, actually! I guess the problem really is that they don't make it obvious to users that they actually hold an authentication token in their hands.
- codezero 12y ago
  Yeah I assumed they were one-time only. In examples I've seen, each link had a different token, so if you forwarded something, one of the links may work if you hadn't clicked that particular one. When ever I explain this to people, and forward them one of my notifs from Facebook, they get pretty paranoid and shocked, then eventually accept it because of the convenience :)

Oblouk 12y ago

I do not see the benefit of this from a usability standpoint. From a security standpoint it seems like an absolute nightmare. If you lose the password to your email you could lose access to all your accounts. Most people do not own their own email server and so this could have catastrophic security consequences. Of course the sites could check for IP location consistency but in order to spot security threats early you would need to track logins to multiple sites. The only way to do this would be to either give another third party company the ability to track logins and implement fail safes. At that point it begins to operate a lot like the companies which allow third party authentication through Facebook/Twitter/Email.

penprog 12y ago
Considering that for most websites one can easily reset the password to your account if they have access to your email, this adds no extra security risk (for those situations which are most common websites eg. Amazon, facebook, twitter etc). So this is NOT catastrophic for security because the current situation is already like this. For websites where security is a larger issue, this obviously wouldn't be the solution.

thesumofall 12y ago

Someone just made me aware of www.cotap.com - It's probably using a different middleware, but I think a perfect example of where passwordless login makes great sense!

konceptz 12y ago

One thing I like about having different passwords and logins for each site is that I don't have to worry about cascading failures. This seems like it isn't getting rid of user/pass authentication, it's just pushing it onto someone else, in this case your cell or email provider. Other users have correctly stated that this doesn't increase the attack surface, however it does increase the value of a single vector. Please correct me if I've missed a key point in the OP, I didn't spend lots of time reading the finer points of the implementation.

twodayslate 12y ago
Your email is already a single vector. Most sites have a "forget my password" link and all you need is the email account to reset the password and access the account.

throw7 12y ago

This requires javascript on the client no? That's a no go for me. The little demo site fails for me.