運用課の蜂谷です。
昨年度までは営業企画を担当し、過去に一度だけ臨時ライターとして駆り出されて記憶力向上術に関する記事を投稿したことがありますが、エンジニアの一員としては今回が初投稿になります。
現在はIT資産管理を主な業務としており、セキュリティ対策として皆さまにもなじみ深いであろうパスワード生成・管理方法について私見をまとめてみます。
今年8月、日本の情報セキュリティ対策組織（CSIRT）として著名なJPCERTコーディネーションセンター（JPCERT/CC）からパスワード設定に関する新たな提案が公表されました。
その要旨は「パスワード管理の複雑さを嫌って単一のパスワードを使い回すぐらいなら、サービスごとに使い分けてもらうために、いっそ覚えやすいパスワードにしてもいいのではないか。ただし文字列は長めで」といったものだと解釈しています。
この提案によると、パスワードは12文字以上がいいのだそう。
英大文字・小文字、数字に一部記号も加えた94種の文字を使って生成可能な8文字のパスワードは約0.6京通り。
一方、使う文字を英大文字・小文字、数字の36種に絞っても、12文字のパスワードなら約473京通り、単純計算で実に800倍近い強度（パスワード計算コスト）になると考えられています。
そうはいっても、その12文字（以上）を構成するパーツ（文字列）が氏名や誕生日、住所、電話番号、郵便番号など個人情報の一部、あるいは123456、password、qwertyといったいわゆる「よくあるワード」のように、類推されやすいものだけではあまり意味がありません。
「覚えやすい」と「類推されやすい」は似て非なるものです。
では、類推されにくいことをある程度確保しながら、覚えやすい文字列にするにはどうすればいいでしょう。JPCERT/CCの提案では「ランダムなワードや好きなワードを複数個、英単語と日本語のローマ字表記とを交えながら構成」する例が掲載されていました。
私なら、大学時代に専攻していた「折り紙」と、200桁以上暗唱できる「円周率」と、最近ハマっているカメラとを組み合わせて、例えば
Origami3.14Nikon
みたいな感じでしょうか。
これなら一応、英大文字・小文字、数字に加え、1つだけですが記号（.）も使えて、自分の趣味に関することなので「覚えやすさ」と「文字列の長さ」はある程度確保できているかな、と思います。
利用するサービスによって、設定可能な文字数は異なりますが、さらにもう数語加えるとより良いのかもしれません。
ただ私は思いました。
これだと、パスワードそのものの覚えやすさは確保できているかもしれませんが、サービスごとに使い分ける上での覚えやすさという視点が抜けているので、この調子で10個もパスワードを作ってしまうと、いったいどのサービス用のパスワードかが分からなくなるのでは…と。
それと、サービスごとに制限の度合いが違いますが、使える限りはやはり記号も使ってパスワード強度を確保したいとも思いました。
そこで私は「自分だけが連想できるサービス関連ワード」もパスワードの一部に加えてみたり、日本語キーボードの利点を生かしたパスワード生成術も＋α（プラスアルファ）で取り入れてみたりすると、より幅が広がるのではと考えました。
いくつか例を挙げてみます。
まず「日本語キーボードの利点を生かした手法」というのは、ここでは「ローマ字入力モードの状態で、かな入力モードの作法により文字を打ち込む」ことを指します。
そしてこの反対、つまり、かな入力モードの状態で、ローマ字入力モードの作法により「NTT」と打つと「みかか」という文字列が表れることから、みかかはNTTを表すネットスラングとして古くから使われていたそうです。
こうして2つの入力モードを意図的に混ぜ込むキー入力法を、ここでは便宜的に「みかか」としますが、みかかの特徴として「実際に打ち込まれる文字列がランダムっぽくなる」点があり、これが古くから「覚えやすさと一見した複雑さ」を両立するパスワード生成術の1つとして使われているようです。
例えばAmazonのパスワードを生成するなら、ローマ字入力モードのまま、かな入力の要領で「あまぞん」とキーボードを打つと
3jc@y
というランダム（っぽい）文字列を得られます。期せずして「@」なんて記号も使えました。
ここでJPCERT/CCの提案、つまりは「単語を組み合わせて文字数を稼ぐ」という手法に立ち返り、例えば私がAmazonでよく買う（＝自分しか連想できない）製品名も数語組み合わせてみるとどうでしょう。
f[cby （ぱそこん）
t/o （かめら）
この2つも加えれば
3jc@yf[cbyt/o
という、何だかそれらしい文字列が出来上がります。
これなら「パスワードとしての覚えやすさ」「ある程度の長さによる強度」に加えて「使い分ける際の思い出しやすさ」「多様な文字種の使用による強度」もある程度確保できているのでは、なんて思っています。
もちろん、パスワードに使用できる記号はサービスによってまちまちなので、上記例の「@」「[」「/」といった文字が使えない、というケースもあると思います。
そういう場合は、当然強度は劣るでしょうが、単純にかな入力の作法では記号となってしまう部分だけ、例えばShiftキーを押しながらローマ字入力の作法を適用して
3jZOy （あまゾん）
PAcby （パそこん）
tMEo （かメら）
みたいに文字列を生成してみるのもいいかもしれません。
そんなわけで、JPCERT/CCの提案にみかかの手法も取り入れると、パスワード生成に適した条件を満たしつつ、検討する幅も広がることが確認できました。
ただこれも古くからの「よくある手法」の1つなので、みかか変換された後の（ランダムっぽい）語句も、パスワード攻撃用の辞書に含まれている可能性はあり、絶対に安全だと言い切れるものではないことも付け加えておきます。
私ならもう一ひねり加えて、例えばサービス名の「Amazon」を独自に言い換えた上でみかか変換して
d@'yh@. （じゃんぐる）
^@c@r （べぞす）
など、より類推されにくいものを検討するかな。
こうして「破られにくいパスワード」を検討することは、ちょっとした脳トレというか、発想力を鍛えることにもなり、記憶力向上にも通じるところがあると思います（ここで伏線回収笑）。
それと最後に。
JPCERT/CCの提案からも読み取れることなのですが、実は最近のサービスのほとんどは「パスワードをお忘れの方はこちら」といった感じで、パスワード再設定の仕組みが用意されているため、覚えやすさを優先するあまり類推されやすくなるぐらいなら、いっそのこと、パスワードを覚えることすら放棄してしまっても（それぐらい複雑にしてしまっても）いいのかもしれません。
この記事が皆さまのパスワード再考の一助になれば幸いです。
