ruby on rails - Why does devise not hash reset_password_token and confirmation_token? -


i figured out devise authentication framework rails not hash reset_password_token , confirmation_token in database? know why?

obviously bad approach store such value in plain text in database, has access database can reuse tokens , send them directly api (e.g. 1 can trigger password reset, without having access email). furthermore minimal effort store hash in database. that's why wonder ideas behind approach of plain tokens?


update: no 1 has opinion on that? point security issue looks 1 concerned :d

there wouldn't point hashing them in database. confirmation/reset email still have send token user app use identify them (an invitation/password reset token) against hashed key storing. if stored in plaintext or 2-way encryption have same problem, hacker use plaintext token , app happily hash , authenticate them. if stored 1-way encryption app wouldn't able extract actual token should send user.

someone has know actual, unhashed version of password/token. in passwords, actual password stored in user's head. in instance, actual token needs stored in database.


Comments

Popular posts from this blog

c# - Send Image in Json : 400 Bad request -

jquery - Fancybox - apply a function to several elements -

An easy way to program an Android keyboard layout app -