Hacker News Reader

Comment by ErrantX | Hacker News Reader

Or, you could do the sensible thing that other sites do - and provide them an auto-login url in the email rather than the plaintext password.

View on HN

Of course, you only want to do that for medium-security stuff - if banks mailed out unrestricted auto-login URLs, sniffing unencrypted POP/IMAP traffic at a coffee shop would be rather profitable...

Two points:

1. If you're not reading mail over SSL you've got bigger problems than this; and

2. The problem is also password reuse. No one can remember a totally separate password for the 9827342 sites they've registered on. There are patterns and reuse (or a password manager, which is a little more clumsy but much safer although it then introduces other security issues). So when a password list of hacked as in this case or with Gawker, you almost certainly have compromised users' credentials on completely unrelated sites.

Even if you read email over SSL, it's likely not transported that way.

Sniffing traffic on the internet backbone is orders of magnitude more difficult than sniffing traffic on an open access point. Even if you could do it, making it practical is a terrific challenge of scale.

I provide a link that will allow a password reset in mailouts.

I think that understanding of that this link is isn't as easy as recognizing a password. Everyone on the internet is used to passwords, but not to strange big links in email messages

They are more than likely to be clicking a link in the email anyway, so why not remove the barrier to entry (password). OKCupid emails have a big "call to action" button that says "Login instantly" (or something similar), you click it, you log in. Simples :)

I've seen that link and I had no idea it was an auto-login.

"We miss you. <link>Click here</link> to visit us again." - or some other sensible wording. Most pages already send you html emails, so no big change needed here.

That's silly. Email auto-logins have a time-limit (within 10-30 minutes) and a good developer would limit such email send-outs. The users would understand that email logins to the website are due to the links.

As a replacement for STORING PASSWORDS IN PLAIN-TEXT and EMAILING USERS THEIR PASSWORDS IN PLAIN-TEXT an auto-login link sent in an email without a time limit is a vast improvement.

For example, what happens if you discover you've been hacked and all of your encrypted passwords have been stolen? No big deal. What happens if you discover a hacker has stolen auto-login links for a large number of accounts? Invalidate all of the existing ones and send out new ones. Compared to the problems of getting 100% completely owned (and screwing over your customers) due to storing and sending plain-text passwords, these problems are vastly preferable.

Now you have another security hole - teaching people that it's a good idea to click links in emails, and making it orders of magnitude easier to be phished. Probably better than plaintext passwords, but still bad.

Indeed. The key thing to remember is that you don't have to be perfect to be better.

Yes, from a security standpoint it's bad practice to encourage users to click links in email, or to send one-click login links in email that don't expire in a short amount of time. However, not every website is a bank, and for the vast majority of sites protecting access to the site itself takes a backseat to securing the user's password (which more often than not tends to be shared amongst many sites).

>For example, what happens if you discover you've been hacked and all of your encrypted passwords have been stolen? No big deal.

Encrypted passwords are just as bad, because anybody that can steal your password store can probably get at your source code, or wherever it is that you store the key.

Store hashes instead.

Do you mean the salt? Most of the time I see passwords stored it is through one-way functions, not universal keys, and in the case of a salt they would have to construct a rainbow table and even then they still wouldn't be able to get my password, its just too long. They might be able to get a string that has the same MD5 (Protip: don't use MD5s for password storage) as my password, but if its a salted password it doesn't matter anyways.

Yes, hashed with a salt, as in sha1(password+salt). Of course, then they start hunting for your code/config file/whatever, to find the salt; but it's an extra barrier.

Ah, I had a parsing error while reading your comment and I was confused. I 100% agree with you.

That's all true - but in production systems, the risk of someone getting ahold of a single password table in a database is differnet than, say, getting the source code to the production system. Just because they have one doesn't mean they have no other.

If someone can get all your production code, data, AND configuration settings, you are screwed no matter what you are doing.

If you could use the unique, generated key only once, what would be the harm in not letting them time out?

I guess e-mail sniffing could be a risk... but if that's an issue then we have larger problems.

Ideally, you want both. The link being clicked on twice is a clear red flag for a problem, but if the user requests a password and then for whatever reason doesn't click on the link that quickly, how are you otherwise going to know who's done the interception? In theory your legitimate user will be clicking on the link quite quickly (because they know when they requested it after all), so combining both increases your security.

It seems to me that there would be a benefit in checking ip addresses so that you could only click the link from the same IP that requested it. That way snoopers have even more work to do.

Not necessarily a good idea. On an average working day I'll probably use 5 different machines; I could very well trigger an action on one, go off to do something else while waiting for an email (if it wasn't instant, these things often aren't) and come back to it on a different machine altogether.

OK I'm unusual in my usage habits, but I suspect a complete IP filtering (at least without a warning about it) would cause issues.

Reply on news.ycombinator.com