I've recently been thinking (a little too much, it can be argued) about what autologin links do to your web application's security profile. My position has been, as with most hole-punching, to never engage in the practice. I first said "No" to such a feature request in 2005, and have since said to similar requests:
- "No."
- "Absolutely not."
- "WTF. No."
- "Well, that's not a good idea. I will remind of this every time you suggest it." and
- "You're on the crack, son."
...not necessarily in that order and sometimes more than once. The counter-arguments I've heard for autologin links include:
- This isn't high finance
- What's the worst that could happen? [No pause.] It's worth the risk.
- So-and-so is doing it
- We need a higher conversion rate
- Logins are so 2001! (seriously)
The whole series of arguments for and against one-time autologin links should be split into two distinct email types with two scenarios each:
- Transactional Emails
One-time: Password reset links are a great example here. The user initiates an email with a "one time password reset" link, which the user then receives in their inbox. These are typically, as is the case in Drupal, one-time in that they cannot be used more than once and dump the user directly into a screen within which to change their password. This intention and sequence of events is important - the user is invested, an email is generated (at their discretion), and that one-time autologin link is used up pretty quickly. Therefore, you may expire that one-time login fairly quickly, as well.
Perpertual: You may want that link to NEVER expire, like in an account statement for a service or a welcome email. In this case, the email contains an autologin link instead of or in addition to username (and possibly password!) sent as clear (unencrypted) text. - Marketing Emails
One-time: Promotions or targetted conversion offers (e.g.: "Upgrade using the below link to save 20%!") are the prime examples here. But you take out the password reset component - the user may *never* know their web application credentials, just have access to the email address. Is that good enough? Perhaps, unless your user has access to previousl transaction details. A billing address or access to security challenge Q&A may seem pretty innocuous, but are potential vulnerabilities for your user, not to mention the time consumed in rectifying any actions (comments, contact form emails, etc) taken while masquerading as a user. Also, expiration rules (since the user isn't waiting with baited breath for this email and may *never* get to it) need to be more flexible. (Read: LONGER.) This means a wider window within which that autologin is open to vulnerability, no matter that it can only be used once, making it inherently different from the albeit similar Transactional Emails use case above.
Perpetual: This is the worst case scenario from my perspective. A reusable link that a user can just store in their email instead of ever authenticating using web application credentials? This link would appear in server log files, thus opening up the can that any perpetually available login link is logged/stored in multiple places.
I stand by my 2005 position for all of these reasons. And no, maybe you're not trading securities or storing health care information... but there is no excuse for poor security when the holes that you punch in otherwise "good" security are so avoidable.
Some more reading if you're interested:
Add comment