41–50 of 113 posts
Earlier quoted context omitted.
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.
Variables in GET requests are stored in the history as part of the URLs. Variables POSTed are not.
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.
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…
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 sys…
Try educating end-users on that one!
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 sys…
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.
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…
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.
Earlier 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…
change password shouldn't log you into your account, just provide a form to enter a new password.
I can just set a new password and then log in with it anyway. Don't make your users jump through hoops.
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 sys…
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!
Now there could of course be ways around this like time/ip/geo pattern tracking, but that's no trivial enterprise.
Earlier 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…
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 "accoun…
This my first thought upon reading the article. If people designing websites are making decisions that are not really well thought out (like this), episodes like Sony will continue to happen.
It really makes me sad.
It also makes me angry.
Earlier quoted context omitted.
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!
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 n…