ストレッチング ハッシュで医療情報を守る実践的手法

ストレッチングとハッシュで医療情報を守る

ハッシュ化したパスワードは、1万回ストレッチングしても予算100億円の攻撃者には10桁以下なら解読されます。 learningbox(https://learningbox.online/column/hash_stretch_salt/)

ストレッチング ハッシュとは何か：基本の仕組みを理解する

「ストレッチング（Stretching）」とは、パスワードをハッシュ化する際に、1回で終わらせずに出力されたハッシュ値を再びハッシュ関数に入力し、その操作を何千〜何万回と繰り返す処理のことです。 日本語に直訳すると「引き伸ばし」であり、計算時間を意図的に引き伸ばすことで攻撃コストを高めるのが目的です。 tex2e.github(https://tex2e.github.io/blog/crypto/hashed-password)

つまり「時間を武器にする」発想です。

数字8桁のパスワードは、ストレッチングなしであれば高性能PCで約1秒で総当たり突破されます。 1,024回のストレッチングを施せば、この1秒が1,024秒（約17分）に延びます。さらに1万回にすれば1日かかる計算が約27年分の計算量に膨らみます。 医療情報システムにアクセスするためのパスワードは、まさにこの「時間稼ぎ」によって守られています。 jnsa(https://www.jnsa.org/aboutus/jnsaml/ml-29.html)

ハッシュ化そのものは「元に戻せない一方向変換」です。 たとえば「password123」というパスワードを SHA-256 でハッシュ化すると固定長の文字列に変換され、その文字列からは元のパスワードを直接復元できません。しかしハッシュ値さえ手に入れれば、攻撃者はあらゆるパスワード候補をハッシュ化して比較する「総当たり攻撃（ブルートフォース）」が可能です。 ストレッチングはその1回あたりの比較コストを数千〜数万倍に引き上げることで、攻撃を現実的でない規模に押し上げます。 tex2e.github(https://tex2e.github.io/blog/crypto/hashed-password)

条件	8桁数字パスワードの突破時間（目安）
ハッシュ化なし（平文）	即時
SHA-256（1回）	約1秒
ストレッチング1,024回	約17分
ストレッチング1万回	約27年相当

これが基本原則です。 jnsa(https://www.jnsa.org/aboutus/jnsaml/ml-29.html)

ストレッチング ハッシュとソルトの違いと組み合わせ方

ストレッチングと混同されやすいのが「ソルト（Salt）」です。ソルトはパスワードに付加するランダムな文字列であり、同じパスワードでも異なるハッシュ値が生成されるようにする仕組みです。 ストレッチングとソルトはそれぞれ別の攻撃に対応しています。 techmatrix.co(https://www.techmatrix.co.jp/product/appscan/column/check12.html)

ソルトが防ぐのは「レインボーテーブル攻撃」です。 レインボーテーブルとは、よくあるパスワードのハッシュ値をあらかじめ大量に計算してまとめた「逆引き辞書」で、ソルトがなければ一致検索で瞬時にパスワードが判明します。一方、ストレッチングが防ぐのはブルートフォース（総当たり）攻撃です。 両者を組み合わせることで、攻撃者はレインボーテーブルも使えず、かつ1件あたりの計算コストも高い状況に追い込まれます。 reddit(https://www.reddit.com/r/cryptography/comments/12khlyt/safest_way_to_salt_and_hash_a_password/)

医療情報システムでは、この2つは「セットで使う」が原則です。

厚生労働省が公表している医療機関向けサイバーセキュリティ対策チェックリスト（2025年度版）では、「強固なパスワード設定」が明確な要求事項として挙げられています。 単純なハッシュのみの実装は、このガイドラインへの適合とはみなされないリスクがあります。医療機関が不適切な認証実装を放置した場合、診療停止にまで追い込まれた事例も報告されています。 セキュリティ担当者として、ソルト＋ストレッチングの実装確認は定期的なチェックリストに含めることを強く推奨します。 gemmed.ghc-j(https://gemmed.ghc-j.com/?p=66866)

参考：厚生労働省が公表する2025年度版サイバーセキュリティ対策チェックリストの詳細は下記から確認できます。

医療機関のサイバーセキュリティ対策チェックリスト2025年度版の解説（GemMed）

ストレッチング ハッシュの推奨アルゴリズム：bcrypt・scrypt・Argon2の選び方

現在、OWASP（Open Web Application Security Project）が推奨するパスワードハッシュアルゴリズムは bcrypt・scrypt・Argon2 の3種類です。 これらはすべてストレッチングの概念を内包した設計になっており、繰り返し回数やメモリ使用量をパラメータとして調整できます。 psono(https://psono.com/ja/blog/evolution-of-password-hashing)

これは使えそうです。

| アルゴリズム | 特徴 | 適した場面 |
|---|---|---|
| bcrypt | 古くから実績あり・広い互換性 | 既存システムとの互換性が最優先の場合 |
| scrypt | メモリ消費量が大きく解析コストが高い | メモリ制約が少ないシステム |
| Argon2id | 並列クラッキング耐性・メモリ調整可能 | 新規構築する医療システムのデフォルト推奨 |

bcrypt は「コストファクター」と呼ばれる数値を設定することで、処理時間を調整できます。 コストファクターを1増やすごとに計算量は2倍になるため、ハードウェアの性能向上に合わせて定期的に値を引き上げることが重要です。 appmaster(https://appmaster.io/ja/blog/bcrypt-vs-argon2-pasuwadohatsushiyushe-ding)

Argon2id は2015年のPassword Hashing Competition（PHC）で最優秀賞を受賞した比較的新しいアルゴリズムです。 CPU時間だけでなくメモリ使用量もコストとして設定できるため、GPUを大量並列させた攻撃に対してより強力な抵抗力を発揮します。新規に医療情報システムを構築する場合、Argon2id を第一選択とし、互換性の理由で使えない場合に bcrypt を選ぶのが現在のベストプラクティスです。 psono(https://psono.com/ja/blog/evolution-of-password-hashing)

既存システムでまだ MD5 や SHA-1 のみでハッシュ化している場合、早急な移行が必要です。 MD5 は1996年に脆弱性が報告されており、現代のGPUでは数秒以内に大量のパスワードを解析できます。医療情報システムの認証部分にこれらが使われているか、ベンダーに確認することが第一歩です。 xtech.nikkei(https://xtech.nikkei.com/atcl/nxt/column/18/00138/040200261/?P=4)

ストレッチング ハッシュの実装でよくある医療現場の3つの落とし穴

医療現場で特に見られるミスは「ハッシュ化している＝安全」という思い込みです。意外ですね。

まず1つ目は「ストレッチング回数が少なすぎる」問題です。 一般的に推奨される回数は1万〜10万回ですが、古いシステムでは1,000回以下に設定されているケースがあります。10年前に設定した回数は、今のGPU性能では不十分になっている可能性があります。回数は「現在のハードウェアで攻撃者が現実的な時間内に解析を完了できないレベル」に設定し直す必要があります。 techmatrix.co(https://www.techmatrix.co.jp/product/appscan/column/check12.html)

2つ目は「ソルトを使い回す（固定ソルト）」問題です。ソルトはユーザーごとに異なるランダム値を自動生成させることが鉄則です。 固定ソルトを使うと、同じパスワードを持つ複数ユーザーのハッシュ値が一致してしまい、1件解読されると他の同一パスワードユーザーも芋づる式に特定されます。これは痛いですね。 appmaster(https://appmaster.io/ja/blog/bcrypt-vs-argon2-pasuwadohatsushiyushe-ding)

3つ目は「ログイン処理の高速化を優先しすぎる」落とし穴です。 ストレッチング回数を増やすと、ログイン処理にかかる時間も延びます。サーバー負荷を気にするあまり回数を下げすぎると、攻撃耐性が大幅に下がります。理想的には「ユーザー1人のログインに0.1〜0.5秒かかる程度」を目安に設定し、パフォーマンステストを行いながら最適値を探ることが推奨されます。 techmatrix.co(https://www.techmatrix.co.jp/product/appscan/column/check12.html)

• ✅ ストレッチング回数は1万回以上を目安に設定する




• ✅ ソルトはユーザーごとにライブラリが自動生成した値を使う




• ✅ bcrypt・Argon2id などの専用ライブラリを使い、手動実装は避ける




• ✅ ハードウェア性能の向上に合わせてパラメータを定期見直しする




• ✅ 既存システムの認証実装がMD5/SHA-1のみでないかベンダーに確認する

ストレッチング ハッシュを医療従事者視点で活かす独自の考え方

医療従事者がセキュリティ技術を「自分事」として捉えにくい理由のひとつは、「技術者が対応すべきこと」という切り離しにあります。しかし実際には、パスワード運用の現場ルールが実装の強度を左右することも多くあります。

たとえば、複数スタッフが同一アカウントを共用している医療現場では、ストレッチングや強固なハッシュを実装していても、パスワードが「password1」など単純なものであれば意味をなしません。 8文字以下の数字のみパスワードはストレッチング1万回でも、現代の高性能GPUを複数使った環境では最終的に解析されます。 技術的な対策と運用ルールは車の両輪です。 learningbox(https://learningbox.online/column/hash_stretch_salt/)

結論は「実装と運用の両方が必須」です。

また、医療情報システムのベンダー選定時に「パスワードはどのようにハッシュ化・ストレッチングしていますか？」と聞ける医療従事者は、サイバーセキュリティ事故のリスクを大きく下げる立場にあります。 2025年度版の厚生労働省チェックリストでは、医療機関側がシステムベンダーと協力して平時からの対策強化を求めており、担当者としての質問力そのものが防衛策になり得ます。 ardent(https://ardent.jp/rentoffice-consultation-center/security/iryou-cyber-security/)

ランサムウェアによる医療機関の診療停止被害は、国内でも実際に複数報告されています。 被害を受けた医療機関の多くは「認証管理の不備」が入り口になっています。ストレッチング＋ソルト＋強固なアルゴリズムという3点セットを理解し、ベンダーや情報システム部門への適切な問いかけに活かすことが、医療従事者としての現実的なセキュリティ貢献です。 ardent(https://ardent.jp/rentoffice-consultation-center/security/iryou-cyber-security/)

参考：医療機関向けのサイバーセキュリティ対策の全体像と具体的な対応策の確認は下記から。

医療機関におけるサイバーセキュリティ対策チェックリスト解説（Ardent）

参考：JNSA（日本ネットワークセキュリティ協会）によるストレッチングの効果と設定の考え方。

JNSAメールマガジン第29号：パスワードのハッシュ化とストレッチングの解説