「マイクロソフト系技術情報 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。
目次 †
概要 †
- 暗号化
- 秘密鍵・暗号化
- 公開鍵・暗号化
- ハイブリッド・暗号化
などがある。
デジタル証明書、デジタル署名の仕組みを使用してセキュリティを実現する。
その他 †
パスワードを格納する方式 †
WebサイトのForms認証などを実装する場合、ハッシュのみ保管が一般的である。
ハッシュのみ保管 †
- パスワードのハッシュのみ保存する方式では、前に述べたように「キーなし方式」の場合、
辞書攻撃（オフライン辞書攻撃、オフライン総当たり攻撃、レインボーテーブル）により、
容易にパスワードが割れる可能性があるので、「キーあり方式」を使用したり、ソルト、ストレッチングを変更する。
- なお、パスワードのハッシュのみ保存する方式では、
ユーザから送信される暗号化されたパスワードは、一度、平文に戻す必要がある。
このため、本方式と、「チャレンジ＆レスポンス」方式は併用できない。
- デメリット
パスワードを保存していないため、
- パスワードリマインダを実装できない。
- パスワードの保存方法の変更が難しくなる。
（次回認証時のパスワード入力を待って変更することは可能）
暗号化して保管 †
パスワードを暗号化して保存する方式としては、「秘密鍵・暗号化方式」と「公開鍵・暗号化方式」があるが、
ユーザは不特定多数でなく、サーバ機能上で暗号化・復号化を行うだけであるため、「秘密鍵・暗号化方式」を使用する。
参考 †
ハッシュとソルト、ストレッチングを正しく理解する：本当は怖いパスワードの話 - ＠IT
http://www.atmarkit.co.jp/ait/articles/1110/06/news154.html
- 暗号学的ハッシュ関数の「不可逆性」「衝突困難性」を利用する。
- パスワードの代わりハッシュ値を保存すると鍵管理の煩わしさがない。
- ベストプラクティスはソルト＋ハッシュ＋ストレッチング
- ストレッチング
高速なハッシュを繰り返し用いることで速度を遅くする。
- ソルト
同じパスワードでも、ユーザーごとに異なるソルトを使い異なるハッシュ値にできる。
- レインボーテーブル探索を妨害する。
- ソルトはハッシュ値とともに保存する。
ネットワークへパスワードを流す方式 †
セキュアな認証基盤では、ネットワーク上に流すパスワードは、平文以外で流す必要がある。
パスワードを平文以外でネットワーク上に流す方式として以下の方式が考えられる。
以下、それぞれの方式の詳細について説明する。
HTTPS †
- 平文で送信される基本認証、Forms認証のユーザアカウントの暗号化
- HTTPSは、共通鍵が通信セッション 毎に可変となるため、リプレイ攻撃 に対しても対処できる。
チャレンジ＆レスポンス †
「暗号学的ハッシュ関数」（キーなし方式）では、リプレイ攻撃の対象となり得るため、
チャレンジ＆レスポンス方式では、
- チャレンジ（認証する側が認証される側に送信する乱数とID）と、
- 「暗号学的ハッシュ関数」（キーあり方式）
を使用してパスワードをハッシュ化してネットワーク上に流す。
- NTLM認証などが、チャレンジ＆レスポンス認証の方式を採用している。
- 可変のハッシュ（レスポンス）を元に認証処理を遂行するため、
認証基盤側は、ユーザ アカウント（パスワード）を平文で保持している必要がある。
公開鍵・暗号化 †
.NETにて提供されるRSACryptoServiceProvider?を使用した「公開鍵・暗号化方式」では、
同じ公開鍵を使用しても暗号化情報は可変になるが、同じ秘密鍵で復号化可能であることが確認できる。
このため、結局、リプレイ攻撃の対象となり得る。
このため、「公開鍵・暗号化方式」を使用してパスワードを暗号化してネットワーク上に流す場合、
元となるメッセージにチャレンジを加え暗号化するなどの実装を追加する必要がある。
ネットワークへ認証チケットを流す方式 †
Tags: :セキュリティ, :暗号化, :証明書
![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
