データベースにREST APIトークンを格納するために使用するハッシュの種類は何ですか？
RESTモバイルフロントエンドと通信するAPIがあります。ワンタイムパスワードを送信した後、バックエンドはモバイルアプリが認証として使用するトークン（ランダムUUID v4文字列）を発行しますサーバーは、このトークンのハッシュバージョンをユーザーと共にデータベースに格納します。
トークンの認証に必要な時間をできるだけ短くする必要があります。
[〜＃〜]質問[〜＃〜]
トークンをデータベースに保存するには、どのようなハッシュ/暗号化で十分ですか？ SHA256などの高速ハッシュで十分ですか、それともbcryptなどの低速ハッシュを使用する必要がありますか？ SHA256を使用している場合、元のハッシュされていないトークンはランダムな16バイトのUUIDなので、saltを含める必要がありますか？
TLDR; SHA256で十分です
これに答えるには、まずソルト、ハッシュ、およびハッシュの複数の反復を使用する理由を調べる必要があります。
ソルトする理由パスワードエントロピーの弱いユーザーがパスワードを解読されるのを防ぐため（たとえば、レインボーテーブルまたは同じパスワードを持つ2人のユーザー）。 UUID4には122ビットのエントロピーがあるため、これは問題ではありません1。
SHA256ハッシュされたすべてのUUIDv4値のRainbowテーブルを作成したい場合、1兆ハッシュを1秒で実行できます。2。レインボーテーブルを作成するには 168.6兆年 かかります。したがって、そのことを心配する必要はありません。
ハッシュする理由パスワードのクリアテキストコピーが保存されないようにするため。これは良い考えのようです。あなたはあなたのデータベースを読むことができる誰かを望んでいない３ ユーザーを偽装できるようにします。
なぜ複数の反復を使用するのですか？総当たり攻撃を遅くするため。前述のように、UUID4には122ビットのエントロピーがあります。これらのハッシュをクラックすることは、高速でも実行できません。
[1] 128ビット-6ビット 所定
[2]現在の最速のハッシュ率は常に連鎖しているので、数か月で最新ではない最新の速度を見つけようとはしません。
[3]これは、SQLインジェクション、バックアップからのリークされたコピー、インサイダー、またはその他の可能性があります。