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:
Comments
"A less bad idea"
So by this point there are a number of things you should be thinking about w regard to perpetual login links.
a. Expiration -- aggressive garbage collection of link tokens (as defined by your tolerance for risk and the application), perhaps run as a hook_cron task.
b. Partial Authentication -- look at what LinkedIn does with this... you can view a lot of stuff via those links, but when you try to DO something with it, like add or edit information, a password is required.
c. Lastly, my point is to just not do it. That's how this is avoidable. But we all have bosses, and I feel for you.
To your question, take a look at your boss' perspective: his business goal is to (A) secure these data -- which have assumed value to the client and their competitors -- but (B) make it as easy as possible to view them. The assumption in A is where to start -- does it actually need to be as locked down as perceived? I mean, maybe some slightly randomized path ("security by obscurity") and not requiring authentication at all would be acceptable, sort of like the LinkedIn model. There are lots of variations on that theme.
So if that doesn't fly, what about B? What are the real barriers to remembering a login for a service for which you're paying? You *could* go half-way (again, like linkedin) and populate the username / email address + require password. Part of that would have to be the business goal of making it easy... to reset a password. Drupal makes that easy, right? Well, you could make it easier by providing a one-click solution for resetting the password, assuming that you know the email address already from that link. If the link's expired, you could presumably keep the same flow but turn the one-click/"easy button" approach transparently into the regular Drupal form. This is, of course, if you're using Drupal, which is pretty flexible on these points via hook implementation.
There's a reason why the Drupal Security Team has gotten involved in the behavior of modules that do this kind if thing -- to do so is risky as noted here and elsewhere. I think the truth lies somewhere in between "dead simple" and "totally annoying" to secure these assets. This, of course, assumes a need for such security -- in lieu of punched holes, you could just remove the wall.
So, you propose?
Hi Brian,
Great issues you brought up...but what do you propose as an alternative?
I'm not exactly sure what you were referring to when you ended with:
"but there is no excuse for poor security when the holes that you punch in otherwise "good" security are so avoidable"
How?
I'm looking for a better solution for my boss's idea to send his clients autologin links to view project processes (these are concrete test results). My initial concern was that a user can intentionally or accidentally send fwd this link to someone who should not have access to it. Then there are your other mentioned issues... We would prefer a "perpetual" link.
Thoughts? Thanks.