こんにちは！ バックエンドエンジニアのKazです。
とても唐突ですが、「パスワード」って危ないと思いませんか？
目次
「ユーザー名＋パスワード」でのログインは最適解ではない
ショッピングサイトやSNSサイト、Webメールから電話料金の支払いサイトまで、ありとあらゆるサービスで「ユーザー名とパスワードの組み合わせ」で登録・ログインが行われていますよね。
でも、これって本当に適切なんでしょうか。
パスワードを「信頼しない」設計
まず英語版Wikipediaの「最もよく使われるパスワード一覧」というページを読んでみてください。
2011年以後、「123456」と「password」が1位と2位を争っているのが見てとれます。
ほかにも、キーボードを左上から順に打つ「qwerty」とか、管理者が設定しそうな「admin」とか、このレベルのパスワードが非常によく使われています。
つまりは、利用者がこうしたパスワードを使ってくる以上、Webサービスを設計したりするとき「パスワードは信頼できないものである」という前提で考える必要が出てくるのです。
パスワードは「秘密の情報ではない」
ぶっちゃけ、利用者はパスワードをきちんと管理していないんです。
いまだに手帳にメモしたり、PCの画面にパスワードを付箋で貼ったりするようなおぞましい運用が当たり前のように横行しています。
また、前述の「よく知られたパスワード」だけでなく、誕生日や電話番号などに絡めたパスワードもよく見られます。
こういう「そもそも利用者がきちんと管理していない可能性のある情報」を、本来厳格に管理されているべき認証情報として採用するのは矛盾していますよね。
パスワードは「漏れるもの」
利用者は、往々にしてパスワードを使いまわしています。
たとえばKeeperによる調査では「18〜30歳の87％がパスワードを再利用している」という結果が出ています。
これの意味するところは「ほかのサービスで情報漏えいが起きたら、あなたのサービスからも情報が盗まれる」ということです。
あなたのコントロール外の第三者のサービスが攻撃されても、ぶっちゃけ知ったこっちゃないですよね。でも、そこで使われていたパスワードが一緒にネット上に漏れれば、それを入手したほかの攻撃者が利用者になりすまし、今度はあなたのサービスにログインし情報の入手を試みます。
パスワードを認証要素に利用するということは、こういう潜在的リスクも発生するということになるのです。
パスワード自体の安全性は高められないのか
パスワード認証を少しでも安全にするためにパスワードを強力にするさまざまな手段が講じられてきてはいますが、どうしても利用者側のレベルに引っ張られてしまう以上、どの対策も付け焼き刃になってしまいます。
パスワードの定期変更は、逆にリスクを高める
サービスによっては「パスワードは定期的に新しいものに変更してください」と案内されたり、もっと厳格なところでは「一定期間経過したパスワードは使えなくする」という仕組みを採用しているところもあります。
これはパスワードを使い回すリスクを減らす効果を期待したもので、「利用者が定期的に無理やり新しいパスワードを考えなければならなくなるので安全ですよね」という仕組みです。
でもこれまでの例を見てみてください。利用者が複数のパスワードを覚えられるのであれば、そもそも使いまわしなんてしてないんです。
こういう仕組みを導入してしまうと、利用者に不便を強いるどころか、逆に「1234」「abcd」といったパスワードを交互に使いまわしたり、「abc#1」「abc#2」といったパターン化したパスワードを利用されたりして、さして強度が上がらないという事態になるのが関の山です。
それどころか新しいパスワードを覚えられなくなった利用者は、付箋に書き出して貼るという「解決策」を見出してしまいがちです。
これでは本末転倒ですね。
パスワードの定期変更については同様の理由でNIST (米国国立標準技術研究所) ガイドラインで非推奨とされており、総務省や内閣キュリティーセンターもそれに従って同様の案内を出しています。
パスワードの強度制限が、逆に危険な運用を強いている
サービス側で「安全のため」という理由で、パスワードの必要強度を高めるケースが散見されます。
たとえば「8文字以上」、「大文字小文字必須」、「記号・数字必須」とかいうやつですね。これって、パッと見ればいいアプローチのように思えます。
でも実態は、事態をより悪化させているんです。
前述英語版Wikipediaの「最もよく使われるパスワード一覧」をもう一度参照してみてください。
SplashDataによるリストの2017年19位に「passw0rd」というのが挙がっています。
これは紛れもなく2位にランクインしている「password」の亜種であり、サービス側で仮に「英数字を最低ひとつづつ」と制限をつけたところで、利用者はこういうパスワードを用いてしまうのです。
それに英数字記号を組み合わせた複雑な「qwER43@!」よりも、関連のない英単語を組み合わせただけの「correct horse battery staple」のようなパスワードのほうが覚えやすく、かつ機械的に推測しづらく安全であるといった理論もあります。
大文字小文字や数字記号の強制といった制約は、利用者にとって覚えにくいパスワードを推奨する反面、こうした「より強力な」パスワードを弾いてしまいます。
パスワード認証以外の方法を模索する
パスワードそのものの安全性が利用者依存になってしまい、その信頼性を期待できない以上、安全性を担保するには別の認証方式を考えたほうが得策です。
SMS認証
これはログイン時に携帯電話宛にSMS（懐かしのショートメール）で1回限り使えるランダムな認証コードを送り、それを入力して認証を完了させる仕組みです。
AWS SNSなどのSMS送信用ゲートウェイサービスを利用して送信・認証ロジックを自前実装するほか、Facebook社が提供している「Account Kit」を使えば認証処理まで全て丸投げすることもできます。
この仕組みの利点は、
- パスワードを覚える必要がない
- 認証コードはログインのたびに変わるので、付箋に書き留められない
- 使用済みの認証コードで不正にログインすることができない
- 認証コードはランダムなので、他サイトが攻撃されてパスワードが漏れても影響しない
- 常に手元にある端末で認証するので、知らぬ間に第三者にログインされることがない
といったものがあります。
逆にデメリットは、
- 携帯電話端末が必要（SMSを受信する必要があるのでデータSIMなどは不可）
- 端末が壊れた・紛失したときにログインできなくなる
- 利用するSMS送信ゲートウェイサービスによっては送信料金がかかる（Account Kitは2018年8月までは無料、それ以降は月10万件を超えた分だけSMS送信料金が課金される可能性がある）
といった形で端末に物理的に依存してしまう問題があります。
これを解消するため、セキュリティーとのトレードオフにはなりますがバックアップで後述のメール認証も行えるようにしておく方法が挙げられます。
メール認証
Slackなどで「マジックリンク」と呼ばれ採用されているログイン方式です。
登録されたメールアドレス宛に1回限り使えるログイン用の認証リンクを送り、それをクリックすることで認証を完了する仕組み。
これは言い得て妙な方式で、サービスによっては「パスワードを忘れたとき」のリセット手段で「パスワードのリセット用リンクをメール送信」しているものもあります。この手順であれば「もはやそのままログインさせちゃえばよくないか」という風になってしまいますが……。
ただ、このログイン方式には「メールサービスもまたユーザー名・パスワード認証であることが多い」という欠点があります。
メールサービスを突かれた場合、こちらも被害を被ってしまう諸刃の剣です（メールベースでパスワードリセット機能を提供しているサイトは、同様にこの攻撃の影響を受けうる）。
とはいえ、利用者が使っているサービスが仮にGmailなどであれば、追加の高度な不正ログイン対策が実装されていますし、プロバイダ提供のメールサービスだと事前に決められた比較的強力なパスワードが用いられていたりするので、サービス独自のパスワード認証ロジックを持たせるよりは安全です。
外部の認証サービスに丸投げ
最近よく見かける「Googleでログイン」「Facebookでログイン」というSNSログインボタンですが、これも解決策のひとつになりえます。
これらのSNSサービスもまたパスワードを認証要素にしているので100%安全とは言えないのですが、それでも彼らの持つ不正ログイン対策機構は「ないよりは断然マシ」なセキュリティーをもたらしてくれます。
これらのSNSログイン機能は利用者にとっても会員登録の手間削減に繋がりますし、利点は大きいのでおすすめです。
WebAuthn
この記事を書いていたら、ちょうどタイムリーに『パスワードに依存しない認証「WebAuthn」をChrome/Firefox/Edgeが実装開始』なんていうニュースが飛び込んできました。
詳しい説明は記事に譲りますが、WebAuthnは上記で挙げたパスワード認証の問題点を解消できる「公開鍵認証」と呼ばれる仕組みを採用しており、危険なパスワードに頼ることなく安全に利用者を認証できるようになっています。
現時点ではまだAppleがWebAuthnの対応を発表しておらず、当面はSafariなどでも使えないため、全てをWebAuthnにすることはできません。が、認証方式のひとつとして提供する価値はとても大きいです。
将来的にこれが普及すれば、おそらくWebAuthnが最良の認証方式となります。
多要素認証
すでにサービスインしている場合、パスワード認証の撤廃はなかなか難しいですよね。
あるいは新規にサービスを作る場合でも、デファクトスタンダードであるパスワード認証を採り入れないという選択肢には大きな決断を必要とします。
この場合「パスワード認証は活かしたまま、追加の認証を要求する」ことでセキュリティーの強化が可能になります。
前述のSMS認証やメール認証を「追加で」要求したり、一定時間ごとに書き換わるワンタイムパスワード (TOTP) を導入したりすることで実現します。
TOTPはGoogleを筆頭に様々なサービスで利用されていて、 Google Authenticator などのクライアント側アプリケーションと組み合わせて無料で導入でき、セキュリティーを格段に向上させることができます。
これまでに利用者由来のパスワード認証の問題点ばかりを挙げてきましたが、一部の「適切にパスワードを運用している利用者」にとってはこれからもパスワードが適切な認証要素にはなっていきますので、「ほかの認証要素＋パスワード」という多段階の認証を選択肢として提供するのは、利用者へのメリットにもなります。
Yahooはパスワードログインの無効化機能を提供
パスワード認証の廃止はもはや特別なことではなく、あのYahooも先日「Yahoo! JAPAN、セキュリティ向上の新たな取り組みとして、 パスワードでのログインを無効にする機能を提供開始」というプレスリリースを発表しました。
この記事中に挙げられているようにYahooでは2017年4月からパスワードを利用しないユーザー登録方法を提供していて、今回の発表はさらに一歩進んで「既存ユーザーもパスワード認証を無効化できるようにした」ものとなっています。
このように国内を代表する大規模Webサービスにおいても「パスワード認証は危険性をもたらしうる」と認識され、パスワードに変わる代替認証手法が提供される時代となりました。
まとめ：これからのセキュリティー
前述した対策を施すことで、パスワードが元来持つ「不信頼性」をある程度克服することは可能です。
もちろんパスワードが諸悪の根源というわけではないのですが、何十年と利用され続けたパスワードが、この期に及んで未だにリスクの要因になっているのは事実です。
サービスを設計開発し、正しく運用していく上で、その根幹である「認証」の安全性をいかにして担保していくのか。見過ごされがちですがとても重要な、この課題をみなさんがご一考されるきっかけになりましたら幸いです。
LIGはWebサイト制作を支援しています。ご興味のある方は事業ぺージをぜひご覧ください。
