If you develop web apps, don't do this.

http://sneak.datavibe.net/20110614/please-dont-do-this/

by sneak • 15 years ago

239 110 15 years ago

sneak.datavibe.net

thirsteh9• 15 years ago

"Forgot your password" requests usually POST to the web server, not GET (what's usually used in emails). Sending links that give you complete control over the account by default seems like an extraordinarily bad idea--as does allowing users to reset their accounts without any kind of identity verification.

(You could do a POST from an HTML email, but then, in most email clients, the users would be prompted with "You are sending data to the web page. Do you want to continue?" every time they click such notifications.)

sneak14• 15 years ago

> "Forgot your password" requests usually POST to the web server

No they don't. They usually just have some sort of password reset token as part of the query string for a standard GET. AFAIK there isn't any good way to POST from the body of an email - do mail readers even do JavaScript?

thirsteh9• 15 years ago

> No they don't. They usually just have some sort of password reset token as part of the query string for a standard GET. AFAIK there isn't any good way to POST from the body of an email - do mail readers even do JavaScript?

I think you misunderstood what I was saying. "Forgot your password" requests, as in requests that will lead to the user receiving a new password/ability to reset their password, are usually POST, and are usually on a webpage, not in an email.

Besides, POST requests aren't Javascript. It's perfectly possible to use from inside an HTML email. Usually, though, the most you'll provide in an email is a link (GET request) with a param identifying the user, e.g. the UID, that will lead to a form that asks at least one security question.

Sending out links that essentially unlock the user's account via email by default seems incredibly risky to me, and only provides a minimally better user experience. Just do better session persistence -- then the worst thing that can happen is you need to log in once via your mobile phone.

sneak14• 15 years ago

Also, that's the core of my argument - the "click here to reset your password" link that is sent, on command, is a link that gives you "complete control over the account" without identity verification (other than your email box).

yread• 15 years ago

You can just make the link go to a page "Do you really want to reset your password?" with a POST form

roel_v• 15 years ago

Using POST over GET does not make anything more secure, if I'm understanding your point correctly.

And while it's true that many 'forgot password' forms use POST, there's really no reason for it. They could just as easily use GET links.

sneak14• 15 years ago

Variables in GET requests are stored in the history as part of the URLs. Variables POSTed are not.

badmonkey0001• 15 years ago

POST can be sniffed and is only slightly less vulnerable than GET. HTTPS at a dedicated address should be a minimum level of security for a login form. Anything else is readily vulnerable to sniffing or spoofing.

stcredzero• 15 years ago

Properly implementing hashed passwords with challenge-response will protect your login, though your session information can still be sniffed.

Legion• 15 years ago

If you create a blog, don't use fixed headers and footers that take up half a netbook's screen.

sneak14• 15 years ago

Sorry, I design for 2560x1600. I don't want poor people reading my site.

(That's a joke. I didn't even make the theme.)

thenduks• 15 years ago

Joke or not, I have to point out that just because someone's screen resolution is 2560x1600 doesn't mean they have their browser that huge. Personally, my browser is never wider than 1100px. I do usually go as tall as the screen, but on a small laptop...

yaix• 15 years ago

Just wanted to comment the exact same thing. And netbooks still have a big screen compared to many phones.

pyrhho• 15 years ago

There's a mobile version of the blog, though (without the massive header/footer.

cubicle67• 15 years ago

yes. I use space to move the content up a screen, and layouts like this mean I then have to go and scroll back a few inches.

nthj• 15 years ago

Even #newtwitter gets this wrong. Space jumps down a page, all right, but one of the unread tweets hides behind the black header.

I haven't looked into this, but if anyone has a fixed position header on their project, they should look into overwriting the space bar action readability-style and calculating how far to jump down.

Smoking_Gnu• 15 years ago

I use the Stylebot addon for chrome to hide annoying elements on websites:

https://chrome.google.com/webstore/detail/oiaejidbmkiecgbjei...

underwater2• 15 years ago

A good idea for some situations. There are some obvious caveats:

* Remember email is not encrypted. The links can be intercepted.

* Consider looking at other factors (like IP, browser data, persistent cookies) that will let you know the user is legit before you green light the auto-login.

* Link to HTTPS, not HTTP. The user might be on a shared computer and you don't want login-able URLs left in the history.

* Force the user to enter their password to access sensitive settings or data (like changing email, passwords, etc.)

sneak14• 15 years ago

The "click here to reset your password" links are sent over unencrypted email, too. I guess I am being insufficiently clear about why this is no less secure than what exists today.

> Force the user to enter their password to access sensitive settings or data (like changing email, passwords, etc.)

If they have to enter their password to change their password... then how will the "click here if you forgot your password" feature work?

nick_lewis2• 15 years ago

There's a difference between those two features. Changing the password requires entering the old password and entering the new password, so you're authenticating them via their password. Resetting the password requires sending a link to an email account you know they own, so you're authenticating them via their email account.

It's SORT of a "thing you know" vs. "thing you have", except the email account is kind of also a thing you know.

RossM2• 15 years ago

> I guess I am being insufficiently clear about why this is no less secure than what exists today.

Because it sounds scary really. But if someone aiming to take over an account already has access to the account's email inbox then forcing the user to reset their password immediately is no hurdle, it inconveniences a legitimate user (however briefly) more than a malicious user.

However, I am still not in favour of an immediate auto-login without a password reset beforehand (as there is a need for the user to update their password). Since we've already 'verified' that the user at least has access to their email (so it is probably them) I don't see anything wrong with automatically authenticating the user after this though.

thirsteh9• 15 years ago

Please don't act as an authority on security when you do not understand how something like a POST request works.

What you're encouraging is forfeiting the site's accounts in standard communication, of which you send many, many more than "Reset your password" emails (which should, but may or may not be triggered by a form that presents at least one security question), and which are fundamentally different than "account security" emails, for the sake of streamlining the user experience, i.e. saving the user from having to log in at all from new devices.

If any users forward any of these mails to anyone else, they've essentially given them complete access to their account--imagine if Facebook started doing that in their "You've received a new message". It's needlessly and inconspicuously compromising account security on a regular basis with no real win. (The idea wouldn't fare well in a proper risk evaluation.)

Deadsunrise• 15 years ago

change password shouldn't log you into your account, just provide a form to enter a new password.

underwater2• 15 years ago

That's true but with reset password links you can force the user to do extra work, like enter a CAPTCHA or answer a secret question. That should prevent bots from scraping and compromising accounts on a large scale.

Locke16893• 15 years ago

Remember email is not encrypted. The links can be intercepted.

This is somewhat false. You should clarify your intention here.

Locke16893• 15 years ago

Whoever downvoted me is apparently unaware of encrypted protocols like SMTP w/ TLS (which most major webmail providers use) and IMAP (which is increasingly preferred over POP3).

buchin• 15 years ago

Down here

unicornporn• 15 years ago

Do what? Create database driven sites that can't handle the load? I get error messages or timeouts when trying to reach the site.

wahnfrieden• 15 years ago

Cached copy: http://www.google.com/search?sourceid=chrome&ie=UTF-8...

(If you use chrome, just prepend any URL with "cache:" instead of posting snarky comments about it :)

sneak14• 15 years ago

Thanks for that. My poor old p3 personal page box just about imploded when @newsycombinator tweeted this...

acron0• 15 years ago

I for one will not be adding this feature to my web app. However, might it be possible to kick in a login process using OAuth/OpenID? The onus isn't then on you to validate the user.

danenania5• 15 years ago

This is the way to go imo. For some reason a lot of people have the idea that it's somehow more secure to build your own login system than it is to use Google's or Facebook's. But doing it yourself opens up new vulnerabilities and you'll be reinventing the wheel making all the mistakes that have been tested out of veterans' systems.

The convenience factor is also superb.

jpalomaki• 15 years ago

How about two states for authentication: "light" and "fully authenticated"

If I click to the site via link in email, I get to "light" mode. This allows me to see things. Other actions can require "fully authenticated" mode and the transition light => fully requires me to enter my password.

With password reset emails I'd like to have a basic security question (one that I can pick myself).

randomwalker• 15 years ago

The funny thing is that CAN-SPAM mandates 1-click opt-out, and requiring login to unsubscribe is specifically prohibited.[1] So most websites already have code to include and verify auth tokens in emailed links, which they utilize when they are mandated to.

But somehow they haven't figured out that it is in their own interest to do so the rest of the time.

[1] http://blogs.boomerang.com/blog/2009/06/16/can-spam-2008-uns...

thirsteh9• 15 years ago

You can use such tokens to disable email notifications, and still not provide complete access to the account, though.

danenania5• 15 years ago

This seems like a good compromise.

Allow immediate access for convenience in some cases, but restrict that access to a specific task until login.

zaidf2• 15 years ago

AFAIK CAN-Spam only applies for unsolicited emails, so a newsletter from a service you opted into does not need to abide by it. May be I'm mistaken.

pbreit2• 15 years ago

> CAN-SPAM mandates 1-click opt-out

Actually it requires one-click or two-click. And not for transactional emails.

staunch• 15 years ago

What's the safest way to do an instant login like this?

First thought would be to encrypt a query param with necessary info and add a few day expiration on the link.

Any good articles on doing this as intelligently as possible?

StavrosK4• 15 years ago

A good way I can think of is to include a user's secret (hashed password or whatever), HMACed with the number of the week. This way, the token expires at the end of the week. There would be a problem with links sent late Sunday, but I guess you could always try verifying with the previous week's number as well.

Of course, I'm not sure if this is faster than storing random tokens in the database and expiring them, but it sounds like it should be.

StavrosK4• 15 years ago

So, uh, why the downvotes with no comment?

RossM2• 15 years ago

I would use the same implementation as a password reset token - generate a hash and store it with a time-to-live - but I would probably be less lenient with the TTL (although as has been discussed, not for any real good reason).

thirsteh9• 15 years ago

There's no safe way. As soon as you start sending tokens that grant complete control over the account in normal/regular emails, you've reduced the account's security.

Joakal• 15 years ago

PGP-encrypted emails? It becomes a question of security vs convenience eventually with security considerations (Someone mentioned dating sites are more engagement > security).

There is no 'safest' way with encryption. It's a matter of time before it's breached.

StavrosK4• 15 years ago

So, the one with the most time before it's breached is the safest.

sneak14• 15 years ago

PGP encrypted emails? Are you serious?

Those of us that live in the Real World send our regards.

eli2• 15 years ago

I would also make each link only auto-login at most once per message (or maybe once per week across any message). You could also make the auto-login fail if any images from the message have previously been loaded from a different IP.

But there's no safe way.

nick_lewis2• 15 years ago

Huh, I was just thinking about this the other day, and wanted to rant about it but never got around to doing so. It's extremely annoying when I land on a login page from an email when I clicked to take a specific action. ESPECIALLY when logging in takes me to the home page, and not even to my intended destination.

radicalbyte• 15 years ago

:facepalm: you don't happen to work for Sony, do you?

StavrosK4• 15 years ago

That's what http://www.yourpane.com uses, so that when someone sends you a link you don't have to enter your password to use it.

As a matter of fact, it forgoes passwords altogether, using a secret token to log you in. It also creates an account as soon as you send a link to a friend, so there's no explicit account creation either. This is done to avoid the obvious hurdle, as it allows you to send links to your friends without them having accounts already.

newhouseb• 15 years ago

If you want to do this, at least make the login cookie expire at the end of the session.

I had a friend forward me an OKCupid e-mail when they sent mis-matches for April Fools - a few days later I realized that I had somehow been logged in as said friend and was majorly creeped out. Had I been less mature about it there was major potential for trolling said friend - particularly on OKC.

danenania5• 15 years ago

Mistakes like this will inevitably occur even with a cookie that expires as you suggest. Not as often as with a non-expiring token, but there are plenty of people who will leave a browser tab up for days at a time, keeping the session alive.

The convenience is tempting but it seems careless.

mdasen• 15 years ago

The reason so many sites prompt for password is for security. Yes, they will also send you an email with a link to reset the password to the same address. However, the difference there is that you will know if someone has changed your Foursquare password and the token used to allow for a password change can be expired immediately after the change takes place rather than offering continued access.

With the OKCupid system, someone that has access to my email (even for a short time) might get continued access to my OKCupid account. I won't know that they have access. With Foursquare, someone who has access to my email can get access to my Foursquare by using the forgot password system. However, when they reset my password, I won't know the new password and there's a decent likelihood that I will realize that someone has broken into my account.

With the forgot password system, it's easy to expire that token as soon as the password is changed. With the instant login system, you can't expire the token after its first use since the email will still be in the user's inbox where they expect it to work. In one case, there will be a URL in my history with the token and if someone is smart, they can just try typing in okcupid.com/l in my browser and wait for the autocomplete with an auto-login token from my history. With the forgot password system, it will be in my history, but it will have expired when I changed my password. So, even if I've signed out of my email and okcupid before letting a friend borrow my computer, there will still be an auto-login token in my browser history that can be exploited.

I'm not saying that there aren't low-security services where this convenience is good. It's more that the author hasn't taken into account that there is greater security in the forgot password system.

itcmcgrath3• 15 years ago

Not to also forget that if you have automagic login links in the email, you can no longer forward that email to anyone without compromising your account.

Try educating end-users on that one!

danenania5• 15 years ago

Yep, this alone is a borderline fatal flaw. The practice of sharing links, whether done intentionally or unintentionally through email forwarding, is pervasive and people won't stop to think about whether the url contains an embedded login token. This practice opens up a new class of vulnerabilities in the human error realm.

Now there could of course be ways around this like time/ip/geo pattern tracking, but that's no trivial enterprise.

JoachimSchipper2• 15 years ago

Simple solution: put a persistent cookie on the computer of everyone who's ever logged in. Automatically log the user in if this cookie is present and the URL is correct. Obviously, the cookie should be unforgeable - e.g. HMAC-SHA1(service_secret_key, username).

sneak14• 15 years ago

> With the instant login system, you can't expire the token after its first use since the email will still be in the user's inbox where they expect it to work.

As the article mentions, you can expire them after a week or so. And if you're smart enough to do this, you're smart enough to fall back gracefully to the old "login form" behavior when you get a link with an expired token.

cdcarter• 15 years ago

Hell, you could expire them as soon as they are clicked, and then have the fallback.

lamby• 15 years ago

Another trick is to mix in the user's hashed password when you generate and check the HMAC - that way if the user ever changes their password all the previous links fail to work.

sssparkkk• 15 years ago

> I'm not saying that there aren't low-security services where this convenience is good. It's more that the author hasn't taken into account that there is greater security in the forgot password system.

Exactly. And I think it's somewhat dangerous for the author of the article to not understand this important distinction and at the same time advise creators of web apps to implement this behavior.

Judging by the amount of upvotes for the article and the comments it has been getting, I'm afraid some of us will simply follow his advice and replace reset password emails with direct login links.

scoot• 15 years ago

It's getting upvotes because the title says "don't do this". People are voting for the fact that the article is offers bad advice. The author however doesn't seem to have quite grasped this - thanking us for his position on the HN front page!

pbreit2• 15 years ago

> The reason so many sites prompt for password is for security

I doubt it. I think the reason has more to do with what their framework or authentication scheme supports or how rigorous they are with user engagement.

fullmoon• 15 years ago

What about auto-login info in the browser? If you present them with the login form (maybe with username prefilled), and they need to submit the form, they can update their autofill.

jsvaughan• 15 years ago

Exactly. If you use an auto login cookie then the browser will not have the password, so for the sake of saving a user a small amount of time you'll inconvenience them in the long run, and discourage them from using the site.

bkhl• 15 years ago

I'm not sure if I can totally agree with the author. I understand his pain, but email isn't the most secured place. If your email is being "watched" by someone else, then that someone else can access other web services that you own WITHOUT requiring to type passwords! I know that it is very rare to have your email being watched, but in security, even the most rare case should be taken into consideration. It's a trade off between user experience and security. This is something you find very often in software engineering.

sneak14• 15 years ago

> If your email is being "watched" by someone else, then that someone else can access other web services that you own WITHOUT requiring to type passwords!

The person watching your email can ALREADY DO THAT NOW by clicking on the "I forgot my password" link, intercepting the reset email, and then setting a new password and logging in.

skrebbel• 15 years ago

That assumes someone has live access to your email. If someone has a recent enough dump (or simply a mail you forwarded yourself, because you didn't understand the security implications), then the "forgot password" button does really provide more security than login tokens inside the URL.

sainttex• 15 years ago

Traditionally if an account reset email is sent out you didn't trigger, it's a huge red flag. With this proposed approach, especially on a location based service like foursquare, getting access through a sniffed seemingly harmless notification email would most likely go unnoticed.

The closest method to this I'd personally implement is a toggle option only, with no further access. Similar to a standard unsubscribe toggle link.

zaidf2• 15 years ago

Plentyoffish emailing you your password.

OKCupid sending login token'd links

Notice the trend? When you're a dating website, engagement trumps security in many cases. But if you are a bank or any service with some liability, you're probably going to play it conservative as you should.

sneak14• 15 years ago

"Engagement trumps security" holds true for 99% of the sites this audience builds. There's a reason I used Foursquare as an example.

DavidMcLaughlin• 15 years ago

The real point is: don't do two-level ACL on websites.

At my previous company we had these "auto-login" links in emails and they are extremely powerful.

But maybe once every six months people would call or write in and say "I forwarded a job posting from one of your email alerts to a friend and they had full access to my account!" and we'd have to revisit the issue again, but the conclusion was always the same - we were getting absolutely ridiculous user engagement from emails because of this feature and this was too valuable to give up.

Before I left the solution I had started to push was to introduce a new intermediate user level - "logged in but not trusted" - to the standard logged out/logged in two-level ACL. The basic implementation would have looked like this:

1) A logged in but not trusted cookie is set on both manual login or auto-login from marketing materials. It allows us to assume that this is user X and they are taking action Y on website Z. It also allows the user to receive the user logged in view where that UX has been tweeked to minimise effort for logged in users.

2) A logged in and trusted cookie is only set on an explicit manual login, and is required to perform _any_ write operation as well as to read certain sensitive information.

Where the practical implementation gets difficult is you really need to refine when to require the trusted cookie - at what point in your UX - to keep the engagement high. It will almost definitely go down, you just want to minimise that.

For an example, say you're a service like LinkedIn. You send emails to your users whenever they get a private message and you want to make it easy as possible for that user to reply because recruiters getting candidate engagement happens to be one of your key metrics. User clicks on the message in their email and instantly gets a login page, they might have been 50/50 about engaging with this recruiter so now that you presented an obstacle they just close the tab and get back to what they were doing. Alternatively, you show them the message from the recruiter and allow them to type up a reply and only ask for a password confirmation when they hit send, and it's possible your engagement will go up.

It requires more thought and is surprisingly tricky to implement once you get past the really easy "read-only" versus "write" type security checks, but it seems to be the way things are going.

LiveTheDream• 15 years ago

The not-fully-trusted user paradigm is actually pretty common in websites for changing your password (enter old password, new password, and new password confirmation). The main reason, as I understand it, is to limit the damage made possible by session hijacking.

Session hijacking and the wrong person auto-logging in are actually the same thing on a technical level; the difference is semantics. In both cases, a logged-in user is not the owner of the account.

unshift• 15 years ago

amazon does that. you can browse the site and it identifies you and your preferences, but when you go to check out or modify account settings, you have to enter your password.

Splines• 15 years ago

... and it feels really natural. Amazon identifies me easily, but if I do anything that feels like I need my password, it asks for it. Apple's App Store has similar logic, although it bothers me in one place where they ask for your password when downloading free apps.

And then there's Windows Live. Click on anything remotely related to Passport? You need a password (followed by 17 redirects, which is hilarious when managers have sound turned on and you here the "click click click click click" as IE bounces around).

jarin• 15 years ago

I saw one of Amazon's UX team at a talk a while back, and the way he described it is they have a set of actions/permissions for people who are totally logged out, a set for people who are "sort of logged in", and then a set that require full login.

It's definitely tricky to implement (how do you determine whether a user is "sort of logged in"?), but once you get over the conceptual hurdles it's a pretty awesome user experience.

However, I would argue that like much of what Amazon does, it's not necessarily appropriate for the majority of sites.

ra• 15 years ago

I think you've confused Access Control Lists (ACL) with Authorization.

mikecomstock• 15 years ago

A good take-away from this might be "don't do two-level ACL until you have user traction".

DavicMcLaughlin says, "we were getting absolutely ridiculous user engagement..." When you are starting a site, you want as little resistance to usage as possible, and this helps with that. It makes it one step easier for people to use your site. It helps reduce the typical chicken/egg problem, or any other "it's hard to get users" problem.

Once you have the users, and security becomes more of a concern ("But security should always be a concern", yeah I know.) then you should start to think about something more secure. Until then, do all you can, within reason, to get users.

AretNCarlsen2• 15 years ago

> Once you have the users ... then you should start to think about something more secure. Until then, do all you can, within reason, to get users.

Worked well for Sony!

Seriously, that is an egregious abuse of both ethics and morality, the latter because you are implicitly abusing your users' trust (unless your welcome screen says "NOT YET SECURE" in huge font). If implementing reasonable security before you enter beta testing is such a resource burden that your product will go under before it can get its footing, then your product goes under. Ethics do not go away when your profitability and success are on the line -- that is the specific moment when ethics come into play.

I realize you have already thought through this and have a different POV. Newbies are liable to see this kind of talk however, and think it is an accepted industry-wide practice to treat security as an afterthought until you have scaled, when that is in fact a profitable but unacceptable antipattern.

P.S.- This is like a new small-town restaurant saying "Refrigerators are expensive, so we can't afford to refrigerate our eggs and milk until we get more customers. Otherwise we might go under from the increased operating cost, and then our customers wouldn't get to enjoy our restaurant!" Draw your own conclusion.

adjwilli• 15 years ago

A lot of issues like this will be overcome with iCloud's ubiquitous kay-value stores, but sorry those are native apps. This points out yet another way how the web is a broken platform.

eli2• 15 years ago

You should definitely NOT be putting auto-login links into every email without very careful thought and planning. People routinely forward emails to their friends and colleagues, or copy links and post them on twitter.

It's obvious that a password reset link should not be forwarded, but a monthly newsletter?

irfan• 15 years ago

Someone commented on the original post:

"Or provide a single use single action token that performs one function, like confirm friend. Security doesn’t need to be all or nothing."

For extra security this token can be one time useable only.

JonoW• 15 years ago

I think this could be done safely (well just about as safe as sending forgotten password reset links):

1. Set a short expiry date on the link (1 day). 2. On first click within 1 day, log user user in and expire link. Ask user if they want to stay logged in (via a subtle overlay at the top of the page perhaps + set "remember me" cookie) 3. On subsequent clicks within 1 day. If user has "remember me" cookie, log them, otherwise redirect to login screen. 4. Clicks to link after 1 day. Redirect to login page.

This should be just about as safe as a forgotten password email; they both have an expiry period + 1 time use, meaning anyone intercepting the email before the expiry and before the user clicks on it can impersonate the user.

The only counter-point that I'll make against my own point is that a forgotten password email is sent on demand, i.e. a user requests it, so they are probably more likely to click it immediately (hence expire it immediately).

I wouldn't do this for an e-commerce or otherwise sensitive app, but for something a bit more casual I think it would ok.

siavosh• 15 years ago

This is a compromise in security, and it should be seen in the context of the application/domain. I don't think it would fly in the medical or financial world.

dkokelley• 15 years ago

After reading the article and comments, it appears that what this really represents is a need for more secure email protocols. How would one go about creating and ensuring and end-to-end secure email protocol? It could be done within a domain, but once you send or receive messages outside of your domain it's up to the intermediate and end parties to keep the message secure.

I suppose you could ensure secure communications via encrypted messages and end-clients with the key, but how could such a system be ubiquitous and practical?

rachelbythebay• 15 years ago

It seems like this calls for a two-pronged approach. If you've been logged in to their site from that browser in that account, then the link from the e-mail should auto-log in (unless it's been disabled for that account). Otherwise, it should prompt to allow an actual login as usual.

This way, you can forward an e-mailed link, and unless they happen to have logged as you already, they don't get into your account.

This probably means a significant amount of attention to detail to exactly which cookies are set, how long they live, and what they mean, but it sounds worth the effort.

If you develop web apps, don't do this.

Related Stories