パスワードの表示/非表示切り替え機能ってセキュリティ的に大丈夫なの？
アンカーデザインの木浦です。 弊社はUIやUXデザインも多く手がけており、プロジェクトによってはシステムの開発まで行うこともあります。先日、 デザインしたUIを実装してもらうために、エンジニアと話をしていたところ、このような話題が出ました。
「パスワードの入力フォームで、最近表示表示の切り替えができるものが多くなっているけれど、これ実際のところセキュリティー的にはどうなんですかね？」
なるほど。下記の画像のようなログインフォーム、結構目にしますよね？バリエーションはいくつもありますが、パスワード入力欄に目玉みたいなアイコンがついていて、それをクリックすると入力したパスワードが表示されるやつです。
我々デジタルサービスに関わっている人間は個人情報やパスワードの取り扱いについて非常に敏感になります。基本的にパスワードは他人に知られてはいけない物です。
それにもかかわらず、あえてパスワードを表示させるようなボタンということが存在して良いのか。 これは今更ではあるものの、至極まっとうな疑問かもしれません。 他のサービスが同じような仕組みを備えているからと言って、 思考停止して、同じような機能を実装する事は果たして正しいのでしょうか？
個人的にも気になった点であり、少し調べてみました。
そもそもセキュリティ的にはどうなのか？
まず初めに考えたのは、セキュリティーを扱う公式機関がパスワードの表示非表示の切り替え機能について、どのように捉えているのか、あるいは何らかの情報発信をしているのかです。
セキュリティーに関する著名な機関としては、アメリカのNISTがあります。NISTとは暗号プロトコル等を策定する機関です。NISTはパスワードについて（パスワードの話だけではありませんが）SP800-63Bという文書を公開しています。
こちらの文書の3 Authenticator and Verifier Requirementsに、下記のような記述があります。
To assist the claimant in successfully entering a password, the verifier SHOULD offer an option to display the secret — rather than a series of dots or asterisks — while it is entered and until it is submitted to the verifier. This allows the claimant to confirm their entry if they are in a location where their screen is unlikely to be observed. The verifier MAY also permit the claimant’s device to display individual entered characters for a short time after each character is typed to verify the correct entry. This is common on mobile devices.
これを日本語にすると下記のような感じでしょうか。
申請者がパスワードを正しく入力できるように、入力中のパスワードは一連のドットやアスタリスクではなく、パスワードを表示するオプションを提供する必要があります。これにより、申請者は画面が監視される可能性が低い場所にいる場合に入力したパスワードを確認できます。あるいは正しく入力できているかを確認するために、各文字が入力された後、申請者のデバイスが短時間、入力された個々の文字を表示することを許可することもできます。これはモバイル デバイスでは一般的です。
つまり、NIST的にはパスワードを表示できるようにすることを推奨している訳です。
ちなみに、この項目には他にも推奨項目があります。できれば原文を読んで欲しいのですが、デザイナーが知っておくべき部分について抜粋すると下記のような物があります。
パスワードは最低でも8文字を入力さる必要があります。なお、できれば最低15文字を入力させるべきです。
パスワードは最低でも64文字まで入力できるようにする必要があります。
パスワードに使える文字として、ASCIIコード表のうち印刷可能な物すべてとスペース、そしてUnicode文字を受け入れなければなりません。
パスワードの「ヒント」を表示する機能を提供してはいけません。
ユーザーが脆弱なパスワード（過去に漏洩したパスワード、辞書に載っている単語、繰り返し文字、サービス名、ユーザー名など容易に推測されるもの）を入力した場合は別のパスワードを設定するように促しましょう。
パスワード強度メーター等を用いて、ユーザーにパスワードの強度を伝えましょう
パスワードの入力を何度か失敗したらロックしましょう
パスワードを定期的に変更するのを求めてはいけません
パスワードに異なる文字種（大文字、小文字、記号、数字など）を含めることを求めてはいけません
パスワードを入力させるときは「貼り付け（ペースト）」機能を使えるようにしましょう。
なお、NISTの他にCISのPassword Policy Guideにおいても、5.2.2で入力中のパスワードの表示/非表示を切り替えられるようにすることを推奨しています。
このようにセキュリティ的な観点からはパスワード入力フォームでパスワードを表示できるようにすることは問題無いと考えてよさそうです。
政府や行政のデザインガイドラインではどうなっているのか
ここで視点を変えて、海外の政府のデザインシステムがどのようになっているかを調べて見ました。デザインシステムはその国の様々な組織で使うことが想定されており、UIに関しても適切に検討されているべきです。 そのため、デザインガイドラインでパスワードが表示し、表示が備わっているのであれば、ある程度信頼できそうです。
イギリス
イギリスのGOV.UK Design SystemではPassword Inputのページがあり、個々で紹介されているデザインコンポーネントに表示/非表示のボタンがあります。なお、注意点として入力したパスワードはデフォルトで非表示にしてくださいと記載があります。
なおWCAG 2.2（Webアクセシビリティのガイドライン）についての言及もありますが、パスワード表示ボタンの設置そのものに関してではなく、表示/非表示ボタンのサイズを少なくと24x24ピクセルにしなさいとのことでした。
アメリカ
アメリカのU.S Web Design System(USWDS)ではCreate accountやSign-inに関するページがあります。こちらではデザインコンポーネントにShow passwordの文字列があり、切り替えられるようになっています。
なお、アメリカのデザインシステムではパスワードの表示/非表示の切り替えをできるように、と明記がありました。
ユーザーがパスワードの表示/非表示を切り替えることができるようにします。これにより、必要に応じてプライバシーを維持しながら、ユーザーがパスワードを正しく入力していることを確認できます。（Allow users to toggle password visibility. This helps ensure users are entering passwords correctly while maintaining privacy when needed.）
ヘルシンキ（フィンランド）
ヘルシンキのHelsinki Design SystemではPassword Inputのページがあります。こちらについては目玉マークでパスワードの表示/非表示の切り替えを実現しています。
この機能についてHelsinki Design Systemでは、Do not disabled this functionality without a good reason.（正当な理由がない限り、この機能を無効にしないでください。）とまで記載されています。強いですね。
日本
では我らが日本のデジタル庁はどうか・・・、というとデジタル庁がデザインシステムを公開しています。が、残念ながら私が探した限りではパスワード入力欄への入力内容について表示/非表示の切り替えに関する情報ではなく、そもそもパスワード入力欄をどうすべきか？についての情報がを見つけることができませんでした。
またIPA（情報処理推進機構）が何らかの指針を出していないかなと思って調べてみました。しかし、サービスをデザインする側に向けた情報発信は特に見つけることができませんでした。パスワードの作成管理に関するユーザー向けの情報発信はなされているのですが･･･。
とはいえ諸外国のデザインシステムを見る限りではパスワードの表示/非表示の切り替え機能は特に理由がないのであれば実装すべき、と言えそうです。
パスワード入力欄をデザインする際に考慮すべきこと
ここまで様々な事例を確認してきましたが、少なくともセキュリティ的な観点からはパスワードを表示させる機能を実装することに大枠として大きな問題は無いと言えそうです。
なお、本題とは異なりますがパスワード入力欄をデザインする時はこのあたりを考慮べきではないか？について私が思いつく範囲でいくつか列挙してみます。
デフォルトではパスワードをアスタリスクなどでマスクしておく
入力されたパスワードを表示できるようにすることはユーザーの利便性を高めますからユーザーのメリットは大きいでしょう。一方で、必ずしもユーザーが1人でシステムを利用するとは限りませんし、場合によってはzoomなどで画面共有しながら何らかのシステムを利用することもあるかもしれません。
ユーザーがパスワード入力欄に実際に文字を入力するまで、入力した文字がマスクされて表示されるか、マスクされずに表示されるかを判断するかを判断することは難しいでしょう。慣習に従えば入力されたパスワードはマスクされて表示されますので、マスクされるものだと思ってパスワードを入力してしまうと、セキュリティ的なリスクとなってしまいます。
そのためデフォルトではパスワードをマスクしておくのが望ましいと言えるでしょう。
一定時間経過後に自動で非表示になるようにする
パスワード入力中になんらかの理由でユーザーがPCの前を離席してしまう・・・と言った状況も想定しておくべきです。第三者によって表示/非表示ボタンを押されてしまう状況をどこまで想定するか、というのは悩ましいところですが、少なくともパスワードが画面に表示されたままというのは望ましくありません。
ユーザーの操作によって入力されたパスワードが表示されるようになったとしても一定時間経過後に再度マスクする、のような仕組みはあってもいいかも知れません。
パスワードマネージャーとの共存を想定する
昨今ではパスワードマネージャーを用いてパスワードを管理することが一般的になっています。そのため、サービスをデザインする側もパスワードマネージャーの存在を考慮に入れるべきでしょう。いまだに一部のWebサイトではコピー＆ペーストを禁止してパスワードを手入力することをユーザーに強制させていたり、パスワードマネージャーから入力がスムーズにできないものも見受けられます。
おそらくシステムを作っている側としては、セキュリティを高めるための施策としてそのような機能を実装しているのだとは思いますが結果としてユーザーがシンプルなパスワードを選択するケースが増えてしまい、逆効果であることもあり得そうです。
アクセシビリティを確保する
パスワードマネージャーの項目と近いですが、ITシステムは様々な方が利用できるようにすべきです。その中には例えばロービジョンや、全盲の方もいらっしゃいます。そういった方がパスワードを入力する際に、あるいは入力したパスワードを確認する際にできる限り考慮することが望ましいです。
例えば、表示非表示ボタンにキーボードでアクセスできるようにする、ボタンに適切なラベルをつける、スクリーンリーダーへの対応が挙げられますが、網羅しようと思うと多岐に渡るため本記事では簡易的に説明するに留めます。
パスワードの確認フォームは不要
パスワードを2回入力させる設計となっているサービスは多く存在しますが、実際のところユーザビリティを低下させる要因にもなっており、コンバージョン率を低下させるという報告もあります。ユーザーがパスワードを間違えて入力してしまったらどうするか？と言う問題はたしかに存在しますがパスワードの再発行機能があればカバーできるはずであり、2回入力させる必要性は多くの場合薄いでしょう。
余談ですがパスワードを2回入力させるにも関わらずコピペが使えないフォームは個人的に滅びて欲しいと思っています。パスワードマネージャーに頼り切っている人間としては不便極まりない･･･。
究極的には・・・そのシステムを誰がどこで、どんな状況で使うのか？を考慮する
究極的には当然の話であるのですが、そのシステムが使われるコンテクストを適切に把握したうえでサービスをデザインする必要があります。ユーザーのリテラシーはどの程度か。1人で使うシステムなのか、複数人で使うシステムなのか。オフィスでPCで使うシステムなのか、満員電車の中でスマホで使うことが想定されるシステムなのか。2段階認証があるのか、ないのかなど。そもそもシステムとして求められるセキュリティの強固度合いはどの程度なのか。これらは一例ですが、様々な要素を勘案しながらセキュリティとユーザビリティのバランスをとり最適なあるべきUIをデザインしていく必要があります。
余談：パスワードのマスクがそもそも不要だと言う説も
ユーザビリティの権威であるヤコブニールセンは2009年時点（15年前！）の記事でパスワードのマスクがそもそも不要なのではないかと提言しています。
パスワードの表示/非表示機能がどのようにして一般的になったかについて辿ることはなかなか難しいのですが、ヤコブニールセンのこの記事がその一助になった可能性は大いにあるでしょう。
おわりに
本来秘密であるべきパスワードを表示する機能については、セキュリティ面から一定の懸念があるものの、多くの状況で利便性が上回ることから機能を実現することが推奨されていると捉えてよさそうです。
さて、本記事ではパスワードの表示/非表示切り替え機能について書かせて頂きましたが、UIのデザインとは、技術とユーザー、あるいは事業の置かれたそれぞれの状況の適切に理解しながら、最善のソリューションを探求してい行かなければならないことが多くあります。そしてUIをデザインした立場として「なぜこうなっているのか？」という質問に対して、根拠を持って答えられるようにしておくことも求められるでしょう。
もちろん「慣習としてこうだから」というケースもかなり多いですし、多くのケースで慣習に沿ってデザインすればある程度の高得点を取ることができるのも事実です。一方で慣習がなぜそうなっているか？を知っておくと新しいコンセプトのUIをデザインしなければならないときなど役立つことも多いでしょう。