security - How would a secure "lost password" feature work?

Question

The "done" way of doing password resets seems to be the following:

1. Generate a temporary token (zs8Abn27)
2. Store token in a database along with an expiry time
3. Email token to the user
4. User goes to /password_reset?t=zs8Abn27
5. Token is checked against database for validity
6. If valid user gets a new password which is stored in your database (salted and bcrypted, of course)

My question is if a hacker gets read/write access to your database wouldn't they just be able to create their own tokens, and gain access that way? Even if they just had read access they could use the tokens they can see to gain temporary access.

For the record this is entirely conceptual, I'm just curious how you could make a feature like this secure.

Answer 1

Have a read of Everything you ever wanted to know about building a secure password reset feature.

Yes, someone who has access to the database can create their own tokens but they can also just reset passwords to whatever they like anyway (assuming they know the hashing algorithm used). Plus they can always create new accounts, elevate privileges or perform any number of other malicious tasks.

Assume that if the database is breached you have problems of a scale that make access to reset tokens insignificant!

Answer 2

必要なプロセスの説明は正しいです。

ハッカーがデータベースにアクセスすると、すべてが失敗に終わります。あなたの努力はそれが不可能であることを確実にすることに向けられるべきです。

Answer 3

Well, first of all, and not just because of this matter, we need to make sure that the hacker does not breach the database and get read/write access.

Another approach would be storing the tokens not in the database, but on the filesystem. In a folder which is not readable but only by the webserver user, secured against access by .htaccess, regularly cleaned by cron, so the tokens expire relatively quickly. This way, the code responsible for password recovery will check against this file, not the database.

But yet again, that is hackable too.

Answer 4

In addition wo what has been said, you could hash the token before storing it in your DB, but after mailing it to the user.