This is dumb idea and requires that you open your email to login to a site that you want to use. Faster is just typing your username and password and pressing the login button. Anyway browsers make this even faster by storing the username and password.
Sorry, but I do not see anything bad at saying "this is dumb idea" different would have been if I had said "This is fucking stupid idea". Anyway my negative points kinda were earned. :(
I do not necessarily disagree with you that I'd prefer a username/password, but please be nicer than "this is a dumb idea" - someone spent quite a bit of time making this work.
Doesn't this need some kind of browser plugin to set your cookies with? Most websites don't have secret token URLs that will log you in, right? What about sites that issue cookies per-IP? Maybe I'm misunderstanding the mechanism here, would love clarification.
Huh? No, you don't need a plugin to set cookies. They will just email you a link to a page that presumably has a timeout and will set your session cookie so that you get logged in.
You put an e-mail in the box, click Submit, it sends you an e-mail with a link to click. You click the link, it brings you to a page that sets a cookie for you (key '_logged_in', value 'SOMEKEYSPECIFICTOYOUREMAILADDRESS'). Browse the site with the temporary key linked to your e-mail address. When your browser closes the cookie is gone.
If you want to log in again, repeat the process.
Now, here's why this is a bad idea: e-mails are not secure. They are sent willy-nilly around the internet in plain text through multiple mail relays. All one would need is to sniff traffic on a network segment that the mail travels over and you'd have a hell of an easy time collecting login info. This is why the passwords sent over e-mail are supposed to be temporary, and why most good password reset forms ask for additional confirmation details before they let you reset the password.
You might think the above process would be secure if the link they send you is de-activated the first time you click it, but anyone could just keep sending more e-mail login requests and collecting the e-mails. The whole thing is pretty not-secure.
Great idea. 99% of website accounts I create are only accessed once or twice to purchase something or to leave a comment or get access to something. I use KeePassX to generate passwords for most of those, but most people use passwords that are either repeated, insecure or forgotten.
Although this concept certainly has its flaws, I could see it being useful for something where it was a site that most people would rarely log in. But for a store, I'd prefer having my credit card in the hands of something more secure.
Every web store has a "reset password via email" feature, so this is no less secure. In fact it's more secure, because this way you would receive email notification every time somebody tried to log in as you.
On top of that, the SSL server supports compression, session tickets and insecure ciphers, so that's three possible attacks to try.
What's REALLY weird: my browser is showing a different cert than OpenSSL is. My browser shows it's signed by PositiveSSL, but when I connect with 'openssl s_client' I get this:
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = ip-10-119-98-53, emailAddress = root@ip-10-119-98-53
verify error:num=18:self signed certificate
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = ip-10-119-98-53, emailAddress = root@ip-10-119-98-53
verify error:num=10:certificate has expired
notAfter=Feb 24 01:08:21 2012 GMT
verify return:1
depth=0 C = --, ST = SomeState, L = SomeCity, O = SomeOrganization, OU = SomeOrganizationalUnit, CN = ip-10-119-98-53, emailAddress = root@ip-10-119-98-53
notAfter=Feb 24 01:08:21 2012 GMT
Not only is it self-signed, it's expired. I actually don't know what the fuck is going on here.
This is really great. There's quite a few places where I'd love to sign-in like this.
The one area where I think it would fall down is logging into web apps that have multiple points-of-entry. Such as chartbeat(phone app and website). I don't see how you would be sent a link to log into an iPhone app. Or could you be sent and email with multiple links: one that goes to the site, another that flings you into an app?
The best implementation would be if web apps offered this in the preferences area with a check-box saying: "Enable NoPassword" (so you don't offend any traditional password lovers or confuse people that just might not understand it).
This is a neat idea. There are plenty of sites that I only use once or twice a year, or ever. I'm not sure how widely this will be adopted, though, since most sites tend to cater to the people that access them frequently.
Also, as a user, you can accomplish this same thing by just using a common username across all your 1-off sites, along with a gibberish password that you reset every time you want to log in.
It's great to have a library for this ... I first encountered a service using this type of login with www.wasitup.com (sadly now down) in 2010 and never had an issue with logging in, though it was indeed necessary to open an e-mail when using a new computer.
My bank starting texting me a one-time password which at first I thought was weird - but now I like it better than actually having to create and save a password. Seems like a nice natural extension of this for more secure things.
As some will point out, SMS is generally insecure because of the possibility of snooping vulnerabilities.
An even more secure way to implement one-time passwords is through an HTOP[1] smartphone app. The crypto is seeded once and then never has to communicate over the network to generate an OTP. Only the person with physical access to your phone can generate a password. I know when I was with USAA, they allowed you to generate one-time passwords using this method.
I don't understand why you downvoted me -- my point is perfectly valid.
"The concern is that in the 2 seconds it takes me to type the password in someone will intercept it and beat me to it?"
The concern is that someone will snoop the password before it even gets to your phone. SMS snooping/MiTM has been demonstrated before [1]. Time-Based One-time Password algorithms are safer because they are not vulnerable to the aforementioned probems -- they never touch the network.
It's a matter of how comfortable you are with someone having access to your bank account.
If you believe it's unlikely anyone will ever either A. work for a telecom company, or B. build an OpenBTS base station, while also C. try to get into your bank account, then you shouldn't worry.
If you believe it's unlikely anyone will ever A. work for an ISP or other mail relay, or B. sniff traffic on a network segment that an unencrypted mail relay runs on, while also C. try to get into your bank account, then you shouldn't worry.
Now then. If you think both of those are likely to happen, you can simply use a one-time pin program on a phone (or a keyfob -- much more secure than on a phone) and neither of the two attacks will be possible, thus your bank account will be more secure.
It's only a matter of how much you care about your bank account. If you care enough you won't use e-mail or SMS. If you don't care, then whatever happens, happens.
So I have to log into my email to avoid logging into the site? Isn't that the exact same thing, yet now I have to include a few extra steps in between?
If it is the kind of site for which you are willing to keep a cookie around, then you'll only have to get a new link from your email whenever your cookie expires or if you explicitly log out.
Anecdotally, everyone always has their email open anyway (I do, everyone I work with does, my family aways does), so the extra step of checking your email is trivial.
Unless you use a different account for junk websites than you do your day to day email. I have my work email open all day, but not my personal email, which is also different to my spam email account I use for trials or junk websites. If I need to have 3-4 different email accounts open just to manage my sessions, I could see this being a massive pain. Also if I sign up using my work email to a work related service (so I can use it at work), I might not have access to it at home.
"The thing is when I used internet cafes, the first thing I would always open would be email."
Seriously? Intenet cafes are the least secure computers to give your email and password to. Sure for junk and spam-email accounts, that you dont care about anyway. But logging in to your personal email account on an internet caffe!? Thats madness.
Internet cafes aren't the only place. Our work doesn't allow access to external email - as one part of an attempt to avoid data leakage - but has no problem with a small amount of browsing sites like HN.
I think it's an admirable goal, but they have a huge task ahead to convince both developers and other browsers to pick the standard up.
Realistically, I expect most people/services will converge on Single Sign On via one of Twitter, Google, Facebook, and maybe a couple others. Hopefully all offering 2-factor authentication. So you'll only need a handful of passwords anyway.
I agree with you. Those big names, for better or worse, became the identity store on the internet. Most websites tend to support at least one of them if not all of them.
Are there any plans or thoughts in regards to adding some way to implement it on a website without using JavaScript? You control the browser, so it shouldn't be difficult to do.
For example, you could define a special URLs for login and logout actions. (E.g. persona:action=login&onsuccess=encoded_url1&onfailure=encodedurl2 ). I don't know about others, but it would make me much more willing to give a try.
Google Apps accounts should work. That error message shows up when there's a delay with XHR requests behind the scenes -- things look good on our end. Maybe a blip in your connection? Is it working now?
When I'm on an untrusted computer, e.g. in an internet cafe, I typically try to avoid logging into webmail. E.g. I'll first put files I want to print into Dropbox and then log into that instead, (the consequences of an attacker getting access to my Dropbox are less grave than an attacker accessing my email account). This extra precaution is not possible with this NoPassword scheme.
That's my exact thought. An idea solution is to check your mail on your phone, open a link that is essentially a second layer of authentication where you can login by clicking on the link in your mobile device, then refresh the page on the desktop and you'll be logged in.
I still see this cluttering up my inbox, they would need to be deleted right away...for me it's just easier to type in a password.
Once someone has access to your e-mail, they can reset your password and log into anything that you used that e-mail to sign up for. With Dropbox, all they'd have access to is whatever files you happen to have in your Dropbox at the time.
1 reason would be that you can reset your dropbox password with your email, but you can't get your email password from dropbox (unless you store something silly like passwords.txt in dropbox)
Makes me wonder, if emails and SMS messages start to carry more and more plaintext passwords (and links) providing direct access to everything, how will their security hold up in the long run? I don't think they are inherently very secure channels.
I think people put way too much faith in inbound TLS. My mail server has some bozo self signed cert and nobody has ever failed to send me an email. Meaning: either nobody is using TLS to deliver mail or they use TLS and ignore all cert failures. Either way, about 99% less secure than you think it is.
Which A5? Is it vulnerable to one of these attacks? https://en.wikipedia.org/wiki/A5/1#Security (This is besides the more simple exploit, which is either cloning the handset or making a fake GSM base station which your phone will automatically hop to, pass traffic transparently, and sniff control channels)
There is no such thing as secure transport-level e-mail because eventually it may [read: will] hop through a relay which does not use transport-level security.
I don't think there is any working attack vector (i.e. not taking 100 years to do it) against pure TLS as of today. (using it along with compression is another thing)
The thing is, those channels are already used by most services for password reset.
So, a user could implement this workflow themselves already.
Basically, create a password for the site that you don't even know yourself when you sign up. Make sure you select the appropriate "keep me logged in" option.
Now, if you ever get logged out, go to a different computer or otherwise clear your cookie, you just "reset" your password... which generally involves sending you an email that lets you login to the site based on the link or code provided.
This approach is simply making that the norm and doing away with the (probably insecure anyway) password for the site.
If email and SMS aren't secure for password recovery, what alternatives do we have that scale and provide for a quick and user-friendly experience?
With this approach, you don't have to store or remember your password. Just "reset and forget" whenever you want to start a new session. The only risk is in the few minutes your temporary password is in transit and sits in your inbox before you replace it with something ridiculously difficult to crack (or remember). It would be awesome if password reset pages offered the option of encrypting with a PGP public key to eliminate even that risk.
With this approach, you're at risk every time you log in. Why on earth you want that I have no idea.
If you create a ridiculously difficult to crack password once, you don't have to keep doing it. If it takes 50,000 years to crack, creating a new one 3 days later will not make you more secure.
If you're going to the level of PGP to send yourself a new password every time you log in, just use client certs!!!
Let me put this in more plain terms, because I want you to understand exactly why what you're doing is wrong.
Now that I know you always reset your password, i'm going to find a way to intercept your e-mail. (There are many.) Then i'm going to automatically reset your password as soon as the mail is delivered, faster than you ever possibly could by hand.
If you had just remembered or saved your password in the browser this would have been impossible. Now your account is compromised because you thought it was easier to go through 4 steps every time you log in versus just logging in with a saved password.
Google can only secure them (assuming you trust them, of course) from the moment it hits their servers. Until then, it's a postcard hopping from machine to machine.
I like it. Especially because theoretically it can be
mixed with other, conventional authentication schemes, so it can be made completely optional and used at will, just like sites currently mix password + several OAuth providers.
It's pretty much the ideal scheme for all those sites you don't visit regularly (and many of us, despite knowing better, use the same password for...).
Definitely a neat idea. Could also just email them a reusable link except that would leave the credentials in your browser's history unless there is a way to avoid that.
This is an interestimg idea and surely has it's place, but how you implement it is critical. For example, you would want SSL for the entire site to ensure the cookie is always protected. You would also need to make sure that the token and session management is solid.
Of course to really make it secure, you would want all smtp connections between you and the user to use SSL, which you cannot guarantee. One test I always use for new authentication schemes is would the NSA be able to compromise your account if they wanted? In this case I would definitely say yes.
Still, this would be excellent for sites that only have you login to set preferences, etc.
Y u no use LastPass? I've been using it for more than a year and never had a problem. Today, I only know 3 passwords, one for each of these: LastPass, full disk encryption in my PC, and the login in my PC.
Bad solution, email is slow and unsecure. I also have always hated identities linked to email in anyway. It's wrong way and that's it. Also allowing password recovery via email is dangerous, because email isn't secure either. Email is secure if you use GPG, and in that case it would be better to login by signing nonce with your private key and returning signature to site, which can verify it against your public key.
150 comments
[ 2.9 ms ] story [ 218 ms ] threadFor previous discussion: http://news.ycombinator.com/item?id=4308190
That's what they are proposing. Every time you log in they send you a one-time secret token URL by email.
If you want to log in again, repeat the process.
Now, here's why this is a bad idea: e-mails are not secure. They are sent willy-nilly around the internet in plain text through multiple mail relays. All one would need is to sniff traffic on a network segment that the mail travels over and you'd have a hell of an easy time collecting login info. This is why the passwords sent over e-mail are supposed to be temporary, and why most good password reset forms ask for additional confirmation details before they let you reset the password.
You might think the above process would be secure if the link they send you is de-activated the first time you click it, but anyone could just keep sending more e-mail login requests and collecting the e-mails. The whole thing is pretty not-secure.
What's REALLY weird: my browser is showing a different cert than OpenSSL is. My browser shows it's signed by PositiveSSL, but when I connect with 'openssl s_client' I get this:
Not only is it self-signed, it's expired. I actually don't know what the fuck is going on here.The one area where I think it would fall down is logging into web apps that have multiple points-of-entry. Such as chartbeat(phone app and website). I don't see how you would be sent a link to log into an iPhone app. Or could you be sent and email with multiple links: one that goes to the site, another that flings you into an app?
The best implementation would be if web apps offered this in the preferences area with a check-box saying: "Enable NoPassword" (so you don't offend any traditional password lovers or confuse people that just might not understand it).
Also, as a user, you can accomplish this same thing by just using a common username across all your 1-off sites, along with a gibberish password that you reset every time you want to log in.
Thanks!
An even more secure way to implement one-time passwords is through an HTOP[1] smartphone app. The crypto is seeded once and then never has to communicate over the network to generate an OTP. Only the person with physical access to your phone can generate a password. I know when I was with USAA, they allowed you to generate one-time passwords using this method.
[1] http://en.wikipedia.org/wiki/Time-based_One-time_Password_Al...
"The concern is that in the 2 seconds it takes me to type the password in someone will intercept it and beat me to it?"
The concern is that someone will snoop the password before it even gets to your phone. SMS snooping/MiTM has been demonstrated before [1]. Time-Based One-time Password algorithms are safer because they are not vulnerable to the aforementioned probems -- they never touch the network.
"This is way safer than email."
I never said it wasn't?
[1] http://en.wikipedia.org/wiki/IMSI-catcher
If you believe it's unlikely anyone will ever either A. work for a telecom company, or B. build an OpenBTS base station, while also C. try to get into your bank account, then you shouldn't worry.
If you believe it's unlikely anyone will ever A. work for an ISP or other mail relay, or B. sniff traffic on a network segment that an unencrypted mail relay runs on, while also C. try to get into your bank account, then you shouldn't worry.
Now then. If you think both of those are likely to happen, you can simply use a one-time pin program on a phone (or a keyfob -- much more secure than on a phone) and neither of the two attacks will be possible, thus your bank account will be more secure.
It's only a matter of how much you care about your bank account. If you care enough you won't use e-mail or SMS. If you don't care, then whatever happens, happens.
Otherwise, you are correct.
1) You don't have/won't access your email account on that computer (ex: Internet Cafe)
2) Spam filters that may delay the mail and so will delay the ability to log in. (ex: Grey Listing)
3) Changing your email account (ex: Work Email to personal email)
2 and 3 and really valid though.
Seriously? Intenet cafes are the least secure computers to give your email and password to. Sure for junk and spam-email accounts, that you dont care about anyway. But logging in to your personal email account on an internet caffe!? Thats madness.
[1] https://login.persona.org/
Realistically, I expect most people/services will converge on Single Sign On via one of Twitter, Google, Facebook, and maybe a couple others. Hopefully all offering 2-factor authentication. So you'll only need a handful of passwords anyway.
Also, if you've been waiting for Persona to hit "beta" before trying it out, well, check back Thursday morning. :)
For example, you could define a special URLs for login and logout actions. (E.g. persona:action=login&onsuccess=encoded_url1&onfailure=encodedurl2 ). I don't know about others, but it would make me much more willing to give a try.
"We are sorry, this is taking a longer than it should. If this doesn't resolve itself within a few seconds, please close the window and try again."
I still see this cluttering up my inbox, they would need to be deleted right away...for me it's just easier to type in a password.
Can you be specific as to why? If you use Dropbox for personal information, I'd assume it would be similar.
This doesn't avoid any number of different scenarios.
Too bad we don't all use PGP for email...
My SMS are encrypted with A5, and my email (gmail's inbound smtpd) is (usually) encrypted with TLS.
Of course, I always check with TLS as well.
It's not quite as bad as you seem to make it out.
There is no such thing as secure transport-level e-mail because eventually it may [read: will] hop through a relay which does not use transport-level security.
It's not secure, period.
Edit: looks like I missed the point here
Sent from mobile
So, a user could implement this workflow themselves already.
Basically, create a password for the site that you don't even know yourself when you sign up. Make sure you select the appropriate "keep me logged in" option.
Now, if you ever get logged out, go to a different computer or otherwise clear your cookie, you just "reset" your password... which generally involves sending you an email that lets you login to the site based on the link or code provided.
This approach is simply making that the norm and doing away with the (probably insecure anyway) password for the site.
If email and SMS aren't secure for password recovery, what alternatives do we have that scale and provide for a quick and user-friendly experience?
If you create a ridiculously difficult to crack password once, you don't have to keep doing it. If it takes 50,000 years to crack, creating a new one 3 days later will not make you more secure.
If you're going to the level of PGP to send yourself a new password every time you log in, just use client certs!!!
Let me put this in more plain terms, because I want you to understand exactly why what you're doing is wrong.
Now that I know you always reset your password, i'm going to find a way to intercept your e-mail. (There are many.) Then i'm going to automatically reset your password as soon as the mail is delivered, faster than you ever possibly could by hand.
If you had just remembered or saved your password in the browser this would have been impossible. Now your account is compromised because you thought it was easier to go through 4 steps every time you log in versus just logging in with a saved password.
It's pretty much the ideal scheme for all those sites you don't visit regularly (and many of us, despite knowing better, use the same password for...).
Of course to really make it secure, you would want all smtp connections between you and the user to use SSL, which you cannot guarantee. One test I always use for new authentication schemes is would the NSA be able to compromise your account if they wanted? In this case I would definitely say yes.
Still, this would be excellent for sites that only have you login to set preferences, etc.