31–40 of 113 posts
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.
Earlier 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,…
Dumb sites then require the user to type it in a third time to log in, "smart" ones log them in when doing the update operation.
Most sites don't have any security questions.
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?
"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.
Earlier quoted context omitted.
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).
You can just make the link go to a page "Do you really want to reset your password?" with a POST form
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.
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…
This is somewhat false. You should clarify your intention here.
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 "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…
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.)