パスキー時代の"認証要素"の考え方 ~単一要素の組み合わせ、おまとめMFAと同期~
ritouです。
前回は、パスキーやパスワードマネージャーを使う時の認証要素について触れました。
今回は、
- 同じ要素の認証を重ねる意味
- 同一端末やパスワードマネージャーだけで完結するMFA
- あるアカウントに紐づけられて同期されるクレデンシャル管理
についての 基本的な整理 をします。
前回に続き、書いていることは無難な内容だと思います。
(長いので先に)まとめ
- 単一要素を重ねる意味について、要素の種類によっては有効な場合もある
- SYK を重ねるケースは決済などでまだ見られるが今後は淘汰されていくのでは?
- SYH の場合、管理デバイスを分離することで安全性を上げられる。ただし手間は増えるしフィッシング耐性は別途考慮する必要あり。
- SYA を重ねる=単一SYAの精度を上げるのと同じ扱いになりそう(顔だけ、指紋だけ -> 顔 + 指紋など)
- 同一端末やパスワードマネージャー内で完結するMFAやプラットフォームアカウントに同期する場合は 認証要素の変換 が起こる
- 同一端末やパスワードマネージャーだけでのMFAの場合、その環境を使うための認証強度 に依存する
- あるアカウントに紐づけられて同期されるクレデンシャルは、そのアカウントでログインしている端末群、つまり それぞれの環境を使うための認証強度 や アカウント自体の認証強度 に依存する
単一要素を重ねる意味はあるのか?
自分で記事書いておいて、最近は ユーザー認証で大事なのは認証の3要素である! と言うのが前に出過ぎている気がします。そのおかげで?ごく稀に 同一の認証要素を重ねても意味がない という意見で殴りかかってくる方もいらっしゃいます。
このあたりは実際どうなんでしょうか?
SYK + SYK
最近の2FAスタイルではこのパターンは見かけないと思いますが、サービスや機能を利用する時に SYK を重ねるケースはたまにあります。
- ログインの際に第2パスワードを利用する
- ありえないと思って画像検索すると出てくる
- サービスが払い出したなんとかIDみたいな、記憶するの無理だろ的な識別子を入力させる場合は SYH 扱いになりそう
- パスワードでログインしつつ、アプリ内でPINみたいなのを設定させて利用
- 今ならプラットフォームのローカル認証(ロック解除)を利用すればいい気もする
- 決済機能など特定用途のところで第2パスワードや取引用パスワードを利用
- これは外部からの制約としてあるものもありそう
みたいなのがあるでしょう。
SYK の最大の特徴は SYH の認証方式に必要な特定デバイスが不要ですし、サービス側からは比較的楽にユーザーに責任を押し付けられるので使われてきたのでしょう。パスワードレスの風潮がある通り、今後は端末だけで閉じたPIN/パスコードと呼ばれるもの以外はだんだん淘汰されていくでしょう。
ユーザー側から見ると、この辺りもパスワードマネージャーに任せることで前回の記事のような 認証要素の変換 を行いつつ安全に運用していく方が良いのではないかと思います。第2パスワードの扱いなんてサービスごとに違うんでしょうからパスワードマネージャーでも追加のフィールドやメモ欄みたいなところを使わないといけないかもしれませんが。
SYH + SYH
SYH な認証方式はたくさんあります。
よく使われているのはこの辺りでしょう。
- SMS/Email OTP
- TOTP
- 認証アプリ
- セキュリティキー(UserPresent=刺して金属面を触れるぐらいのやーつ)
後述する 同一端末やパスワードマネージャーだけで完結するMFA の話にもつながりますが、それぞれの認証を行うために所持しておく必要があるデバイスなりが別であれば攻撃者観点から見て難易度が上がるので全体の安全性は高まります。しかし、ユーザーにとっても手間が増えることは確かですし、SMS OTP + TOTPの組み合わせで人間の手入力を含むフローはAiTMのような中間者攻撃には弱いので、フィッシング耐性 については別途考慮する必要があるでしょう。
SYA + SYA
指紋だけ、顔画像だけ、声や静脈だけではなくその組み合わせであったり動画であったり、SYA の組み合わせについては単純な精度向上としてみなせるのかなという印象です。
さまざまな理由によって利用できない認証方法がありそう(顔認証ができない、指紋が利用できない、声が出せない)だということと、あまりユーザーの負担になるようなものを頻繁に要求しても使われないだろうといったあたりは想像できる通りだと思います。
認証要素の変換と認証強度の依存
前回の記事でパスワードマネージャーを使うとパスワード認証の要素が SYH( + (SYK / SYA)) に変わる話を書きました。それが単一の認証方式ではなくMFAの場合でも同じです。
認証要素の変換 が起こり、そして 変換後の認証強度に依存 することになるのです。
- モバイル端末にパスワードマネージャーを使い、同一端末内にTOTPアプリや認証アプリ、バックアップコードがある
- パスワードマネージャー内で完結できるようにする
- プラットフォームアカウントで同期される
これらを考える時には、どんな認証に要素が変換されるのか、どこを守らなければならないかを
意識することが大事です。ちょっと見てみましょう。
同一端末や端末のロック解除を利用するパスワードマネージャーだけで完結するMFA
同一端末内に認証アプリが集約されている場合やモバイル端末のパスワードマネージャーにMFAを集約している場合、端末への物理的なアクセスとロック解除の認証要素(SYH(+ (SYK/SYA)))に変換されます。
画面ロックを厳しくしつつ、スマホを落とさないような人生を送りましょう。
パスワードマネージャーのアンロックが端末のロック解除と別である場合は、端末へのアクセスとパスワードマネージャーの認証を2段で突破する必要があるので、安全性は上がりますね。
アカウントに紐づけられて同期されるクレデンシャル管理
プラットフォームアカウントに紐づけられて同期される場合、守らなければいけないものが増えます。
- プラットフォームアカウント自体: プレーンなモバイル端末に対象のアカウントでログインできてMFAのクレデンシャルを同期したら、あとはやりたい放題です
- プラットフォームアカウントでログイン状態のモバイル端末への物理的なアクセスとロック解除: あるプラットフォームアカウントで複数端末にログインしていた場合は、守らなければならないものが増えることになります
ちなみにこの辺りはID連携でも同じことが言えますよね。
まとめ
- 単一要素を重ねる意味について、要素の種類によっては有効な場合もある
- SYK を重ねるケースは決済などでまだ見られるが今後は淘汰されていくのでは?
- SYH の場合、管理デバイスを分離することで安全性を上げられる。ただし手間は増えるしフィッシング耐性は別途考慮する必要あり。
- SYA を重ねる=SYAの精度を上げるのと同じ扱いになりそう(顔だけ、指紋だけ -> 顔 + 指紋など)
- 同一端末やパスワードマネージャー内で完結するMFAやプラットフォームアカウントに同期する場合は 認証要素の変換 が起こる
- 同一端末やパスワードマネージャーだけでのMFAの場合、その環境を使うための認証強度 に依存する
- あるアカウントに紐づけられて同期されるクレデンシャルは、そのアカウントでログインしている端末群、つまり それぞれの環境を使うための認証強度 や アカウント自体の認証強度 に依存する
以上です。
最近、Oktaに依存するGoogle Workspaceのアカウントと Google AuthenticatorでバックアップされるTOTP の話があったと思います。この記事の話が教科書に書いてある内容だとしたら、あの話は応用問題見たいな感じです。特にエンタープライズ分野においては、今回の話の守らなければいけない部分をシステムで管理できるのか、侵害に気づいた時に無効化できるのかみたいなところが重要になるでしょう。
ではまた。
Discussion