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