uniqueID should be hashed for ProtoUser?

[Tobias Pfeiffer]

Hi,

I am digging a bit into Lift user handling right now and I have some
concerns with respect to the uniqueID.

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.

In fact, for the purpose of logging in to the website, the uniqueID is just
as valuable as the password itself. That is, it should in fact also be
hashed (and salted?) such that findUserByUniqueId(id: String) does no longer
just do "find(By(uniqueId, id))", but rather something like
"find(By(uniqueIdHash, hash(id)))".

What do you think?
Tobias

[David Pollak]

The answer is not to hash the uniqueId... that won't solve anything.  The answer is to put a timeout on the uniqueId so it can only be used for a certain period of time.  Then the time-scope of the attack is limited (the time between a user requesting a password reset and the reset taking place.)

Please open a ticket and assign it to me.

More broadly, this is much less of an issue than salting passwords.  This allows an attack on your web site and allows someone who captures your database to get control of accounts... although if they have access to your database, they have the ability to change passwords at will by writing rows in the database.  The bigger issue of non-salted passwords is one of being able to get a username/password combination that can be used on other sites because more people use the same password for many different sites and very often, their email address is their user-id.

Tobias

--
Lift, the simply functional web framework: http://liftweb.net
Code: http://github.com/lift
Discussion: http://groups.google.com/group/liftweb
Stuck? Help us help you: https://www.assembla.com/wiki/show/liftweb/Posting_example_code

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Tobias Pfeiffer]

Hi,

Am Montag, 2. Juli 2012, 19:02:38 schrieb David Pollak:
> Please open a ticket and assign it to me.

I created
https://github.com/lift/framework/issues/1289
but I didn't find where to assign it to you.

> The answer is not to hash the uniqueId... that won't solve anything. The
> answer is to put a timeout on the uniqueId so it can only be used for a
> certain period of time. Then the time-scope of the attack is limited
> (the time between a user requesting a password reset and the reset
> taking place.)

Hm, I don't see why hashing wouldn't help. In the password reset mail, I put
a link like

http://myurl.com/user_mgt/reset_password/someSecret

but in the uniqueId field, I store hash(someSecret), with some good-enough
hash function and change the implementation of findUserByUniqueId to:

protected def findUserByUniqueId(key: String): Box[TheUserType] =
find(By(uniqueId, hash(key)))

In that case, someone who has read access to the database is not able any
more to trigger the password reset unless he knows how to compute hash^{-1}.

> More broadly, this is much less of an issue than salting passwords. This
> allows an attack on your web site and allows someone who captures your
> database to get control of accounts... although if they have access to
> your database, they have the ability to change passwords at will by
> writing rows in the database.

That is true, but many of the issues we see those days are like "someone has
uploaded a table dump to RapidShare" or "someone sold the user table to X"
or so, aren't they?

Tobias