雑記帳

整理しない情報集

更新情報

パスキーについて調べてみた

公開日:

カテゴリ: Webサービス

漠然とパスキーを使っていたら認証できないパターンがあったので、最低限はきちんと調べてみようということでまとめてみました。

パスキーとは

パスキーは近年急速に普及している認証方法の1つで、パスワードを用いずに公開鍵で認証します。使用している技術(公開鍵認証やFIDOなど)自体はこれまでも存在していましたが、パスワードに代わる認証方法として一般ユーザでも使いやすいように、OSやブラウザベンダーを中心に環境が色々と整備されてきています。

パスワードが抱える問題

  • 毎回同じ文字列で認証する → 漏洩したら一発アウト
  • ユーザは管理や運用が大変(強力なポリシーがあっても、ポリシーを回避することが目的化する)
    • 認証が必要なサービスが増える → 面倒になって、秘密でない情報を使ったり使い回したりしがち
    • 数字や記号を必須にする → Iやlを1、aを@に置き換えたり、1や!を後ろに付けるなどパターン化しがち
    • 定期的に変更させる → 忘れる、パターン化する、元のパスワードを設定し直すなどをしがち
  • 偽サイトかどうかの判断がすべて自己判断

パスキーではこれらパスワードの問題点が、完全にとまでは言えませんが一通りは解決します。

パスキーの欠点

パスキーの保存先がパスワードマネージャもしくはセキュリティキーであるため、それらの欠点がそのまま当てはまることになります。

  • パスワードマネージャを使う場合
    • 他の端末で同じ認証情報を使う場合は同期機能もしくはBluetoothが必須
    • クラウド系のサービスを使用する場合はベンダーに全幅の信頼を置く必要がある
    • クラウド系のサービスを使用する場合はアカウント停止(BAN)でロックアウトされる
  • セキュリティキーを使う場合
    • パスキーの定義上はDiscoverable Credentialsであるため(後述)、セキュリティキーに登録できる鍵の数には上限が存在する
    • 故障・紛失したらロックアウトされる(その対策で2本以上登録することを推奨するサービスが多い)

パスキーの使い方

パスキーは以下の3通りの認証方法があります。

  • パスワードマネージャ
  • セキュリティキー
  • Bluetooth

パスワードマネージャ

OSやブラウザにもよりますが、以下の3種類のパスワードマネージャが使用可能です。どれを使用するかは使用時に選択できますが、ブラウザによっては最初に表示された方法をキャンセルすると他の方式を選択できるなど、選択方法の実装はまちまちです。

  • ブラウザ内蔵のパスワードマネージャ
  • ブラウザの拡張機能としてインストールしたパスワードマネージャ
  • OSのパスワードマネージャ

さらにOSのパスワードマネージャは、OSがサードパーティアプリ向けにAPIを解放している場合、ユーザがOSにインストールしたパスワードマネージャ(対応している場合)も使用可能です。

セキュリティキー

USBまたはNFCで接続します。USB接続での認証時は、多くの場合PINだけでなくセキュリティキーへのタッチが要求されます。

NFCの場合は最初にキーと接触して読み取りした後、PINを入力し再度接触して認証します。

Bluetooth

認証する側でQRコードを表示し、パスキーを格納したデバイスでそのQRコードを読み取り、Bluetooth経由で認証します。そのため認証する側とパスキーを格納しているデバイスの双方でBluetoothが必要です。

認証情報はBluetooth経由でやり取りされるため、パスキーを格納したデバイス側のネットワーク接続(Wi-Fiやモバイルデータ通信)は不要です。

関連情報

関連する単語

FIDO (Fast IDentity Online)

パスワードへの依存を減らすための標準化に向けて設立された業界団体です。

FIDO2が標準化される前のFIDO UAFやFIDO U2Fのことをまとめて指すのに使われることもあります。

FIDO UAF (Universal Authentication Framework)

生体認証などによって、パスワードレスをサポートする方式です。生体認証そのものはローカルで行われ、成功したら認証デバイス内の鍵を用いて認証します。

FIDO U2F (Universal 2nd Factor)

2要素目の認証手段として開発された方式です。1要素目(パスワード)の認証はそのままに、ワンタイムパスワードの代替として使用できるプロトコルです。後述の発見不可能な認証情報にあたるため、無限に認証情報を生成できます。

CTAP1 / CTAP2

認証端末と認証器間の通信方法を定めた規格です。現在はFIDO U2Fに新しく名前が付けられたCTAP1と、FIDO2用のCTAP2の2つの規格が存在します。USB・NFC・Bluetoothのいずれかを用いて通信します。

CTAP2では、CTAP1(FIDO U2F)の認証器にモバイルデバイス(スマートフォン等)が追加され、さらにパスワードレス認証をサポートします。CTAP1の下位互換もあります。

FIDO2

FIDO U2Fを拡張したCTAP2とWebAuthnを用いてパスワードレス認証を実現する方式です。パスキーはこの方式の実装の1つです。

WebAuthn

FIDOをサポートするWeb APIです。W3Cで標準化されており、各種ブラウザでこのAPIのサポートが行われています。

2種類の認証情報

FIDO2の元となっているFIDO U2Fでは、パスキーのようにサービスごとに秘密鍵をユーザ側で保持するのではなく、ユーザ側の固有ID(デバイス固有のIDやシークレット等)とサービス側のID(ドメイン等)を用いて秘密鍵を導出する方式でした。パスキーは前述の通り秘密鍵をユーザ側で保持するものを指しますが、技術的には同じFIDOの規格であるため、サービス側が対応していれば今でも秘密鍵を導出する方式でも認証できます。

色々あって様々な呼び方が存在しますが、いずれもどちらかを指します。

発見可能な認証情報

  • 秘密鍵をユーザ側で保持する方式
  • ユーザは保持されている認証情報を確認できる(どのサービスのログイン情報を保持しているのか確認できる)
  • 秘密鍵以外に付加情報を保持できる(サービスによってはユーザIDの入力を不要にすることが可能)
  • 呼び方
    • Discoverable Credential
    • Resident Key
    • Client-side Credential

発見不可能な認証情報

  • 秘密鍵をユーザ側で保持せず、固有のIDを用いて計算で導出する方式
  • どのサービスで使用しているかは確認できない(鍵を保存しないため)
  • 計算で秘密鍵を導出するため、無限に認証情報を生成できる
  • 呼び方
    • Non-Discoverable Credential
    • Non-Resident Key
    • Server-side Credential

その他

Bluetoothのプロファイル

ポリシー等で使用可能なプロファイルに制限をかけている場合、FFF9とFFFDを許可するとBluetooth経由でのパスキーが使用可能になります。

  • FFF9: FIDO2 secure client-to-authenticator transport Service
  • FFFD: Universal Second Factor Authenticator Service

Windowsでの設定例(FIDO2のみ許可)

REG ADD HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Bluetooth /v ServicesAllowedList /d "{0000FFF9-0000-1000-8000-00805F9B34FB};{0000FFFD-0000-1000-8000-00805F9B34FB};" /f
REG ADD HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Bluetooth /v ServicesAllowedList_ProviderSet /t REG_DWORD /d 1 /f
REG ADD HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Connectivity /v AllowBluetooth /t REG_DWORD /d 2 /f
REG ADD HKLM\SOFTWARE\Microsoft\PolicyManager\current\device\Connectivity /v AllowBluetooth_ProviderSet /t REG_DWORD /d 1 /f

PRF (Pseudo Random Function)

パスキーは認証のための技術ですが、そのパスキーを元に暗号化用の非対称鍵を生成することができる機能です(正確にはWebAuthnの拡張機能)。

パスワードマネージャのBitwardenでは、保管庫をマスタパスワードではなくPRFで暗号化する機能がベータ版として提供されています。

リモート環境下での認証

パスキーはWebAuthnが使用できれば認証できるため、リモートデスクトップソフトウェアにWebAuthnを転送する機能があれば認証可能です。

Windows標準のリモートデスクトップにはWebAuthnの転送機能があるため、サーバ側で許可されていれば(デフォルト設定は許可)、クライアント側で機能を有効にして接続すれば使用可能です。

認証時にサーバ側でセキュリティキーを選択するとWebAuthnがクライアントPC側に転送され、クライアント側で認証を行う(USBもしくはBluetooth接続)と結果をサーバに返します。あくまで認証を行うのはクライアント側であるため、サーバ側ではUSBやBluetoothは不要です。

おわり

長年の課題だったパスワード問題が、100%代替になるとまでは言えませんが、技術的・制度的には一旦の解決を見せようとしています。あとは対応サービスが増えれば一段落ですね。

ユーザ認証周りでは、個人的にはあとは秘密の質問・SMS認証が廃止に向かってくれれば嬉しいですが・・・。

参考

カテゴリ: Webサービス

最新の記事

カテゴリ

その他