パスワードにはうんざり。改善しましょう。

誰もが経験するあの瞬間。新しいサービスに登録し、パスワードを選んで入力する。でも、入れません。選んだパスワードは十分安全なはずなのに、使いたいサービスが独善的にそれを拒むのです。

記号、数字、大文字、小文字を少なくとも１つずつ使用しなければなりません。

小文字の長いパスワードの方がドルマークだらけの短いパスワードより安全だということを証明する、 XKCDの有名なコミック のことは忘れましょう。まず、あなたの主力パスワードが $$ICECREAM$$ だとします。アイスクリームは、恐ろしい人生の希望の灯火とも呼べるほどの大好物なので簡単に思い出せます。そして、このパスワードにはブートのための特殊文字が入っています。

残念なことに、 $$ICECREAM$$ には小文字と数字がないので、客観的に見れば安全ではありません。そこで、このサービスのためのパスワードを $$IceCream100$$ にしました。どのみち、このパスワードの方が安全なので、あなたは、これを新しい主力パスワードにしようと決めます。申し分のない1日ではないけれど、全体的には満足な日です。

パスワードに特殊文字は使用できません

さて、 $$IceCream100$$ は、しばらくの間は問題なく使えていましたが、6つの製品に使った後で、これが使えないものに遭遇しました。独善的なサービスです。そういうサービスはパスワードを拒絶することが多いのです。特殊文字を嫌い、数字を必要とすることもあるし、数字を嫌って特殊文字を要求することもあります。図を見てください。

*注釈：
Username：ユーザ名
Must be at least eight…：英字と数字をそれぞれ1つ以上含み、特殊文字を含まない8桁以上で指定してください。
available：利用できます
Confirm Password：パスワード確認
Password Strength：パスワード強度
Strong：強
Email：Eメールアドレス
Confirm Email：Eメールアドレス確認

プロのアドバイス：制約を加えて可能な組み合わせを減らすとパスワードが簡単に解読されるようになります。

では、この要求の細かいサービスのためにだけ、ドルマークを外して、代わりに IceCream100 を使うことにしましょう。古き良き時代に逆戻りです。問題は、次回ログインしようとしたときに、このシステムのパスワードポリシーが頑固だということをシステムが思い出させてくれないことです。あなたは、いつものパスワードを入力します。入れません。過去に使ったことのある他の組み合わせをいくつか試してみます。それでもだめです。またパスワードリセットのリンクボタンを使うときが来たのです。こうなったら、このボタンが基本的にあなたにとってのログインボタンなのです。

サービスは次に、数字を使ってはいけないと念を押してきます。私ならここで、怒りで左目がピクピクし始めるところです。喜ばしいことに、あなたの脳は以前と同じ思考回路をたどって以前のパスワードを思い出します。もう一度それを使ってもいいかも。再び IceCream100 とタイプして、送信ボタンをクリックします。

以前に使用したパスワードは使用できません

なんだって？　言葉も出ません。現実なのか？　こんなことが起こり得るのか？　まるで、あなたが国中のトイレの個室に行き当たりばったりに以前のパスワードを落書きして回っているとサービスの裏側の人たちが想像しているみたいです。そのうちの1人が信念を持ってこう言います。「解決策があります。私たちの登録システムに、とんでもない規則を追加しましょう。」

*注釈：
Reset your password：パスワードのリセット
You have requested…：パスワードのリセットを受け付けました。
Password is not…：パスワードが拒否されました。Adobe IDに独自の新しいパスワードを使用してください。
Your new password…：新しいパスワードは6桁以上を指定してください。

でも、実際にこんなことをする会社はありませんよね？

こういうわけで、 IceCream100 は、もう使えません。うんざりです。自分のいつものパスワードから全くかけ離れた組み合わせを使わなければなりません。さて、この、1つのサイトのパスワードは、少なくとも忘れてしまうまでの間は iceCREAM100 になりましたが、次のログインのときは、きっとこのパスワードを試すことはないでしょう。

*訳：
ヘルプ：パスワード規則一覧

1. パスワードは正確に8桁であること。
2. 英字、数字、特殊文字を少なくとも1つずつ含むこと。
3. 特殊文字は次のもののみ使用可能：@ # $
4. 特殊文字は先頭または末尾にあってはならない。
5. 隣り合う2つの同じ文字は「セット」と見なされる。「セット」は使用不可。
6. 自分の名前、ユーザID、会社名または雇用主などの名前は使用しないこと。
7. その他の使用できない単語は、Texas、childおよび、月の名前（January～December）である。
8. 新パスワードは旧パスワードに酷似してはならない。
   a. 例：旧パスワード－abc#1234、使用可能な新パスワード－acb$1243
   b. 1文字目、2文字目および3文字目は同一文字であってはならない。（abc****）
   c. 2文字目、3文字目および4文字目は同一文字であってはならない。（*bc#***）
   d. 6文字目、7文字目および8文字目は同一文字であってはならない。(*****234)
9. パスワードは15日に1回、自発的に（ヘルプデスクの援助なしで）変更することができる。必要な場合は、ヘルプデスクはいつでもパスワードをリセットすることができる。
10. 直前の8つのパスワードは再利用できない。*

ページの先頭へ戻る

パスワード地獄です。これは 世界で最悪のパスワード条件リスト（The Attorney General of Texas Child Supportのご厚意により転載） です。

ここでは、行く手を阻むパスワード規則の簡単な例を見ただけですが、あなたはすでに、頻繁に訪問する数多くの異なるサイトに $$ICECREAM$$ 、 $$IceCream100$$ 、 IceCream100 、 iceCREAM100 のどれかを使っていて、2日に1回はどれを使ったのか忘れてしまいます。開発者たちが、善かれと思って、それが役立つと考えているからというだけの理由で。

技術系ではない人々がパスワードの扱いをどうしているか分かりますか？　付箋に書いているんです。

なぜこうなるのか？

私が大学生のころ、どの課程でも先生たちは最初に基本原則を繰り返すように命じられていました。授業中にラップトップを開かないこと（授業以外のことに集中できなくなるように）、授業を4回以上欠席しないこと（欠席しすぎないように）、盗用しないこと（証拠がないから）、カンニングしないこと、遅刻しないこと、などなど。

こうした規則の絶え間ない繰り返しは、学生は自分たちの教育について個人責任を負っていないという基本思想に基づくものでした。放っておけば、彼らは確実に落第するのだ。新学期は毎回、この学校の、常に学生は子供扱いされるという文脈に沿った素っ気ないリマインダーで始まるのでした。

同じような思想が、オンラインパスワードセキュリティの根底にあります。ユーザは個人アカウントのセキュリティに責任を負わない。アプリケーションが責任を肩代わりしなければならない。多くのアプリケーションが現状に固執し、ユーザを子供扱いして、安易な手段をとっています。

リスクと報酬

「でもジョエル」と、あなたは画面に向かって抗議の叫びをあげているかもしれません。「複数のサービスに単一のパスワードを使うなんて恐ろしい考えだ。どれかのサービスがウィルス感染したらどうするんだ？」　そして、 それは正論です 。

銀行に使っているのと同じEメールアドレスとパスワードの組み合わせで新生スタートアップ製の新しいアプリに登録すれば、解読されるリスクがあります。出会い系アプリの新しいアカウントばかりではなく、お金を預けている場所もまた、危険にさらされることになるのです。そこのセキュリティがどれだけ優れていても。

もちろん、愚かなことではありますが、そのことが重要なのではありません。重要なのは、それが本人の決断だということです。おそらく本人にとって、1つのEメールアドレスとパスワードの組み合わせは、自分のアカウントが乗っ取られるリスクを冒してでも使いたいほど便利なのです。

ユーザには、自分の損得をはかりにかける権利があります。1PasswordやLastPassなどのパスワード管理ツールに頼ることになってもいいから、覚えにくい強力なパスワードを選ぶべきか？　いつでも電話を手元に置いておく必要があってもいいから、2要素認証に切り換えるべきか？

私は子供では ない ので、こういったサービスに子供扱いされて不便さを強制されるのは不快です。こういうことを、悪いユーザエクスペリエンスと呼ぶのです。

はっきりと反論させていただくなら、パスワードセキュリティについての記事を楽しんで書いている人々は一般のユーザとは全く違う、ということです。ましてや、一般市民とは比べものになりません。逆に、おばあちゃん（不幸にも、テクニカルな知識のないユーザの代名詞になってしまいました）は、守られなければなりません。おばあちゃんは、”password”が悪いパスワードだということを知っているとは限りません。

これが真実です。教育を受けていないユーザは、悪いパスワードのもたらす結果も、良いパスワードの成功事例も理解できないかも知れません。でも、これを解決する方法は、他にもあります。

改善する

では、設計者や開発者として、やるべきことは何でしょう？　アプリケーションの登録プロセスを開発しているとしましょう。ユーザを思いやれば、アカウントが乗っ取られるような恐ろしい経験をさせたくありません。ユーザが愚かなことをしないようにするには、どうすればいいでしょうか。

真実は、あなたにはそれを阻止することはできない、という酷なものです。パスワードは、総当たり攻撃、フィッシング詐欺、推測、それに古典的な（そして最も危険な）盗み見に遭いやすいのです。考えられる限りで最も複雑なパスワードを使うように強制したとしても、ユーザはそれを付箋に書いてモニタに貼り付けるだけでしょう。パスワードを覚えにくくすればするほど、こういう事態に陥る可能性が高くなります。

繰り返しますが、複雑さの層を重ねることは必ずしもユーザの助けにならないばかりか、あなたのサービスを使う彼らのユーザエクスペリエンスを 間違いなく 傷つけるのです。

ユーザビリティを犠牲にしたセキュリティはセキュリティを犠牲にする — Avi Douglen

あなたが開発者なら、バックエンドを保護することに尽力しましょう。パスワードをハッシュしてソルトし、データベースをセキュアに維持し、スロットリングを実装し、ジオロケーションの変化をチェックし、アプリケーションで2要素認証が使えるようにする各種機構を提供し、強固なパスワード修復システムを確保しましょう。パスワードの決定はユーザに任せましょう。

結局はユーザはシステムのセキュリティの単なる弱点以上のものであるということを忘れてはなりません。 サービスはユーザの ために 存在するのであって、ユーザをよそにして存在するのではありません。 ユーザの手を煩わせることなく、また、私たちの製品を使うユーザエクスペリエンスに悪影響を与えずに、人々が強力なパスワードを使えるようになる方法があると思います。そのような方法を探ってみましょう。

2要素認証の構築と推奨

2要素認証システムをセットアップする際には、ユーザの持っているシステムと確実に統合するように注意を払いましょう。ユーザのほとんどがGoogle Authenticatorを持っているとは期待できません。そうではなく、どのように認証したいのか、つまりEメールか、携帯メールか、Duoか、伝書鳩か、ユーザに方法を選ばせるのです。ユーザが手軽にセキュリティを確保できるようにして、その後ユーザが理解できる方法でメッセージを送ります。

アプリの新規ユーザがサービスに慣れる過程で、つまり、登録中かアプリを使用して数日たってから、パスワードを変更するように勧めるのです。

*注釈：
Hey,want to…アカウントのセキュリティを高めたいですか？
If some getshold…誰かがあなたのパスワードを入手したら、あなたのアカウントを盗むことができます。
あなたの電話番号を追加することで、私たちはそれを食い止めることができます！
Mobile phone #…モバイル電話番号
Learn more…詳しい内容を知る
Make my account bulletproof!…アカウントを防弾仕様に！

ユーザが2要素認証の有効性を理解しやすいようにするのです。ユーザが分かる言葉で話しかけます。もし、あまりに使いにくい時は、簡単にやめられるようにします。

Slackのログインプロセスは、ユーザが理由を理解できるような言葉を使った認証の枠組みの素晴らしい例です。Slackでは”Magic Link”というものを呼び出すことで、ログインプロセスを取り除いています。厳密に言うとこのシステムは”2要素”ではありませんが、ユーザはパスワードかMagic Linkのどちらかを利用することができます。これはセキュリティが低下するという点で議論の余地があるかもしれませんが、2要素認証のような”技術的”なものを、ユーザフレンドリーな方法にどのように再構成できるかを示す優れた例です。

注釈：
（左枠）
Sign In…ログイン
Passwprd long? Hard to tipe? …パスワードが長くて入力が難しいですか？
Get a magic link…Eメールに送られるマジックリンクから簡単にログインできます！
Send Magic Link…Magic Linkを送る
Type password instead…パスワードを入力する

（中央枠）
Sign in on your…モバイル機器からログイン
Check your email…Eメールを見てください
We sent an email to you…joel@joelcalifa.comにEメールを送りました。Magic Linkからログインできます。
Open Mail App…メールアプリを開く
Sign in to a different team…違うチームにログインする

（右枠）
Hello friend,…ようこそ
You requested that we send you…私たちのモバイルアプリに簡単にログインできるリンクの送付リクエストを受け付けました。ご希望はこのコマンドですね。さあどうぞ。
Sign in to slack on your…モバイルでSlackにログインする
Not on your mobile devide… モバイル機器ではありませんか？ このリンクが使えるのはiOS、Android、または……

Yahooも、パスワードを使わなくなってきており、 Yahoo Accoun Key を導入しているところです。”2要素”という用語は公式リリースでは使われてこそいませんが、その価値は明らかです。将来的にパスワードは不要となるのです。

パスワード強度メータの利用

この優れたUI要素は、（アカウントがユーザにとってある程度重要である場合に） 効果的であると証明されました 。
パスワード強度メータは、より強固なセキュリティのパスワードを使いたいというユーザの意欲をかきたてます。この特別な意欲が”パスワード強度メータをグリーンにする”ことだというのは、たいした問題ではありません。

これが登録フォームに追加されるべきなのは明らかですが、パスワード強度メータそのものにも問題があります。

多くの場合、メータはとてもあいまいです。 “弱いパスワードです”と表示されても、必ずしも、よりセキュリティが強固なパスワードの作り方を教えてくれるわけではありません。”優れたパスワードです”と表示されても、なぜ優れているかを教えてくれません。

*注釈：
I agree to Dropbox terms…Dropboxの規約に同意します。
Sign up for free…登録無料
Week…弱い
Good passwords are hard to guess…優れたパスワードは推測しにくいものです。一般的ではない単語や身内のジョーク、標準的ではない大文字の使い方、創作スペリング、自明ではない数字や記号などを使いましょう。

Dropboxのパスワード強度メータは、全く同じ内容を表示します。セキュリティの強固なパスワードを入力しても変わりません。

パスワード強度メータは、頑固なのです。 あるメータでは優れたパスワードでも、他のメータでは弱いパスワードとなる可能性があります。メッセージの表現が足りない上に、技術に疎いユーザに大きな混乱を与える恐れがあります。

幅広く高い評価を得ている zxcvbn など、何か1つの評価システムを標準とすることで、この問題に対処できます。

技術的なことがよく分からないユーザにとって、追加情報とガイダンスが表示されるパスワード強度メータは大変役に立ちます。登録するその時だけではなく、今後、あらゆる登録を行う際に同様に役に立つのです。

おばあちゃんに横柄な態度をとることはやめて、良いパスワードの作り方の説明を始めましょう。

パスワードセキュリティガイド

DigitalOceanでは、ユーザへの教育を信条としています。それが、私たちが コミュニティ に多大な投資をする理由です。私たちは、ユーザを路頭に迷わせたくありませんし、チュートリアルの手順に従っていればいいなどとは考えていません。ユーザに、自分のしていることを 理解 してほしいのです。成長してほしいのです。

以下のデザインパターンは、パスワードセキュリティガイド（以下PSG）と私たちが呼ぶものです。これは私が作ったアプリケーションで、登録プロセスについて上に述べた姿勢を表すものです。

PSGと一般的なパスワード強度メータとの主な違いは、ユーザが選んだパスワードの強度を伝えるだけではなく、その 理由 を伝える点です。

もう一度見てみましょう。選択したパスワードのどういう側面が”まあまあ”なのでしょうか。特殊な文字列ではないからでしょうか。頻繁に使われるパスワードの1つだからでしょうか。長さが問題でしょうか。このサイトがパスワードに関して口うるさいだけでしょうか。一体、なぜこの評価になったのでしょうか。

技術に疎いユーザがこのメータから理解することは何でしょう。それはたった1つです。つまり、この口うるさいパスワードシステムはイライラするし、頭が悪いし、何よりも、時間のムダだということです。

より良いパスワードを作成するモチベーションは単純です。それは、この入力フォームを終えてアプリを使いたいということです。メータのバーをグリーンにすることは面白いかもしれませんが、いつまでも面白いわけではありません。いまだかつてそんなことはなかったからです。

良いパスワードを選ばせれば、一日分のセキュリティが確保できる。良いパスワードの作り方を教えれば、生涯に渡ってセキュリティが確保できる。

パスワードメータをグリーンにすることや、入力フォームから抜け出すといったこととは別の方向にモチベーションを移しましょう。 セキュリティのために良いパスワードをユーザに選んでもらうようにしましょう。

では、次のストーリーを想像してみてください。技術に疎いユーザが”qwerty”とパスワードを入力したところ、以下のようなメッセージが表示されました。

*注釈：
Sign Up…登録
Pick stronger password to continue…続けるにはもっと強固なパスワードにしてください。
WARNING!…警告！
This password is on a list…このパスワードは 頻繁に使われるパスワード のリストに載っています。このパスワードを使うと、 あなたのアカウントがハッキングされる恐れがあります。
View the list…他にもどのようなパスワードの使用が危険か、 リストをご覧ください。

パスワードが基準を満たさないということしか伝えない漠然とした内容では、ユーザがシステムに対して怒りを覚えるだけで、何の利点もありません。私たちはそのかわりに、何が問題なのかを説明します。

このユーザはほんの少し前まで、破られることも推測されることもない”qwerty”というパスワードに絶大な自信を持っていました。しかし今では、これが最もよく使われるパスワードの第6位であることを知ったのです。非難の気持ちは、イライラするパスワードシステムからすぐに逸れて、自分自身に向けられました。でも、これで良かったのです。今回だけに限らず、将来的にもどうするべきかが分かったのですから。二度と”qwerty”を使うことはないでしょうし、次回、アプリがパスワードを拒否した時に、怒り出す前にもう一度考えるでしょう。

注釈：
（左枠）
警告！
このパスワードは辞書に載っています。 ハッカーはパスワードを推測しやすいように日常的に辞書を使っています。
単語を作り出すか、2つ以上の単語を使用してください。

（中央枠）
警告！
このパスワードは年を使っているようです。 もしこの年があなたに関係ある場合、ハッカーがそれを利用してパスワードを推測する恐れがあります。
他人があなたのことを推測できるような個人情報の使用を避けるのが最良策です。

（右枠）
警告！
このパスワードは短すぎます。 6文字の場合、10分以内にパスワードが破られる恐れがあります。
さらに6文字追加すると、破るのに3年かかります。 パスワードは長いほど良いと言えます。

私たちはまた、ユーザを大人の存在として扱い始めています。ユーザを教育することで、私たちは役割を果たしました。もちろん、今後も”よく使われる上位10,000のパスワードを使ってはいけない”とか”あまりに短すぎるパスワードを使ってはいけない”などの常識的なルールを設定することはできます。しかし、もしユーザがこうした標準ルールに適うけれども比較的弱いパスワードを使いたい場合には、使用したことによる影響について学び、結果を受け止めることができるようであるべきです。

別の方法として、ユーザに登録フォームを送信させて、その直後にヒントを与える方法があります。例えば次のようなものです。

*注釈：
Your password could be better!…あなたのパスワードはもっと良くなります！
Short passwords…短いパスワードはとても簡単に破られます。
文字を加えるごとに、パスワードは強固になっていきます。
Your paswords is 6 characters…あなたのパスワードは6文字なので、10分以内に破られる恐れがあります。
Add more 6 characters…さらに6文字追加すると、破るのに3年もかかります。
Enter new password…新しいパスワードを入力する
Skip…スキップ
Continue with new password…新しいパスワードで続ける

私は、あらゆる登録フォームでPSGが使われている未来を想像しています。ユーザは特定のパスワードを選択するよう強制されるのではなく、 そのプロセスを通じてより良い教育を受ける のです。どういうパスワードが望ましくないもので、それはなぜなのかを学び、新たなフォームに入力する度にその知識を使えるのです。

PSGはzxcvbnのようなオープンソースにするか、zxcvbnのようなライブラリに 相当するUI にするべきです。こうすれば、パスワードの強度を決める際や新たなセキュリティ上の不具合と戦うためにアップデートされた際に、あらゆるアプリが同じヒューリスティックを使えます。また、クラウドソーシングで収集された同じベストプラクティスを、ユーザの教育用に複数のアプリで使えます。

本稿を読んで、標準的なパスワード入力にPSGを容易に組み込むプロジェクトに一緒に取り組みたいという方がいましたら、 @notdetails までご連絡ください。

今後の展望

セキュリティ確保の方法としてのパスワードは、完璧とは言い難い状況です。また、パスワードの働きが分かっている人々は、パスワードは斜陽の技術であり、いつか Clef のような2要素認証サービスに取って代わられる可能性があることを知っています。

しかし、平均的ユーザにとっては、 パスワードがすぐに姿を消してしまうということはないでしょう 。残された時間をできるだけ有効に使い、パスワードをより良いものにしましょう。

このアイデアが気に入りましたか？　この話を Twitter や facebook で拡散してください。そうすれば、変化をもたらすことができるのです。

Joel CalifaはDigitalOceanのプロダクトデザインリーダーです。
デザインの枠を超え、人生に対する情熱によって、新たな素晴らしい友人を増やしています。もし本稿を楽しんでいただけたら、 Twitter か Eメール でご連絡ください。