Q&A
質問がデフォルトのままになっています。
(初めてで使い方がわからず変な文章を投稿してしまいすみません。編集依頼くださった方々ありがとうございました。)
前提
Webアプリケーションのパスワード送信･保存時におけるパスワードの不可逆暗号化(ハッシュ化)のストレッチングについてです。その他SSL/TSL，salt付与等は行うものとします。
Webアプリケーションのセキュリティについて様々なページを読んでいて、ストレッチングというものがあったのですが、これの目的はハッシュ化されたパスワードが漏洩した場合、処理に時間をかけることでパスワードの総当り(または辞書)攻撃を防ぐものだと理解しました。
質問の主題
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、ユーザーから見た時間的な差異は大きくないと思います。
###具体例
パスワード入力から保存までの具体的な処理としては、
クライアント側
1, パスワードを入力(変数passとする)
2, passをハッシュ化する × 10,000回 (結果をpass_chとする)
3, pass_ch(とuserId)をSSL通信でサーバーに送る
サーバー側
4, salt値を決める
5, 送られてきたpass_chとsalt値を合わせてハッシュ化する(結果をpass_shとする)
6, pass_shとsalt(とuserId)をDBに保存する
が、自分の考えた処理です。具体例として提示しました。
###思いつくデメリットと解決策
自分の思いつくデメリットは、
①パスワードが適切なものかの判別(文字数が適切か，"aaaa","pass"等をはじく)が必ずしもできない
↑必然的にクライアントで判別することになるため、JavaScriptをいじられてしまったらパスワードが"aaaa"でも通ってしまう
なのですが、①に関してはわざわざJavaScriptをいじってまでパスワードを短くしたい人は少ないですし、そうした場合でもsaltを付与してハッシュしているのでレインボーテーブルもある程度無効化できると考えています。
###まとめ
よってストレッチングを、処理の集中するサーバーサイドで行わず、クライアントサイドで各々実行する事について、デメリット等あるのか質問させていただきます。またその他自分の認識で間違いがありましたら、御手数ですが教えていただけると嬉しいです。
長くなりましたが、有識者様の意見が聞きたく質問させて頂きました。拙い文章で申し訳ありません、よろしくお願いします。
回答2件
0
ベストアンサー
ご指摘のような方法は採用されている例があります。私が知る限りでは、Lastpassのマスターパスワードがそのような方法で保護されています。以下は、北河 拓士さんによる解説の引用ですが、
マスターパスワードはデバイス側でPBKDF2-SHA-256(PBKDF2でハッシュ関数としてSHA-256を使用)の反復回数100,100回(デフォルト値、設定で変更可能）でハッシュ化され、更にPBKDF2-SHA-256の反復回数１回でのハッシュ化を行った後にサーバーに送信されます。サーバー側では、256bitsの乱数をsaltとし、 PBKDF2-SHA-256の反復回数100,000回でのハッシュ化を行い、更にGPUやASICでの解析にも強い鍵導出関数「scrypt」でハッシュ化され、認証ハッシュとして保存されます。ユーザー認証時には、同様の計算が行われサーバーに保存してある認証ハッシュとの比較が行われます。
おすすめのパスワード管理ソフトは？ | Bizコンパス -ITによるビジネス課題解決事例満載！より引用
maisumakunさんから『攻撃者は「クライアントが送信するハッシュ値」を総当りするところからスタートできる』という指摘がありますが、現実にはこれは困難です。
なぜかというと、上記のようにSHA-256ハッシュをサーバーに送信する例で考えると、すべてのハッシュ値のとり得る値は 2^256 で 約 1.16e+77 通りあります。これに対して8桁英数字の総数は 62^8 で約2.81e14 で、1万回ストレッチすると、2.81e18回のハッシュ計算を要することになりますから、ハッシュ値での総当りは現実性がなく、結局パスワードから総当りした方がはるかに効率がよいことになります。
問題は、そのような方式の実現ノウハウが十分に共有されておらず、また信頼できるライブラリがない（知られていない）ことだと思います。なので、結論としては、サーバーサイドでストレッチした方が無難ということになります。
投稿2021/02/10 10:22
編集2021/02/10 10:30
総合スコア11705
回答ありがとうございます。
なるほど、似たような事例があったのは確認不足でした。サーバーでの処理軽減ではなくセキュリティの強化が目的のようですね。そちらの実装の方も詳しく勉強させていただきます。
256bitのハッシュ値を総当りすることについても計算すればパスワード自体の総当りの方が少ない計算回数であることは簡単に分かりましたね…自分でもしっかり考えてみようと思います。
また、ご指摘いただいた問題についてもよく検討させていただきます、ありがとうございました。
0
「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。
そもそも論として、「そこでサーバ負荷軽減をする」という考え方自体が適切ではありません。
処理時間をかかるようにするのは、「パスワードの検証自体にも一定の時間を消費するようにする」ことで、連続したパスワードで立て続けに検証することを阻止する、あるいはハッシュ値が手に入った場合に総当りで検証する手間を少しでも稼ぐためのものです。
処理負荷をクライアント側に移してしまえば、攻撃者は「クライアントが送信するハッシュ値」を総当りするところからスタートできるようになり、攻撃に対しては手薄となります。
投稿2021/02/10 08:06
編集2021/02/10 08:08総合スコア145973
ビットコインのようなProof of workシステムを取らない限り、攻撃者は「ハッシュ値を計算したふりをして適当な値を投げる」ことが可能です。
回答ありがとうございます。なるほど、回答くださった
・「(自分のサーバーの)『パスワードの検証自体にも一定の時間を消費するようにする』」
・「攻撃者は『クライアントが送信するハッシュ値』を総当りするところからスタートできるようになる」
の2つのことについてどちらも盲点でした、とても分かりやすく説明して下さりありがとうございます。しっかり勉強し直そうと思います。
あなたの回答
tips
プレビュー
