【セキュリティ対策】パスワード管理について８つの自分ルールを作った【2014年用】

最近はブルートフォースアタックやリバースブルートフォース攻撃など、パスワードの脆弱性をついた攻撃が多いですね。僕個人も、Apple Account、Google Accountに対してパスワードを試すログなどが記録されています（海外や国内からも）

Web関連の仕事に従事する一人の人間として、個人で管理するパスワードについて改めて考えてみました。あくまで自分ルールなので、参考までに。また、「こうしたほうがいいよ」的なアイデアがあれば教えて下さい。本ルールをもとに、もう少し厳しくしたものを、経営するスタートアップ企業のセキュリティガイドラインの中に加えたいと思います。

パスワード設定規約　自分ルール（個人／2014年版）

(1) ルール及びパスワードの見直しの期日

このルール及びパスワードは、自分の誕生日（2/16）に、その年を取り巻いているセキュリティ環境などを鑑みて、全面的に見直すものとします。加えて、一般的な四半期の始まり（年4回、1/1・4/1・7/1・10/1）に、パスワード自体を全面的に見直す日と定めました。

(2) 個人パスワードのセキュリティグループの書き出し

パスワードは全てサービスごとに別々に設定するべき、という声がありますが、現実的には難しいですよね。そこで、自分のライフスタイルに合わせた７種類程度のセキュリティグループ を用意するという考え方を取り入れました。

まず最初の手順として 1.「自分がつかっているWebサービスをすべて書き出す」という作業をします。次に、不要なサービスは退会して、今後も継続するサービスについて、どの程度のセキュリティガイドラインを考えるべきか、書き出していきます。

ここでは、パスワードの個人ルールを考察するので、法人におけるセキュリティ管理は、まったく別の話題として割愛します。※ 個人情報保護法で定められている5,000人基準による、個人情報取り扱い事業者になっている場合は、これらの数倍規模のガイドラインを用意しておくべきです。

例えばこんな感じになります。もっと具体的なサービス名称を、6〜8分類したりしてみてください。

• 【金融】個人の金融機関、証券会社、クレジットカード情報など
• 【プラットフォーム】Google、Apple、Dropbox、Twitter、Facebookなど、Oath認証で用いているプラットフォームサービスなど
  （上記２項は、後述する (5) 【ストロング】に値するパスワードで、全てのサービスでパスワードを分けて管理する）
  
• 【EC】Amazon、楽天、その他のECサイトなど購買情報に紐づくアカウント
• 【SNS】認証を行わないTwitterのサブアカウントや、その他どうでもいいSNS系サービスアカウント
• 【インフラ】仮想サーバーとのSSH通信（ポート／IPアドレスによるファイアウォール設定した上で）のパスワード基準
• 【その他】上記に当てはまらない一般的なパスワードを求められる際の基準
• 【ゴミ】一度しかつかわない、試しに登録するだけのWebサービスのパスワードなど

(3) 【ベーシックフレーズ】（最低レベル）

上記で列挙した中で、【ゴミ】以外のセキュリティグループに対して、外部のWebサービスなどに登録するパスワードの最低基準（ベーシック）として「８桁英数字の乱数（大文字・小文字混在）」を用います。

パスワードを、大文字小文字の英数字８桁乱数にすることで、

• 数字 → 0,1,2,3,4,5,6,7,8,9 ＝ 10通り
• アルファベット→ A～Z, a～z ＝26*2 通り

となり、組み合わせの数は

= (10+(26*2))^8=62^8 = 218,340,105,584,896 

約 218兆通りとなります。より専門的なブルートフォースアタックを除き、人為的な悪意によるパスワードの脆弱性に耐えることができます。

例：dj79AjhX

乱数のパスフレーズは、Rubyのワンライナーを作って書いています。これで気に入ったフレーズを見つけて決めてしまいます。

[参考] Ruby（irbなど）にて８桁英数字混合の乱数を生成するワンライナー。

(("a".."z").to_a + ("A".."Z").to_a + (0..9).to_a).shuffle[0..7].join

(4)【ウルトラ・ライト】（やむを得ない場合）

　残念ながら、まだ一部のWebサービスでは、そもそもパスワード入力欄に４桁ないし６桁までしか対応していないサービス、あるいは数字のみのパスワードも存在しています。その場合、上から優先度順に、

• そのWebサービスを利用しない
• 機密性の高い情報、決済管理情報、社内及び社外（個人情報含む）の情報を保持しない
• そのWebサービス専用でパスワードを管理する

の順で優先度で採用します。管理するパスワードのフレーズは、6桁英数字の乱数か、そのサービスが定めるパスワードの最高基準を満たすものを採用します。

ANAマイレージ管理などは未だに４桁の数字のみという非常に脆弱性のあるWebサービスなので、早く対応してほしいものです。つい最近も話題になったリバースブルートフォース攻撃（パスワードを固定して、IDを任意のものに切り替えていく辞書攻撃）に耐えられるように、最も自分と縁がない数字の配列などを用いて、なるべくIDがもれないような工夫が必要です。

(5)【ストロング】（自分で入力する金融機関、キーチェーン、iCloud、Googleなど）

金融機関、Macのパスワード、キーチェーン、iCloud、Google、Facebookなどのパスワードは、英数字（大文字・小文字を含む）混合 12 桁乱数 を用います。英数字混合の乱数12桁は、5種類程度までのパスワードが僕個人が覚えられるギリギリのラインであり、それを覚えるために30分間、暗記のレッスンをする価値はあります。

例：z54nfx2BlPDd

【参考】Ruby（irbなど）にて12桁英数字混合の乱数を生成するワンライナー

((“a”..”z”).to_a + (“A”..”Z”).to_a + (0..9).to_a).shuffle[0..11].join

(6)【セキュア・ストロング】（アプリケーションに設定するデータベース接続情報など）

人の手による頻繁な入力が不要であり、アプリケーション内に記述するデータベースの接続情報などは、英数字（大文字・小文字を含む）に記号を加えた、16 桁乱数 を用います。このパスフレーズの組み合わせは、「兆」の次のケタ（京など）になるため、2014年現在のコンピューターであれば数年〜数十年以上がかかります。ここまで来ると、そのパスワードの設定ファイル自体が漏れない工夫（インフラのファイヤウォールやパーミッションなど）のほうが重要です。

例：Q$8eZik~n5P#!lCt

現代においては、16桁の記号含む乱数でも決してセキュアとはいえないかもしれませんが、「あくまで個人の日常生活レベル」を基準としてセキュア・ストロングと名づけました。専門家の方のご指摘があれば修正します。

(7) パスワードの保管方法　その１

基本的には 12ケタ乱数 ☓ 8種類程度までは、脳内保管です。そのために1つのパスワードを覚えるために、それぞれ15回は復唱し、タイピングし、または紙に筆記してシュレッダーにかけます。2〜3時間くらいかかるかもしれませんが、頑張って覚えています。12ケタ乱数を覚える練習をすれば、【ベーシック】の8ケタ乱数は非常に簡単に覚えられる事がわかります。

自宅内にアナログで保管する場合などは、自分しか知らないような情報をもとにした「謎探し」「暗号解き」のようにして保管方法を作ると、楽しみながらパスワード管理ができるのでお勧めです。また必ず分割します。

(7) パスワードの保管方法　その２

とりあえず12ケタ乱数、8ケタ乱数などで20種類くらいに膨れ上がったパスワード群は、忘れてしまうリスクもかなり高いです。そこでルール化した方法としては、最後の砦として「実家に送る」でした。自分の手元には、サービスごとにID化（数字）しておくだけの情報を、秘匿して管理しておきます。そして実家には、サービスID（数字）とパスフレーズの対応表を、アナログで保管してもらいます。なんだか公開鍵認証方式のようですね（違うけど気分的に）。

忘れたときは親に電話して、「あっオレオレ、オレだけどさ、ID “8” のパスワードを、右から順番に読み上げてもられる？大文字のときはそう言ってね。」などと聞いたりして、完全に失念した際に、最終的に思い出すことができます。

(8) 二段階認証の採用

二段階認証を使っていない人は、今日にでも採用するべきです。僕のケースでは、以下のサービスで二段階認証を導入しています。自分のiPhoneのSMSに届いたり、Google Authenticatorなどのアプリを利用しています。

• 全ての金融機関（標準でついてくるワンタイムキー機能など）
• au ID
• GitHub
• AWS
• Googleアカウント全て
• Apple ID
• Dropbox
• Facebook

Google Authenticator – Google, Inc.

とりあえず、こんな感じでしょうか。セキュリティ系の記事を流し読みするだけでなくて、自分なりに様々なケースを想定し、「思考」して、実際の行動としてパスワードのガイドライン＆乱数パスフレーズを作って、ちゃんとドキュメント化しておくことが大事だと思いました。（実際に作成したドキュメントから、要約・抜粋したものが、こちらのブログ記事になります）

Author: @mocchicc(Twitter)  / Hiroyuki Tsuruda(Google+)