Zenn
🔑

パスワードレスな認証方式やアカウントリカバリーについての振り返り2020

2020/12/21に公開
Authentication
#
identity
#
Account Recovery
tech

ritouです。

Digital Identity技術勉強会 #iddance Advent Calendar 2020 19日目の投稿です。
急に穴が空いたのでアカウントリカバリーとかの話でリカバリーしましょう。

今年は認証やら本人確認などが騒がしい年でありました。
大きな問題の話はおいといて、自分のブログ記事に書いたぐらいの話を用いて振り返ります。

1. 一般的なパスワード認証 - パスワード = メール/SMSを用いたパスワードレス認証?

bosyuがTwitter/Facebookのソーシャルログインに加え、メールでリンクや認証コード的な文字列を送信、それを検証することでログイン状態とするパスワードレスな認証機能を実装されていました。

bosyuが実装したメールアドレスでの登録/ログイン機能とは!? - r-weblife

(追記: ころちゃん氏が関連する記事を書いてました。パスワードレス認証導入その後｜ころちゃん｜note)

あとはYahoo! JAPANもパスワードレスの推進と題して(後から紹介するFIDOと並べて)SMSを用いた認証を推しています。
ヤフーが推進する「パスワードレス」その進捗と今後の展望 - Corporate Blog - ヤフー株式会社

いわゆるパスワード認証において、パスワード認証とメールやSMSによるアカウントリカバリーを組み合わせるのが一般的です。

  • 認証 : パスワード認証
  • アカウントリカバリー : パスワード忘れた -> メールやSMSでリンクやコードを送り、検証できたらパスワードを再設定

ここで "アカウントリカバリー = 別の方式の認証 + クレデンシャル再設定" と捉えると

  • 認証 : パスワード認証、メール/SMS送信による認証
  • アカウントリカバリー : メール/SMS送信による認証 + パスワード再設定

というように2つの認証方式を持っているとも言えます。
そして、bosyuのメールによる認証やYahoo!JAPANのSMSによる認証は、ここから "パスワード認証" を取り除いてみたものです。

  • 認証 : メール/SMS送信による認証
  • アカウントリカバリー : なし(or 別途)

個人的にはこういうのを "引き算のパスワードレス" と呼んでいます。

当然、認証方式が少なければ少ないほど 詰んでしまう 状態になってしまうため、それをどう避けるかという課題はあるものの、今までよりも "パスワード認証"への依存がない考え方 が普及していくことを期待したい所です。

2. WebOTP APIを用いたSMS経由の認証方式の最適化

これは上述のうち、SMS送信を用いた認証方式について、安全性を保ちつつ利便性を上げられる仕組みを使おうというお話です。

SMS OTP form best practices

通常、

  1. SMSを受信する番号を入力
  2. 「認証コードを送ったので確認して入力してください」などのメッセージと入力フォームが出現
  3. 受信したSMSを確認し、何らかの方法で覚えてフォームに入力

と言った手順を踏む必要がありますが、2のところを工夫すると3の処理がよしなに行われて利便性が上がり、さらにフィッシングサイトには入力されないぞとなります。

これまでAndroidアプリで実現できていた挙動をWebアプリでも実現できるという話だったりしますが、
ベストプラクティスに従っていればあとはサポートするブラウザの時により便利になっていく仕組みなので、認証に限らなくてもSMSの送信と検証を行うWebアプリケーションを実装する際に意識しておくべき技術と言えるでしょう。

3. アカウントリカバリーの機会を減らすためのベストプラクティス

ここまで紹介してきたメール/SMSを用いたパスワードレスな認証方式のような "引き算のパスワードレス" に対し、FIDOは 所持 + 知識/生体 の組み合わせを実現できる "足し算のパスワードレス" だと個人的に思っております。

このような多要素の認証方式を採用していても、上記のメール/SMS送信による認証を持ってリカバリー機能を実現しようとしてもサービス全体としての認証強度としては低い方の"所持認証"となるため "(全体として)安全になりました！" とは言えません。

認証強度を保ったまま 詰むことを回避するための別の認証方式 となるとやはり複数要素が必要となり、結果として開発者の方が詰んでしまいガチ、という状況がこれまで続いていました。
「詰まないようにするには複数のAuthenticatorを登録しておくしかない」「それ本当に広まるんかい」みたいな状況の中、FIDOアライアンスからこのあたりに関するホワイトペーパーが出されていました。

パスワードレス認証のアカウントリカバリーの必要がない戦略とは - Yahoo! JAPAN Tech Blog

複数Authenticatorの登録の仕方について、

  • 追加する時も既存のAuthenticatorで認証しよう
  • Authenticatorの種類や組み合わせによって微妙に登録の流れ変わるけど細かくケアして行こう
  • どこまでAuthenticatorの情報を検証するか、UserVerificationが必要かどうかのポリシーを決めるのが大事

みたいな話が書かれています。
Authenticator追加時に行う認証の強度を下げないことや、どうしようもなくなったら登録時の本人確認のところまで...みたいなのはNISTのあれこれの方針と合わせて覚えておくと良いでしょう。

4. Decoupled な認証方式

ずっと注目してきた「手元の端末を使った●●」はLINEやxIDのマイナンバー要求APIの件などで今年はじわじわと動きがあったように思えます。

  • 認証プロトコル自体で実現するのか(例：FIDOのcaBLE)
  • ID連携のプロトコルにおいて実現するのか(例:CIBA)
  • 決済の仕組みとして実現するのか(例:3-D Secure)

と言ったような、UX自体はID連携だけではなく決済やSSIの観点などからも注目されていると思いますので、開発者の手間が増えないように整理されつつ広まっていくことに期待しましょう。

5. (e)KYC

KYC導入しなきゃ！ってのはだいぶ普及した(というか必要性に迫られたところが多くなってる)と思いますが、今後はKYC結果の安全な流通というところに注目が集まると色々と捗りそうです。

「それぞれで認証処理を実装するのは手間だしユーザーも大変」->「ID連携で解決」の流れですね。

ID連携でおなじみのOIDCの属性情報としてKYCの結果をやりとりする仕様も策定が進んでいますし、ユーザーの負担や開発工数など全体的にWin-Winな仕組みで世界の平和を目指しましょう。

まとめ

  • 認証や本人確認に注目が集まった
  • 認証強度の要件が軽いサービスにはシンプルな認証方式の普及も大事、ユーザーの負担を減らすプラクティスを意識しよう
  • 認証強度の要件が重いサービスも工夫して認証強度を保っていく必要がある。細かいプラクティスを意識しよう。

マイナンバーカードについても何か書きたかった気がしますがまぁいいです。

ではご安全に！

Discussion