

Tell-HN: Lessons from a hack: one-way hash, password reset tokens & session keys - ars

Joomla has an (as of this writing unpatched) SQL injection bug. The hackers requested a password reset, used the SQL injection to view the password reset token, and then used the token to change the password. (And once they had admin access to joomla, they had access to the filesystem and did lots more.)<p>Everyone (hopefully) one way hashes login passwords, but who thinks to do the same for password reset tokens? But in fact they are (short term) passwords and should be hashed.<p>And even if you do that, I'm sure very few will think to one-way hash session keys. But session keys are also passwords (albeit temporary ones). If someone can read your session store they can impersonate any logged in user!<p>So also one-way hash the session keys.<p>Not having SQL injections would nice of course :) But mistakes (bugs) happen, and you should have multiple layers of defense.
======
thaumaturgy
If they could use SQL injection to view the password reset token, then almost
certainly they could do the same to set a password reset hash to whatever
value they wanted.

~~~
ars
At least with MySQL, it's much harder. You can only have one statement in a
query. For reading you can add queries using a UNION, but I don't see any way
to embed an insert in a select.

