Hacker News Reader

Comment by pygy_ | Hacker News Reader

> 2. Record that token in your database, timestamped, along with the user account for which the token was requested.

The token is a password equivalent, and should thus not be stored in clear (use scrypt or a similar scheme).

No, this is unnecessary. An attacker who can pull tokens out of the database already has a terrible vulnerability and can probably avoid the need for passwords altogether.

I've tested many many many many applications in the last X years and not one of them has ever done this, nor would I ever recommend that they do it.

> [...] and can probably avoid the need for passwords altogether.

Probably, yeah...

In the case they only have read access to the token DB, and need write access, or read access to another part of the system, it becomes an attack vector.

It is not a cargo-cult measure, and it doesn't add much complexity (just re-use your password encoding logic).

The same goes for session tokens, BTW.

> [...] nor would I ever recommend that they do it.

Maybe you should reconsider that. I know who you are, and how knowledgeable and experienced you are, but in this case I think you're just wrong.

I have never, ever, ever, ever seen an application one-way hash their reset tokens to prevent disclosure of them from their database. That's all I'm going to say here.

http://en.wikipedia.org/wiki/Argumentum_ad_populum

A cargo cult is not an argument.

What I'll argue is that it's not a best practice, because nobody practices it. I also think it's a silly countermeasure, but I don't feel like I need to defend that argument.

I would not hash reset tokens, but I didn't downmod you for suggesting it. I would get mad at you if you worked on my team and dinged a client for not doing it, though. :)

> What I'll argue is that it's not a best practice, because nobody practices it.

And now you're begging the question!

Actually, some people use it :-).

It shuts down an attack vector, and it's cheap to implement. Why is it silly? My rule of thumb is to treat all passwords equivalents in the same way.

I'm honestly surprised by your hostility towards the idea (not mine, BTW), and by the downvotes for promoting a strategy that provably (in the math sense) increases security.

Name one. You don't count.

Here's where I read about it:

http://stackoverflow.com/questions/549/the-definitive-guide-...

Edit: Even if it were just me, it doesn't make the argument invalid.

Your arguments so far are

1) it's unlikely to be the weakest link. Textbook case of Murphy's law,

2) nobody does it, and

3) I've never recommended it, therefore it's useless.

I don't understand how you can resort to that... Seriously, I'm at loss here. Are you waiting for a high profile attack to react?

I know you have a reputation to defend, but I think you screwed it somehow in this case.

At least, it proves you're not a machine :-)

I am having trouble coming up with the attack that dumps the password token table but doesn't give up the whole app. Sorry.

So do I, but it doesn't mean it couldn't happen.

ONE WAY HASH ALL THE THINGS!

YAY! :-)

Edit: random Divine Comedy song: http://www.youtube.com/watch?v=EN65hsrtg94

Using BCrypt for them provides a layer of protection against brute force attacks, no?

What attack does bcrypting this CSRNG-generated number prevent?

Prevent someone who gets read access to the token DB from either highjacking sessions or resetting passwords.

Reply on news.ycombinator.com