2

Rails のデバイス認証フレームワークが、データベース内の reset_password_token と Confirmation_token をハッシュしていないことがわかりました。誰かが理由を知っていますか？

このような値をプレーン テキストでデータベースに格納するのは明らかに悪い方法です。データベースにアクセスできるすべてのユーザーがトークンを再利用して直接 API に送信できるからです (たとえば、アクセス権がなくてもパスワードのリセットを簡単にトリガーできます)。メールに）。さらに、これはハッシュをデータベースに保存するための最小限の作業にすぎません。だからこそ、プレーントークンのこのアプローチの背後にあるアイデアは何なのだろうか?

更新: 誰もそれについて意見を持っていませんか? 私の観点からすると、これはセキュリティの問題ですが、それについて心配しているのは私だけのようです:D

4

1 に答える 1

0

データベースでそれらをハッシュしても意味がありません。確認/リセット メールでは、保存しているハッシュ キーに対して、アプリがユーザーを識別するために使用できるトークン (招待/パスワード リセット トークン) をユーザーに送信する必要があります。これがプレーンテキストまたは双方向暗号化で保存されている場合、ハッカーがプレーンテキスト トークンを使用するだけで、アプリが喜んでそれをハッシュして認証するため、まったく同じ問題が発生します。これが一方向暗号化として保存された場合、アプリはユーザーに送信する必要がある実際のトークンを抽出できません。

誰かがパスワード/トークンの実際のハッシュされていないバージョンを知っている必要があります。パスワードでは、実際のパスワードはユーザーの頭に保存されます。この場合、実際のトークンをデータベースに保存する必要があります。

于 2013-05-08T10:03:52.510 に答える