All rights reserved.「情報セキュリティは、時間の経過とともに新たに登場する脅威によって変わる」と、ローリー・クレイナー氏は警告しています。サイバー攻撃者は「以前使っていたパスワードを元に推測しやすいパスワードに変える」ユーザーの習性を突いて、読み取った規則性に基づきパスワード・クラッキングを仕掛けてきます。2016年8月に米ラスベガスで開催されたセキュリティ会議で、連邦取引委員会チーフテクノロジストのローリー・クレイナー氏は、ある興味深いデータを公開しています。最も多かったのが、パスワードの末尾に数字を追加していく変更です。たとえば、＜abcdef＞というパスワードを使用していたユーザーは、90日後に＜abcdef1＞に、さらに90日後には＜abcdef2＞にシフトします。それ以外にも、パスワードの最初と最後の文字を入れ替えたり、同じキーワードを重ねるなど、対象ユーザーの大半が「自分が覚えやすい（つまり、容易に推測されやすい）わずかな変更」で対処していました。現在の『Google アカウントヘルプ』においても、「アカウントのセキュリティを強化する」手順の中に「パスワードの定期的な変更」を推奨する項目は見あたりません。欧米のセキュリティ専門家の間では、“パスワードの定期変更はセキュリティ上の効果がない”という見解が統一されているようです。それでは、どの程度のパスワード変更なら物理的な「安全」が確保されるのでしょうか。その意味では、オンラインサービスが行う「秘密の質問」などの二重のセキュリティサービスも、同じジレンマを抱えています。そこで問われる「好きな食べ物」などの質問は第三者に推測しやすく、「あなたの出生地は」などの質問はパスワードのヒントになりやすいため、NISTでは「パスワードを容易に推測される認証サービスは行うべきではない」と警告しています。これでは規則性が明確過ぎて、容易にパスワード・クラッキングを許してしまいます。実際に研究チームがパスワード解析ツールを使って調べたところ、変更されたパスワードの約40％が3秒以内に推測可能でした。しかも、サイバー攻撃者がパスワード・クラッキングに用いる解析ツールでは、4桁のパスワードなら10秒以内、6桁でも英文字だけなら1分以内にパスワードが解読できることが報告されています。ユーザーは「トラスト・ログイン」のマスターパスワードに「64文字に近づけたパスフレーズ」を設定するだけで、複数のオンラインサービスを利用できます。そして、トラスト・ログインで管理する各種クラウドサービスの認証にもパスフレーズを用いることで、強度を高めることが可能となります。ただ、現時点でクラウドサービスの多くはパスフレーズに対応していないため、注意が必要です。例えば、「文字数の長さに制限がある」場合や、「パスワード/パスフレーズにスペースを使うことを認めていない」場合などです。
nlab.itmedia.co.jp. Reading Time: 1 minutesパスワードは世界中で最も使用されている認証方法ですが、過去10年において、ITセキュリティの専門家は、ハッキングを防止するためのパスワードの管理の非効率さに悩まされているのが現状です。 今回は近年発表されたNIST提唱の新しいパスワードガイドラインをご … パスワードの最大長は、ユーザーがパスフレーズを作成できないように設定しすぎないようにしてください。 典型的な最大長は128文字です。 20文字未満のパスフレーズは、通常小文字のラテン文字のみで構成されていると弱いとみなされます。 もしUnicode文字が記憶シークレットとして許容されるならば、検証主体は、Unicode Standard Annex 15 [UAX 15] の Section 12.1で定義されている”Stablized Strings”を行うために、NFKCまたはNFKD正規化のどちらかを用いた正規化処理を適用すべきである(SHOULD)。検証主体は、最低8文字以上であることの検証に先立って、連続した複数のスペースまたは全てのスペースを除去してもよい(MAY)。もし選択したシークレットがリスト中に存在したら、加入者は、それが一般的に使われているため異なるシークレット値を選び直す必要があるということを知らされ、異なる値の選択を求められるものとする(SHALL)。記憶シークレットを選択する際、検証主体は加入者に対して特別なタイプの情報(例えば、あなたの最初のペットの名前はなんですか？といったもの)の入力を求めないものとする(SHALL)。ハッシュ認証器から分離されて記録される鍵(例:ハードウェアセキュリティモジュール中)を用いる鍵付ハッシュ関数(例:HMAC)は、記録済みハッシュ化認証器に対する辞書攻撃に対する更なる対抗方法として利用されるべきである(SHOULD)。例えば、以下のリスト(に限定するものではない)が含んでいるものでよい(MAY):Unicode文字を含む記憶シークレットを選択した加入者は、いくつかのエンドポイントでは異なって表現されるかもしれない文字があることを通知されるべきであり(SHOULD)、それが彼らが正しく認証を行うための能力に影響する可能性がある。この処理は記憶シークレットのバイト文字表現のハッシュ化に先立って適用される。記憶シークレット検証主体は、加入者に対して、未認証の申請者が簡単に手に入れることができる「ヒント」を記録しないものとする(SHALL NOT)。検証主体は、オフライン攻撃へ対策する形式で記憶シークレットを保存するものとする(SHALL)。検証主体は、攻撃者が加入者のアカウント乗っ取りのために試みた認証失敗の回数を有効に制限するスロットリングの仕組みSection 5.2.2を実装するものとする(SHALL)。検証主体は承認済み(approved)暗号化を利用するものとし(SHALL)、記憶シークレットを要求する際には、盗聴や中間者攻撃を防止する目的で保護された認証済みのチャネルを用いるものとする(SHALL)。検証主体は、認証器が侵害されている、または加入者が変更要求を行った証拠がない限りは、記憶シークレットを任意で(例えば、定期的に)変更するよう要求すべきではない(SHOULD NOT)。ソルト値は32ビット以上のランダム値で、承認済み(approved)の乱数生成器を用いて生成され、ハッシュ結果とともに記録される。少なくとも繰り返し10000回のハッシュ関数を適用すべきである(SHOULD)。シークレットは、 ソルト値と一緒に、例えば[SP800-132]で記載されているPBKDF2のような承認済み(approved)のハッシュを用いてハッシュ化されるものとする(SHALL)。記憶シークレットは、CSP(例えばエンロールメント時など)また検証主体(ユーザが新しいPINを要求した時など)によりランダムに決定されるもので、最低6文字であるものとし(SHALL)、承認済み(approved)乱数生成器を利用して生成されるものとする(SHALL)。申請者が記憶シークレットを正しく入力することを支援するために、検証主体は(典型的なドットやアスタリスク表示ではなく)シークレットを表示するオプションを提供すべき(SHOULD)である。Unicode[ISO/ISC 10646:2014]文字も同様に許容されるべきである(SHOULD)。検証主体は他の構成ルール(例えば、異なる文字種の組み合わせ)を記憶シークレットに課すべきではない(SHOULD NOT)。検証主体は、申告者が入力文字を確認するのに十分な時間表示したあとは、文字を非表示にするものとする(SHALL)。これにより、申請者は彼らのスクリーンが盗み見られている可能性が高くない場所にいるとき、自身で入力を検証することができる。検証主体はユーザが決定した記憶シークレットの場合は最低でも64文字とすべきである(SHOULD)。すべての印字可能なASCII [RFC 20] 文字(スペースも同様)は記憶シークレットとして許容されるべきである(SHOULD)。前述の長さ要求を満たす目的で、それぞれのUnicode符号位置は単一文字としてカウントされるものとする(SHALL)。記憶シークレットの設定、変更の要求を処理する際、検証主体はシークレットの値を、一般的に利用されている値、予想できる値、セキュリティ侵害を受けた値と比較するものとする(SHALL)。シークレット文字列の前後の切り詰めについては実施しないものとする(SHALL NOT)。