As far as I can tell thread.com log their users in automatically based on a token in their emails, appended to the URL.

e.g https://www.thread.com/1234logmeintomyaccount-forexample

This is a really useful, great feature and makes it very easy to interact with the site without having to remember/sign in all the time.

However, they also save credit card and address details for easy checkout.

So, unless I'm missing something, if a user forwarded one of their emails to someone and say that got forwarded on again, anyone could log into their account, see their personal information and mess with their money. You could also find the URL in a browser's history and access it there.

Is it me or is this a massive security flaw and, if the worst happens, therefore a terrible user experience. The benefits are brilliant but the potential risks seem to far outweigh those benefits.

If I have missed something and this is done securely, how are they doing it?


migrated from ux.stackexchange.com Nov 26 '14 at 14:48

This question came from our site for user experience researchers and experts.


In my perspective it's probably approximately the same level of security as allowing you to reset your password with only using an email address. Essentially, if you can request a password reset to be sent to you in an email, and one click later you set a new one, it's the same thing.

Now, forwarding such an email contains the same security risks in both scenarios, but honestly, when was the last time you forwarded a password reset email to your friend? In the same way, why would you forward a login email to someone else but yourself?

Also, despite being in the browser's history the link should usually only single-use (i.e. can't use an email from decades ago to reset your password, you have to create a new request). Similarly, when clicking an auto-logon link, the server gives you a cookie and deletes the url token from its side, effectively disabling you from using it twice from two different computers.

Of course, I haven't tested this at all, so it should be taken with salt, but hopefully this is all reasonable enough.

  • With regard to forwarding an email I realise the unlikely nature of it but it's the fact the user knows nothing about it. And it's the kind of thing that you can imagine happening once (someone orders £1,000 of stuff to your address as a joke or something) and then gets picked up by the media and damages a companies registration. It's the fact that the user isn't made aware of this. With regard to deleting the URL token, I've tested and they don't do that. That would kind of be disruptive to the user experience though, I would expect it to work consistently. – Tomass Nov 27 '14 at 9:57
  • Single-use might be too strict. The token should only be good for a limited time. If you click on it after that, they should email you another, to make sure you still have access. – Ben Mar 10 '16 at 14:10
  • this is all personal opinion, you should all depersonalise and back your stance up by citing evidence and/or best practices. en.wikipedia.org/wiki/Negligence – straya Oct 26 '16 at 6:39
  • @straya Welcome back from yesteryear! How are you? – Tsaukpaetra Nov 9 '16 at 4:50
  • 1
    @Tsaukpaetra been busy saving the world, one vulnerability at a time :) – straya Nov 10 '16 at 8:00

Unless you have spent some time analysing and attempting to penetration test a 'forgot password' mechanism, do not assume you understand or appreciate everything that is involved.

Various discussions on this on the web seem very shallow/naive. 'Suspicious activity detection' being the most obvious thing that should be happening under the hood on any sanely implemented system. Without that, this is super-dodgy. With that, this is less dodgy (but still considerably dodgy). Case in point: banking/financial institutions do not provide such an easily subverted feature.

  • If a system is dealing with financial information then do not do this.

  • If a system is touching a credit card system then do this only in accordance with Payment Card Industry (PCI) standards (e.g. PCI-DSS), or get someone who knows what they are doing to do it.

  • If a system is touching/storing other sensitive information (e.g. personal data) then consider the risks and proceed very carefully (achieving OWASP Top 10/PCI-DSS standards would be considered "best efforts"...failing to put in your best effort is effectively negligence, so pray that you don't get sued).

Please read carefully:

https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet https://www.owasp.org/index.php/Logging_Cheat_Sheet

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.