4 ms·

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

by Joakal 16y ago

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.

InclinedPlane 16y ago
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.
- anthonyb 16y ago
  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.
  - InclinedPlane 16y ago
    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).
- metageek 16y ago
  >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.
  - 3pt14159 16y ago
    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.
    - metageek 16y ago
      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.
      - 3pt14159 16y ago
        Ah, I had a parsing error while reading your comment and I was confused. I 100% agree with you.
        dedward 16y ago
        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.
rix0r 16y ago
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.
- eftpotrm 16y ago
  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.
  - stonemetal 16y ago
    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.
    - eftpotrm 16y ago
      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.

by Joakal 16y ago

InclinedPlane 16y ago

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.

anthonyb 16y ago
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.
- InclinedPlane 16y ago
  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).
metageek 16y ago
>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.
- 3pt14159 16y ago
  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.
  - metageek 16y ago
    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.
    - 3pt14159 16y ago
      Ah, I had a parsing error while reading your comment and I was confused. I 100% agree with you.
      - dedward 16y ago
        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.

rix0r 16y ago

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.

eftpotrm 16y ago
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.
- stonemetal 16y ago
  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.
  - eftpotrm 16y ago
    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.