CookieHookey

パスワード管理術

Tech

テクノロジーがインフラ化した現代では､行政とのやりとりでも必然的にパスワードを設定する場面に出くわす｡ それ以外でも､大抵は､既に数多くのアカウントを持っていることだろう｡ つまり､ユーザーネームやパスワードといった認証情報を管理することは必須と言える｡ しかし､その肝心の管理方法は十分に広まっていない｡ ここでは､管理方法について考察してみる｡

TLDR

  • パスワード(PW)は､パスワードマネージャー(PWM)で管理する
  • PWMは専用のNativeアプリであり､オフライン前提で､オープンソースであること
  • 認証情報を強化する(PWMのPWはパスフレーズで管理する)

PWは､PWMで管理する

PWMを用いる理由は､PWM以外の管理方法では､毎回の入力が面倒と感じ､大抵は簡単なPWにしたくなるからだ｡ PWMであれば､自動入力であったり､コピペが可能なので､どんなPWでも作業は変わらない｡

PWMは､専用のNativeアプリ､オフライン前提､オープンソースであること

専用のNativeアプリを選択する

ブラウザなどのおまけのPWMを利用しない理由は､ブラウザをdependencyとしている以上､セキュリティが第一で開発されていないからだ｡ そのため､ブラウザ側のセキュリティ第一ではない意思決定の影響を受け得る｡

オフライン前提

Webアプリ(クラウド型)を利用しない理由は､大切だと言っている情報をわざわざwebにアップロードする意味がないからだ｡ 暗号化されていようが､攻撃の対象になりうることは変わらない｡

デバイス間で共有したいならば､ローカル環境で､syncthingやnextcloudなどのファイルを共有する専用のソフトを使えば良い｡ セキュリティを考えた時に､公開サーバーや､自分が管理していないストレージにわざわざデータを保存する必要はない｡

オープンソースであること

中身がわからないものをパッケージの文言だけで判断できるだろうか｡ 安全と書いてあれば､安全なのか｡ 中身を見て判断するできるべきだ｡ オフライン前提というところにも関わるが､いつのまにかネットと通信しているアプリは結構多い｡ 中身を担保するためには､オープンソースしかないだろう｡

認証情報を強化する

PWMに登録する認証情報を強化する

PW

PWMで､記号や､大文字･小文字､数字を含めたできるだけ桁数･文字数の多いPWを自動でランダムで作成する｡ 詳細は､この後出てくる"屈強なPWとは"を参照｡

解読にかかるコストは､password entropyと言われ､bitという単位で表される｡ 48bitsより､70bitsの方が解読にかかるコストは高くなる｡ 例えば､Password-Entropy-Calculatorで計算できるが､実際に使うPWは入力しないでおこう｡

メールアドレス

認証情報には､PW以外にも､メールアドレスが使われることが多い｡ その場合､aliasを用いてアカウントごとに違うメールアドレスを設定する｡

PWM用のPWを強化する

屈強なPWとは

PWM自体のPWは別途管理する必要がある｡ 端的に言えば､PWM用のPWを設定して､覚え､バックアップ用に紙に書いて保管する｡

まず､屈強なPWとは何か｡ 単純化すれば､桁数(文字数)である｡ なるほど記号や大文字･小文字､数字を含めれば解読されにくくなるが､桁数を増やした方がより簡単に計算量を増やすことができる｡ パスワード長と解読時間の関係を見ると､記号を増やすより数桁でも増やしたほうが解読に時間がかかることがわかるだろう｡

一方で､長いPWほど覚えにくくなるわけだが､PWではなくパスフレーズを用いれば対応できる｡ trimmer.proactive.tummy.tacky.tweet.crushingといったような単語の羅列がパスフレーズである｡ 単語のリストを用いて､ランダムに作成することが望ましい｡

PWM用のパスフレーズの決め方

パスフレーズを､オンラインで自動で決めてくれるサービスもある(ppgen.cgi)｡ ただ､コンピューター上で行うものは､すべて計算可能な変数であるため､ランダムとは言い難い｡ 本当にランダムという意味では､コンピューター上で扱えない変数をプロセスに組み込むべきである｡

手順

  1. サイコロを5個振り､5桁の番号を定める｡
  2. 単語リストからその5桁の番号に対応する単語をピックアップする｡ 例えば､サイコロの目が､ 16363 ならば､単語は enka(演歌) となる｡
  3. 1と2をを繰り返し単語を繋げる｡ 区切り文字として､"-“や”.“を用いてもいいし､そのまま繋げても良い｡ 文字数が多い方が解読はしにくくなるため､6~8単語くらいは繋げた方がいい｡
  4. 生成されたPWを紙にメモする｡覚えた後は､黒ヤギさんに頼んで､金庫に入れて保管してもらう｡

ランダムにするために､手順1､もしくは2をコンピューター以外で行う｡つまり､

  • 実際にサイコロを振って数字を算出する｡
  • 手持ちの国語辞典､英語辞典などから単語を抽出する｡

より強化する

パスフレーズを変換する

先程､PWM用のPW例として出したパスフレーズtrimmer.proactive.tummy.tacky.tweet.crushingは､単語の羅列なので､記号などを含めたPWよりは解読されやすい｡ 何らかのプログラムで変換したものをPWとして用いれば､多少は解読にも手間をかけられそうだ｡

$ openssl passwd -6 -salt pw-for-pwm 
Password: # プロンプトにPWを入力: trimmer.proactive.tummy.tacky.tweet.crushing
$6$pw-for-pwm$QQrI3/9U0HqpgZAW.2WfAmkmCqUz9Zr/rp1g0V3zpTUUX0pQksqJtnEPaIZsNKJmRGkL/kOOG8qiVmsNfWDLf.

多要素認証を取り入れる｡

PWMの解錠に際して､今の所PWさえ合えばわかれば解錠できる状態だろう｡

認証には､知識要素と､所有要素､生体要素がある｡ PWは知識要素に分類される｡ 知識要素以外の､所有要素(ハードウェアトークン･キー)などを取り入れることが解読をより困難にさせる｡

その他

留意点

オフラインだとしても､PWMのデータベースが暗号化されるようにした方が良い｡ 専用のPWMであれば､大抵は､暗号化されるはず｡ 持ち運ぶデバイスでなければ､FDEでディスクごと暗号化でも良いだろう｡

また､オフラインであるため､特にデバイス間で共有していない場合は､別途データベースのバックアップ手段を考えておく必要がある｡ その点､statelessのPWM(lesspassとか)であれば､バックアップを気にする必要はないだろう｡

アカウントを作成しない

ここまでで､PWの管理術は伝えられたと思う｡ 管理術云々もあるが､管理するものが少ないほうが､管理も楽というものだ｡

特にオンライン環境にあるWebサービス上のアカウントは､個人情報の集積地になるし､攻撃の対象にもなり得る｡ いざという時､例えばアカウントがクラックされた後､短時間に認証情報を変更できるだけのアカウント数にしておくといい｡

200個のアカウントがあり､1つあたり変更に10分かかったとすると､ぶっ続けで作業して33時間かかる｡ 1アカウントあたり5分だとしても16時間はかかる｡ 他にやることがあれば､変更には1週間位かかるのではないか｡ 時間が経つほど､悪用される可能性は高まる｡

今は昔のPW管理方法

PWMを使う前は､言語学の接辞を応用し､PWを以下のように3つのパートに分けていた｡

  • prefix: サイトなどの名称
  • stem: 自分で決めたPW
  • suffix: 更新日時などの都度更新していくメタ情報

例えば､googleのアカウントを作成するときは､prefixをgoogleとする｡ stemは､password123など､自分で作ったPW｡ suffixは､3ヶ月毎に､その月の第4週の日曜日に変更するとすれば､0122とか､januarytwentytwoとか｡

すると､生成されるPWは､googlepassword123januarytwentytwoとなる｡ 使うサービスごとにprefixは変更し､時間経過とともにsuffixを更新していた｡

ただ､このPWは単純であり､またサービス側の文字数制限があるため､うまく当てはめられないことがある｡ それに､コンピューター上で管理するのであれば､この方法をあえて取るより､パスフレーズだけ覚え､後はそこからPWを算出するなり､PWMにアクセスするなりした方が､強いPWを扱うことができる｡