If you store the hashes of the tokens, even in the event of a database compromise (SQL injection, etc.), given the tokens are long random strings of bytes, it is not computationally feasible to reverse hashing, and therefore they do not gain access to the tokens.
Also, storing plain text, if the database indexes over this value, timing attack against the database is possible to get a token. Storing a hash, the more bits they want to attack, the larger their search space becomes. This would make timing attack also not feasible.
A lot of plugins, software, etc. use your library and database adapters and aren't written by security-conscious people. Please consider supporting or defaulting to this.
Thank you.
James
(You could even support an upgrade path by having two columns and nulling out the plain text one upon use if need be.)
If you store the hashes of the tokens, even in the event of a database compromise (SQL injection, etc.), given the tokens are long random strings of bytes, it is not computationally feasible to reverse hashing, and therefore they do not gain access to the tokens.
Also, storing plain text, if the database indexes over this value, timing attack against the database is possible to get a token. Storing a hash, the more bits they want to attack, the larger their search space becomes. This would make timing attack also not feasible.
A lot of plugins, software, etc. use your library and database adapters and aren't written by security-conscious people. Please consider supporting or defaulting to this.
Thank you.
James
(You could even support an upgrade path by having two columns and nulling out the plain text one upon use if need be.)