Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Make uniqueIds more secure #1289

Open
tgpfeiffer opened this Issue · 1 comment

2 participants

@tgpfeiffer

Reference: http://groups.google.com/group/liftweb/browse_thread/thread/194410e1bf38c076

Problem

Say, someone gets a dump of my users table (doesn't need to be Lift's fault, can be a bad database configuration), then all the passwords in there are salted and hashed and so the attacker has no realistic chance of recovering any of the passwords therein. Also, some intern who might have read access to the database cannot see the password.

However, the uniqueID allows to silently reset the password by visiting the URL

http://myurl.com/user_mgt/reset_password/{uniqueID}

That is, even though the passwords cannot be recovered by an attacker, they can be reset to an arbitrary value (which is bad enough for, say, online banking). If I noticed that someone got access to my database, I can simply say "UPDATE users SET uniqueId=..." and get rid of that problem, but until I notice, the attacker is free to take over any account in the database.

Possible solutions

  • When sending out links with "secret keys" (e.g., password reset), do not store those keys directly in the database, but only a hashed version. Thus, it is not possible to trigger the action just by knowing the database content, but only by knowing the key.
  • (by dpp) Add a timeout to the uniqueId such that it expired after some time.
@Shadowfiend Shadowfiend modified the milestone: 3.0-M1
@Shadowfiend
Owner

The timeout's a good idea. Not sure if the hashing of the reset key secures us against much, but I'll think on it, as I may be wrong about that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.