NoPassword | Hacker News Reader

NoPassword

nopassword.alexsmolen.com

240 pointsBerislavLopac145 comments

This turns your email inbox into a giant password manager, except without the extensive storage encryption used by real password managers. Thought experiment: What are the possible unintended consequences of that?

Just a few off the top of my head:

1. Easier for email hackers to detect sites where you have logins. (Controlling someone's email usually means controlling most/all logins, but it takes some digging to get a good list of vaulable logins. With this solution, most of the list is on the first page or two of the inbox.)

2. Harder to detect being hacked. (Previously, a hacker with email access would have to reset your passwords, and you will notice that at least some passwords have changed. Now the hacker just has to delete any incoming authentication emails after reading them.)

3. Losing a job becomes potentially more catastrophic. (Hope you didn't associate too many passwords with your work email, because IT wiped your account while security was escorting you out the door. And before you say only dumb people use work email for personal accounts, consider that part of the idea of this nopassword system is to help "dumb people" who fail to (for example) use password managers.)

4. Your email provider now has a nice easily mined record of what sites you log into most often. But, hey, I'm sure we can all trust Google not to use that information in a terribly creepy manner, right?

It would be interesting if email started adapting to this new use. For example, if we standardized around these login emails being sent from login@url.com, then you could set up a rule to automatically delete any email from login@url.com after 5 minutes. Over time, if this caught on, you could imagine this being standard practice by email clients vs. a custom rule.

This of course only solves problem (1) that you mentioned and possibly(?) (2) partially.

It occurs to me that this is kind of an interesting evolution of systems like 1Password, where the user experience is very similar: you have one password that gives you access to other passwords. Similarly here, your "one password" is your email password, and that gives you access to what is conceptually a new password on every login (vs a pre-generated one).

I wonder if we couldn't solve 3 and 1 together by creating a "login email provider". For example, pretend dropbox wanted to offer this service. Dropbox gives you an @dropbox.com email specifically for logging into places. When a login email was sent to you, you would go to dropbox and navigate to the logins tab, which would have a very non-emaily interface showing you the last login links that were sent to you (again, auto deleted after 5 minutes -- and since this is not meant to be used as normal email there is no expectation for them to last longer). If websites only supported "known" services like @dropbox.com for this kind of login, then the (3) could be solved. Maybe to make things even clearer, the .login TLD could be used or something.

You could accomplish a lot of this with a Chrome extension that operates on your gmail window. Heck, it could even listen for login emails and open the tab automatically when they arrive.

It seems like you think this would replace bank login's, which it won't, but rather this is perfect for about 90% of the sites out there that require a username/password.

1 & 2. If your email is hacked, the least of your concerns is what else is being accessed. No matter what, if someone controls your email then you are screwed. We've seen enough examples of that being true.

3. Well, if you don't remember your password and you no longer have access to the email you're in trouble as well. Password managers are great, but there is still some use cases where they don't work very well and I've had keepass go corrupt on me once before.

4. They already know all the sites you visit (if you're really worried about it). You still get password resets, user account confirmations, and weekly notifications from most sites.

If your email is hacked, you don't necessarily even know your email is hacked. With traditional username/password authentication, an attacker has to reset passwords to leverage email, and you have a very god shot at noticing a password somewhere changed. Under this scheme it is much harder to notice "you are screwed," as you put it. The attacker gets to decide WHEN you find out about the compromise.

And yes it's possible to figure out which sites I visit from my Gmail, and yes it's possible to lose your job AND forget your password all at once, but these issues are made exponentially worse by the "email a login token every time" scheme outlined in the article.

Couldn't the links expire to prevent most of these issues?

The links are one-time only, and they expire.

I think this just helps make it even more painfully obvious that email is the single point of failure for the vast majority of web site authentication security. This takes out a step, but it doesn't change what is already possible for an attacker to do.

Proposals for browser plugins and special protocols that use email for authentication have been around for a while too. It's just a matter of mainstreaming them. Which I hope never happens until we make sure email is as secure as a password manager.

I personally would like to disable the ability to reset my password via email on every one of my accounts (and disable resetting by "security questions" too.). I have all those passwords in my password manager, backed up on all my computers, an external disk, and the cloud. I won't need to reset my password. (Except when the service provider forces me too, like Dropbox recently did.)

>This turns your email inbox into a giant password manager

I already use my primary email for this purpose. Most passwords I memorize, but some, for services with requirements so arcane that memorization isn't possible, I just email to myself with a unique key I remember. To get the password, I just search my email for the key.

Yes, this makes me vulnerable if my email is ever compromised. But my primary email is already a single point of failure and pretending otherwise doesn't do me any favors.

I could use a password manager, which would have the advantage of encryption. But it's also limited to those places I have access to it. I can store the database in my dropbox, but that limits the platforms I can access it from (at least, without some serious headaches) and makes the whole process that much more painful.

It might be worth pointing out that most password managers also use email for authentication.

I think a major problem would be one of the most-common use-cases: you're away from your PC, and want to access their site.

To do this, of course, you'd have to get an email sent to that machine. Then, you must login to your email on that same machine to get the PW, and thus the problem: now you have a much greater chance of leaving your email logged in on the 3rd-party machine. Whether it's a friend's laptop or a public terminal (library, airport, etc.) this is not a good thing whatsoever; all you needed to do was to login to a site to post a comment on some silly discussion board, and now you've left the keys to your kingdom in the open.

Further, if there are actual security issues with that box, say it's actively being MitM'd, keylogged, etc. well instead of simply gaining access to your silly forum account, now they will have access to your email.

I think I would flat-out refuse to use any service for these flaws.

What if you could get an SMS, or the email on your phone, and type 5 letters into a box on the website?

Normally this would be more work, but if you're away from your email it might be a good alternative..

It would be great to be able to authorize a login for another machine. I could request a login on any machine and have an email/sms sent to my smartphone and click the link there (alternatively, scan a QR code), and get authorized on the machine initiating the login.

Email/SMS would be an obvious security hole for people who just click "OK" without reading, though. I guess a QR code would be secure anyway.

5. Your "password" is being sent via an insecure protocol.

6. Your "password" being stored in the clear via cookies on your machine.

The sites which would consider using this already have email password resets and persistent session cookies, which have the same problems.

If they made the email link stop working after initial use, that would solve a bunch of these problems.

(not sure if that's how it works or not)

All of those points apply directly to every log-in system that currently allows you to reset your password via e-mail.

5. Your smartphone gets stolen.

It wont work because the password cannot be used from another machine, as i understand. But If a new request is made, it will be logged, but that may not be good enough. Ya if you lose email address and simultaneously lose access to the system from which you originally logged in, you may not ever be able to login.

I hope that Mozilla Persona[1] (or similar) will solve this problem soon.

[1] https://login.persona.org/

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.

We do, too. Please try Persona out and let us know what does and doesn't work for you. We're trying to solve this thing once, for the whole web.

Also, if you've been waiting for Persona to hit "beta" before trying it out, well, check back Thursday morning. :)

Does this use a Mozilla Services Account? If so, your password reset function hasn't been working for a year...

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.

Doesn't seem to work with Google Apps accounts.

"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."

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?

Persona looks really good. Hope you guys build it out for the long haul.

I'll vouch for persona, it's trivial to implement and it's what I use on all my sites nowadays.

We did this on Toptranslation.com as an alternative to the normal password-based login. The thinking is, since password resets go to your e-mail, anyone who has control over your mail or mail server can get into your account anyway. It's a tradeoff between user (mostly enterprise customers') convenience and security. Since all orders made through the system require another confirmation, we decided it was worth not having to handle the "I forgot my password" support tickets. Haven't had any problems with it, I think it makes sense for low- to medium-security authentications.

There's a difference between a one-time, quickly-expiring password (requiring reset on use) being sent on email, as opposed to having the password reside there in perpetuity.

In one case the attacker needs full control during the password reset and in the other they can simply scour email for all passwords and get out - perhaps even without controlling the account - ie, transparent proxy + poisoned DNS would do the 2nd easily.

password reside there in perpetuity

It seems like you could easily handle this by making the link invalid after a certain time period, requiring you to request a new one. Which, is actually what a lot of password reset emails do currently.

The emails contain single-use links. Each time you login you need a new email. http://news.ycombinator.com/item?id=4572031

Changing account details or payment data or placing new orders requires separate confirmation via mail or phone anyway, so you'd have to have access to the email account for a chunk of time. If you can do that and prevent your mark from noticing the confirmation mails, you could have done the same with password reset emails.

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.

They're not secure. SMS and e-mail are sent unauthenticated and unencrypted and can be intercepted in many different ways.

For this reason, the link/code being sent should have an expiration attached to it, as well as being single-use.

This doesn't avoid any number of different scenarios.

Too bad we don't all use PGP for email...

If users could be trusted to maintain a key pair (PGP), then we wouldn't need to use email to do authentication.

> SMS and e-mail are sent unauthenticated and unencrypted and can be intercepted in many different ways

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.

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.

Yeah; internal SMTP to SMTP traffic gives no guarantees at all. The only way is to use S-MIME or PGP.

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.

It's not secure, period.

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)

Edit: looks like I missed the point here

Sent from mobile

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?

This is actually the workflow I use every single time I log in to HN. I haven't the faintest idea what my password is.

So..... Why don't you just save the password in your browser? Do you use a new computer every time you log into HN?

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.

Well, Google asked the NSA to help them with security. So if Google can't secure their mail, then we are all hooped anyway.

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 think it is interesting that a good portion of HN users are quick to point out the security issues in a scheme like this, considering the fact that this is basically the current security model with the intermediate steps removed. The only thing that makes it different from logging in to my bank is that if I try a bank password reset I might get asked what my mother's maiden name is.

I find it amusing that a page discussing passwords/security would throw a couple of SSL certificate warnings when loading it.

It's all green for me on chrome. What's causing the issue for you?

Not sure but perhaps it could be this: http://jimmyzimmerman.com/blog/2011/03/positivessl-untrusted... ?

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.

server name indication?

The self-signed cert is from alexsmolen.com, not nopassword.alexsmolen.com.

Ah, so it's using the servername TLS extension. I forgot that some people use that now :)

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?

The thing is I'd log into my email anyway to check for new messages.

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.

Otherwise, you are correct.

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.

If you use gmail, you can be logged in to multiple accounts at once.

Another glaring issue: they make the assumption that email === webmail.

While this may be mostly true, the fact is that many still use POP email, and so what, you're to setup a POP account on whatever machine just so that you can access a website? Just let me remember my simple PW, thanks.

If you're using a POP service that doesn't provide a webmail interface in 2012, something is wrong.

I run my own mail server from colocation. I have so far refused to provide webmail because I can't find an implementation that isn't a constant stream of security holes, in exactly the way that Courier / Exim aren't.

Any recommendations? I won't use PHP or MySQL on grounds of taste and decency.

> I won't use PHP or MySQL on grounds of taste and decency.

Good for you.

http://roundcube.net/about

http://www.zimbra.com/

http://www.squirrelmail.org/

Are you being cheeky? At least 2 of those are PHP-based...

Great work implementing what was discussed here: http://notes.xoxco.com/post/27999787765/is-it-time-for-passw...

For previous discussion: http://news.ycombinator.com/item?id=4308190

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.

I use a one time password system for magicscroll.net

There's a lot of peace of mind in knowing that my users' passwords won't ever end up on pastebin but overall I regret the decision.

I get a couple of emails a week from users who don't understand how it works. If I had to do over I'd choose openID.

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.

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.

[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? This is way safer than email.

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.

"This is way safer than email."

I never said it wasn't?

[1] http://en.wikipedia.org/wiki/IMSI-catcher

I didn't down vote you.

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.

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).

For none critical information and just a mean to identify a user account, this is a good idea.

In such system, The weakest link is the mail system, but this is not worst than what is done today. Replace mail by an sms code or whatever equivalent.

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.

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.

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.

The consequences of an attacker getting access to my Dropbox are less grave than an attacker accessing my email account.

Can you be specific as to why? If you use Dropbox for personal information, I'd assume it would be similar.

Email is basically master key for all accounts.

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)

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.

Terrible idea. A reusable link is as bad as emailing a plaintext password and not requiring a reset afterward.

Wouldn't it just make life easier for all of us to use auth via apps? I know that right now different providers use different layers of shit for their own purpose but there's gotta be a common ground for all of them that we could leverage for the sake of getting passwords out of the game for the most part of it.

Interesting. you're basically sort of taking the password part out of two-factor authentication.

(I know its not exactly that)

I keep asking users about this login process and passphrase instead of password. Most users seem to feel suspicious of the email login because most users have already been trained to not entirely trust their email. I don't think that this could become an accepted authentication method simply because of that

Regardless of whether this will be accepted, users need to be retrained. Any site that offers a password reset via email already effectively lets you login via email. Users should be aware of this so they can be more careful with their email (picking a decent password, ensuring they logout on public computers, etc).

IMHO everyone should be using two-factor authentication for their email.

Hasn't craigslist been doing this for awhile now? For those worried about the hassle/security of checking email to sign in to a website, there could just be two methods of login. One is the proposed NoPassword, other is the traditional username/password, and leave it up to the user to choose.

The user experience is so different, I think using it would push users away from the different experience.

The idea is nice, but I see a couple of problem with that kind of implementation:

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)

The thing is when I used internet cafes, the first thing I would always open would be email.

2 and 3 and really valid though.

"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.

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.

> Most websites don't have secret token URLs that will log you in, right?

That's what they are proposing. Every time you log in they send you a one-time secret token URL by email.

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.

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.

Thanks!

There are security issues with this approach. However, I wouldn't mind if a site offers both traditional login and email based login. Then, I, as a user can choose which is the most appropriate.

You need a password to get into your email account. + You have to open your email account every time you need to login into the website, it's a bad user experience.

+ What if you lose your email account password?

Most people have their email open, not only on their desktop but also on their mobile devices. Most importantly, you'd only do this once per device, unless you need to log out or clear your cookies.

If you lose you email account password, you'd need to follow the email service provider recovery process. Gmail, Hotmail, etc. have significant resources dedicated to helping people with this.

This is how hi-games.net has worked for years, and it's a clever implementation, but I wouldn't want my bank to use it until we replace email with something, you know, secure.

One big problem with this approach: what happens when your email is down? Does a website really want to tie its availability to that of Gmail / other web mail services?

Another similar application but to you mobile instead. Acts like a physical key. http://launchkey.co/

It would be interesting if you could integrate a mail handler to this service so that you could simply email them to request a session.

> We're sorry, but something went wrong.

Now, cue the browser plugin to which you give access to your gmail (via OAuth), that handles this transparently.

Among other problems, have to put up with delays imposed by greylisting, if your email server does that.

So I have to check my emails every time I want to connect to your website? Seriously?

From my blog post:

"Yes, logging in by waiting for an email and clicking a link does take longer than entering a password. But you should only have to do this once per device. Unless you’re constantly letting other people use your computers (and logging out of your email client each time), you’re golden."

http://alexsmolen.com/blog/?p=194

I'm actually using this strategy more often than I would like to admit.

Alex, It´s giving me an error: We're sorry, but something went wrong.

Combine this with google authenticator for 2 step auth?

" We're sorry, but something went wrong. " :(

How do I run an webmail service with this?

This works well for mobile.

still annoying. i prefer browserid: zillion emails, one password =p

or password managers

railscasts also uses an email link for a login

what's wrong with OpenID again?

Regular people don't get it.

Seems to work okay on Stackexchange. Even the English and Home-Brewing versions!

Oh, when you said OpenID, I assumed you meant the UX concept (the idea of logging in with an URL). since that was the level being discussed here. SE does use OpenID, but it's essentially just a backend technology, which is irrelevant to the user; they can login with an integrated third-party service (Google, FB, etc) or even with a password (by choosing the SE provider).

We're sorry, but something went wrong.

This technique hits the front page once every other week. With the same flaws. Use BrowserID. It's better than this and it paves the future towards actually being able to truly transition away from passwords.

You mean Mozilla Persona? :)

Well BrowserID is the protocol, Persona is Mozilla's implementation. You can use BrowserID without using Persona.

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.

You use LastPass, but 99% of the web doesn't. This proposal makes a web site both easier to use for those users, and more secure.

Yes your proposal is good, I was talking to the commenters, sorry.

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.

Also you are kind of putting all your eggs in one basket...

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.

Reply on news.ycombinator.com