:facepalm: you don't happen to work for Sony, do you?
If you develop web apps, don't do this.
21–30 of 113 posts
Re: If you develop web apps, don't do this.
#22A 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 "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…
> 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.
Re: If you develop web apps, don't do this.
#23Do what? Create database driven sites that can't handle the load? I get error messages or timeouts when trying to reach the site.
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 :)
Thanks for that. My poor old p3 personal page box just about imploded when @newsycombinator tweeted this...
Re: If you develop web apps, don't do this.
#24Earlier quoted context omitted.
> "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?
> 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,…
[deleted]
Re: If you develop web apps, don't do this.
#25What'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?
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.
Re: If you develop web apps, don't do this.
#26What'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?
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).
Re: If you develop web apps, don't do this.
#27Earlier quoted context omitted.
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…
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 al…
They both change the password, thereby granting access to the account. The security issue is really just the true stupidity of "sending password reset links via unencrypted email" - but it's already the standard so we can leverage that to offer auto-login links at no extra charge.
Re: If you develop web apps, don't do this.
#28The 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-…
You can use such tokens to disable email notifications, and still not provide complete access to the account, though.
Re: If you develop web apps, don't do this.
#29That'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.
Re: If you develop web apps, don't do this.
#30"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…
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.