・電子認証について のバックアップ(No.6)
- バックアップ一覧
- 差分 を表示
- 現在との差分 を表示
- ソース を表示
- ・電子認証について へ行く。
- 1 (2020-01-22 (水) 17:43:14)
- 2 (2020-01-23 (木) 14:22:12)
- 3 (2020-02-16 (日) 12:51:50)
- 4 (2020-03-08 (日) 15:42:47)
- 5 (2020-03-19 (木) 14:38:00)
- 6 (2020-07-16 (木) 10:54:18)
- 7 (2020-07-23 (木) 12:51:00)
- 8 (2020-07-24 (金) 16:01:20)
- 9 (2020-07-25 (土) 14:17:14)
- 10 (2020-07-29 (水) 11:25:05)
- 11 (2020-07-30 (木) 11:11:20)
- 12 (2020-07-30 (木) 13:18:09)
- 13 (2020-08-10 (月) 16:04:05)
- 14 (2020-08-11 (火) 11:27:24)
- 15 (2020-08-11 (火) 14:36:02)
情報システム開発契約のセキュリティ仕様作成のためのガイドライン(案)?
パスワードに関する技術的な動向と本ガイドラインの見解 †
パスワード認証に関するガイダンスは多数あり、さまざまな見解が公表されています。
タイトル | 桁数 | 辞書検査 | 複雑さ | 定期変更 | 使いまわし | 多要素 |
内閣サイバーセキュリティセンター インターネットの安心・安全ハンドブック | 10桁以上 | ー | 英大小数字記号 | 必要なし、流出時に速やかに変更 | 不可 | 推奨 |
総務省 国民のための情報セキュリティサイト | 適切な長さ | 推奨 | 英数 | 必要なし、流出時に速やかに変更 | 不可 | ー |
IPA 今、パスワードが危ない!チョコっとプラス パスワード | 8文字以上 | 推奨 | 英大小数字記号 | ー | 不可 | ー |
NIST SP800-63B Digital Identity Guidelines | 8文字以上 | 必須 | 不要 | 不要 | 不可 | システム特性に応じて必須 |
OWASP Application Security Verification Standard V4 | 12文字以上 | 必須 | 不要 | 不要 | 不可 | システム特性に応じて必須 |
国防総省 STIG Windows Server 2016 | 15 | 必須 | 英大小数字記号 | 60日以下 | 不可 | 必須 |
Microsoft Password Guidance | 8文字以上 | 必須 | 不要 | 不要 | 不可 | 必須 |
Google 強力なパスワードとより安全なアカウントを作成する | 8文字以上 | 推奨 | 許容 | ー | 不可 | ー |
NIST SP800-63B †
この中でも、米国国立標準技術研究所(NIST) の電子認証ガイドライン(SP800-63-3) は、影響力が強く、OWSP Application Security Verification Standard V4 はSP800-63-3に準拠済みで、クレジットカード業界のセキュリティ規格である PCIDSS も NIST の見解を反映させた新しいバージョンを2020年後半にリリースするとしており、今後、SP800-63-3 がデジタル認証の標準の地位を占めるものと考えられます。
SP800-63-3は、以下の特徴的な改訂を行っています。(以下、SHALL は必須要件、SHOULD は必須ではないが推奨要件、SHOULD NOT は必須ではないが非推奨要件を示します。)
- システムがランダムにパスワードを決定する場合最低6文字(SHALL)
- ユーザがパスワード決定する場合は8文字以上(SHALL)
- 以下の要件に該当するか比較し(SHALL)、その場合は、理由を説明し(SHALL)、他のパスワードへの変更を求める(SHALL)
- 過去に漏洩した語彙集から得られるパスワード
- 辞書に含まれる言葉
- 繰り返しまたはシーケンシャルな文字(例: 'aaaaaa'、 '1234abcd')
- サービス名や、ユーザ名、そこから派生するようなものなど、文脈で特定可能な単語
- 他の構成ルール(異なる文字種の組み合わせ等)を課すべきではない(SHOULD NOT)
- 定期的変更を求めるべきでない(SHOULD NOT)
- 危殆化した証拠がある場合は、変更を強制する(SHALL)
- パスワード強度メーターの推奨(SHOULD)
パスワードの長さについて †
NIST SP800-63 (2006/4版、邦訳:https://www.ipa.go.jp/files/000025342.pdf)では、ランダムな94文字種から作成した6桁のパスワードのエントロピー(ばらつき強度)を39.5bitと推定しています。また、ユーザーが選択した場合は、94文字種で、辞書規則(5万語の辞書に掲載されていない)と組み合わせ規則(繰り返しやqwerなどの連続性の排除)を適用した場合のエントロピーを30bitと推測しています。
一方で、ユーザーが規則の適用なしに自由に選んだ8文字のパスワードの場合、エントロピーは18bitと推測しています。このため、辞書やサービス名の使用を禁止したものと考えられます。
定期的変更は求めるべきでない(SHOULD NOT) †
2010年のノースカロライナ大学の研究で、無効な10,000を超えるアカウントから50,000個のパスワードを入手し分析したところ、調査したアカウントの17%について、ユーザーの以前のパスワードを知っていれば、5回以下で現在のパスワードを推測できることが報告されています。これは、定期変更が求められた際に、文字を数字や記号に換えたり、記号を追加したり削除し、似通ったものを新しいパスワードとして登録する人が多いことを示しており、ロックアウトの有効性が著しく下がることを意味します。オフライン攻撃の場合、攻撃者にとって定期変更は障壁ではなく、かえって安全性を損ねるものという判断がなされています。
Microsoft Security Baselines Blogの見解 †
Security baseline (FINAL) for Windows 10 v1903 and Windows Server v1903 で定期変更を推奨しない理由を以下のようにあげています。
- パスワードが盗まれていない場合は、パスワードを期限切れにする(定期変更の)必要はない。
- パスワードが盗まれた証拠がある場合は、有効期限が切れるのを待って問題を解決するのではなく、すぐに対処すべきである。
- 組織が禁止するパスワードリスト、多要素認証、パスワード推測攻撃の検出、および異常なログオン試行の検出を正常に実装した場合、定期的なパスワード有効期限は必要だろうか。
- 最新の緩和策を導入していない場合、パスワードの有効期限が切れることによって、どの程度の保護が得られるのだろうか。 https://techcommunity.microsoft.com/t5/microsoft-security-baselines/security-baseline-final-for-windows-10-v1903-and-windows-server/ba-p/701084
本ガイドラインの考え方 †
本ガイドラインでは、対象システムの特性に応じて認証強度を検討すべきとの立場から、以下を推奨します。
個人情報、機微情報、知財を取り扱うシステム、VPNなどのネットワーク境界接続での認証には多要素認証を求めるべき †
- バックオフィス系システム
- インターネット上のWebシステム
- クラウドの制御コンソール
- SSH接続のための踏み台サーバー (Bastion Server)、VPN
- 多要素認証の導入が困難な場合は、代替手段としてパスワードの漏洩のチェック、ロックアウト、ログオン試行の検出などを検討する
- 多要素認証は、ハードウェアトークン、ソフトウェアトークン(Authenticator)、メール、SMS による One Time Token などを検討すべき
- デスクトップアプリケーションは、取り扱う情報の性質に応じて、ライツマネジメントや暗号化を検討すべき
- 生体認証は確率的であり他人を認証する場合があることから、個人の所有が特定できる携帯電話、デバイス等との組み合わせを検討する
ID/パスワードの考え方 †
- 最低8桁とし、複雑さ、定期変更を求めない
- 複雑さを求めると推測しやすいパターンができる 例:先頭大文字のキーワード+数字+末尾記号
- 定期変更は求めないが、漏洩が発覚した際は即時に変更を求める
- 特定の文字列の繰り返し、回文は排除する 例:12341234、monkeyyeknom
- IDにメールアドレスを使用する場合や、個人を特定しやすいIDを使う場合、推測可能な生年月日や電話番号をもとにした攻撃が可能なため、英数のセットを要求すべき
- 5回以上連続して認証に失敗した場合は、一定期間、内部的にロックアウトを求めるか、パスワード変更を求める~この際、内部的にはロックアウトを実行しておくが、外部からの有効なIDの確認がなされないようにするため、「IDかパスワードが違うためログオンできません」などのメッセージを表示し、ログオンの試行は継続的に許可するなどを検討すべき
Windows グループポリシーでの例外 †
Windows のグループポリシー [コンピューターの構成]>[ポリシー]>[Windows の設定]>[セキュリティの設定]>[アカウントポリシー]>[パスワードのポリシー]及び[アカウントロックアウトのポリシー]については、以下を推奨するとともに、多要素認証の導入を強く推奨します。
多要素認証を導入しない場合の [パスワードのポリシー] †
- [パスワードの長さ] は15桁以上を推奨する
- [複雑さの要件を満たす必要があるパスワード] を有効にすることで SamAccountName、DisplayName を ID に含ませることができない事から、有効にする
- 定期的なセキュリティログ監査もしくはパスワードの漏洩・侵害検査の導入を前提に、[パスワードの有効期間]は[0日](定期変更を求めない)、[パスワードの履歴を記録する]は[0回](パスワードの履歴は求めない)とする
- ログ監査の対象Event ID
セキュリティログ Event ID:4625(アカウントがログオンに失敗しました)、Event ID:4776(資格情報の確認)
- ログ監査の対象Event ID
多要素を導入しない場合の [アカウント ロックアウトのポリシー] †
- [アカウントのロックアウトのしきい値] を[5回ログオンに失敗] とする
- [ロックアウト カウンターのリセット] を [15分後] とする
- [ロックアウト 期間] を [15分] とする
Windows Hello などの多要素認証を導入した場合 †
- PIN を使用する場合、6桁以上とする
- PIN の定期変更、履歴、複雑性は求めない、但し、個人から推測可能な誕生日、電話番号等の使用は認めず、これらを規程化する