自社で作成しているサービスでユーザに対して、どれだけ高いパスワードレベルを要求する必要があるのかを考えたことはありませんか。

自社サービスのセキュリティにぜい弱性があったことから、ユーザのパスワードが流出するといった事件が世間では数多く起きていますが、ユーザが設定したパスワードの難易度があまりにも低すぎることで、悪意ある第三者のハッキングによって突破されたといった事例も多々みられます。

そういった被害を防ぐためには、ユーザがパスワードを設定する際に、登録できるパスワードレベルをサービス上で制限するといった対応が考えられます。

しかし、だからといってあまりにも高過ぎる難易度を設定してしまうと、ユーザがパスワード管理することも難しくなります。

そこで、本記事では、サービスにおけるパスワードレベルで最低限設定してほしいことと、+αについて述べていきたいと思います。

最低限設定してほしいパスワードレベル

世間一般でもよく言われる「英字(大文字、小文字区別有り)+数字の組み合わせで8ケタ以上」のパスワードでなければ、ユーザがパスワードを登録できないようにしましょう。

更に難易度を上げようとするなら、記号も含んだものにすることや最低ケタ数を増やすといった手段もあります。

ただし、記号も含んだパスワードは、「トラブルやサポートコストが増える」「パスワードを忘れてしまう」などの確率が他に比べて高い傾向にあります。

そのため、もし難易度を上げたいということなら、文字数を長くするほうがサービス提供側としては良いかもしれません。

表:パスワード難易度ごとの解析時間
使用文字 使用できる文字数 入力ケタ数
4ケタ 8ケタ 10ケタ 12ケタ
英字(大文字、小文字区別無し) 26字 0日 12日 22年 15*10^3年
英字(大文字、小文字区別) 52字 0日 8年 22*10^3年 61*10^6年
英字(大文字、小文字区別)+数字 62字 0日 34年 59*10^4年 51*10^7年
英字(大文字、小文字区別)+数字+記号 92字 0日 813年 68*10^5年 58*10^9年

(単位時間に行えるパスワード探索回数=100000)(小数点以下切り捨て)

パスワード総当りにより解析できる時間の平均値(解析時間L)

L = P*S/R = A^M/(2R)

  • P:パスワードが推定される確率
  • R:単位時間に行えるパスワード探索回数
  • S:ユニークなパスワード数

S = A^M

A:パスワードに使われる文字種類
M:パスワード文字数

(参考)パスワード評価ツール(アクセス:2018/07/10)

+αな設定 ~個人情報と似たパスワードの回避~

パスワードを登録する際には、おそらくそれと同時に名前やメールアドレス、生年月日などといった情報を入力してもらうということが多いのではないかと思います。

その場合、それらの入力文字と一致するような文字列が含まれていた場合、入力したパスワードが設定できないようにしましょう。

名前:田中 太郎
生年月日:1994年8月8日
パスワード:taro0808

+αな設定 ~連続文字パスワード禁止~

連続文字とはアルファベット順や数字順などといったものです。

その他にも、キーボードの横並びや縦並びになるようなものが当てはまります。

アルファベット:abcdefg
数字:12345678
キーボード:qwertyui(キーボード左上から横に8つ)

+αな設定 ~安易に定期的なパスワード変更を求めない~

以前はセキュリティを向上させるためには、パスワードを定期的に変更する必要があると考えられていましたが、現在では定期的なパスワード変更は不要というのが定説です。

滅多に使わないサービスで定期的な更新を促すと、元のパスワードを忘れている可能性がありますし、もっと言えば新しく設定したパスワードもすぐに忘れてしまう可能性があるため、ユーザは「覚えやすいパスワード」を登録してしまう可能性があります。

また、突破されていないパスワードにも関わらずパスワードを変更させてしまうと、ユーザのパスワード傾向を読み取ってしまうといった異なる危険が出て来ることも考えられるため、安易に変更を促すのはよくありません。

まとめ

これまで、サービス上でのパスワードレベルの設定についてご説明をしてきました。

パスワードレベルの設定に際しては、「zxcvbn」というオープンソースが役立ちます。

以下のページに「zxcvbn」とは何ぞやということが書かれています。

もし、ご興味がある方は、ぜひ、参考にしていただければと思います。

zxcvbn: realistic password strength estimation

自社サービスのパスワードレベル設定はどうすれば良いの?

Posted in パスワード

自社で作成しているサービスでユーザに対して、どれだけ高いパスワードレベルを要求する必要があるのかを考えたことはありませんか。

自社サービスのセキュリティにぜい弱性があったことから、ユーザのパスワードが流出するといった事件が世間では数多く起きていますが、ユーザが設定したパスワードの難易度があまりにも低すぎることで、悪意ある第三者のハッキングによって突破されたといった事例も多々みられます。

そういった被害を防ぐためには、ユーザがパスワードを設定する際に、登録できるパスワードレベルをサービス上で制限するといった対応が考えられます。

しかし、だからといってあまりにも高過ぎる難易度を設定してしまうと、ユーザがパスワード管理することも難しくなります。

そこで、本記事では、サービスにおけるパスワードレベルで最低限設定してほしいことと、+αについて述べていきたいと思います。

最低限設定してほしいパスワードレベル

世間一般でもよく言われる「英字(大文字、小文字区別有り)+数字の組み合わせで8ケタ以上」のパスワードでなければ、ユーザがパスワードを登録できないようにしましょう。

更に難易度を上げようとするなら、記号も含んだものにすることや最低ケタ数を増やすといった手段もあります。

ただし、記号も含んだパスワードは、「トラブルやサポートコストが増える」「パスワードを忘れてしまう」などの確率が他に比べて高い傾向にあります。

そのため、もし難易度を上げたいということなら、文字数を長くするほうがサービス提供側としては良いかもしれません。

表:パスワード難易度ごとの解析時間
使用文字 使用できる文字数 入力ケタ数
4ケタ 8ケタ 10ケタ 12ケタ
英字(大文字、小文字区別無し) 26字 0日 12日 22年 15*10^3年
英字(大文字、小文字区別) 52字 0日 8年 22*10^3年 61*10^6年
英字(大文字、小文字区別)+数字 62字 0日 34年 59*10^4年 51*10^7年
英字(大文字、小文字区別)+数字+記号 92字 0日 813年 68*10^5年 58*10^9年

(単位時間に行えるパスワード探索回数=100000)(小数点以下切り捨て)

パスワード総当りにより解析できる時間の平均値(解析時間L)

L = P*S/R = A^M/(2R)

  • P:パスワードが推定される確率
  • R:単位時間に行えるパスワード探索回数
  • S:ユニークなパスワード数

S = A^M

A:パスワードに使われる文字種類
M:パスワード文字数

(参考)パスワード評価ツール(アクセス:2018/07/10)

+αな設定 ~個人情報と似たパスワードの回避~

パスワードを登録する際には、おそらくそれと同時に名前やメールアドレス、生年月日などといった情報を入力してもらうということが多いのではないかと思います。

その場合、それらの入力文字と一致するような文字列が含まれていた場合、入力したパスワードが設定できないようにしましょう。

名前:田中 太郎
生年月日:1994年8月8日
パスワード:taro0808

+αな設定 ~連続文字パスワード禁止~

連続文字とはアルファベット順や数字順などといったものです。

その他にも、キーボードの横並びや縦並びになるようなものが当てはまります。

アルファベット:abcdefg
数字:12345678
キーボード:qwertyui(キーボード左上から横に8つ)

+αな設定 ~安易に定期的なパスワード変更を求めない~

以前はセキュリティを向上させるためには、パスワードを定期的に変更する必要があると考えられていましたが、現在では定期的なパスワード変更は不要というのが定説です。

滅多に使わないサービスで定期的な更新を促すと、元のパスワードを忘れている可能性がありますし、もっと言えば新しく設定したパスワードもすぐに忘れてしまう可能性があるため、ユーザは「覚えやすいパスワード」を登録してしまう可能性があります。

また、突破されていないパスワードにも関わらずパスワードを変更させてしまうと、ユーザのパスワード傾向を読み取ってしまうといった異なる危険が出て来ることも考えられるため、安易に変更を促すのはよくありません。

まとめ

これまで、サービス上でのパスワードレベルの設定についてご説明をしてきました。

パスワードレベルの設定に際しては、「zxcvbn」というオープンソースが役立ちます。

以下のページに「zxcvbn」とは何ぞやということが書かれています。

もし、ご興味がある方は、ぜひ、参考にしていただければと思います。

zxcvbn: realistic password strength estimation

Author: LRM株式会社
  • はてなブックマークに追加
  • ツイートする
  • facebookでシェアする
  • LINEでシェアする