パスキー対応 という記事を見ると フィッシング耐性があるパスワードレスな世界が来る！ と期待を抱き、冷静に考えて パスワードが残ってるうちはリスクは残ってるしフィッシングにもやられるし何にもかわらねぇじゃねーか と遠い目をしてしまう皆さん、こんにちは。 ritou です。 いきなり一気に進むわけがないだろ。ということで、認証を必要とするサービスもユーザーも、パスキーにより理想的な状態となるまでには段階というものがあり、 大人の階段と同じで やるべきことがあります。そのあたりを理解することで、一喜一憂せずにやっていきましょう。 ２つの段階 既存の認証方式に加えてパスキーによる認証が利用可能 : 過渡期ってやつでしょうか。イマココ パスキーのみが利用可能 : 我々が望んでいる世界や！ あとはその前の なんもしてない段階 です。 そんなに新しい話でもないでしょう。 段階を進めるために必要な対応

こんばんは、ritouです。 タイトルの通り、お話をしてきました。 それではどうぞ。 動画 (2024/4/12: 動画が公開されていたので追記しました) 内容 OIDF-Jでエバンジェリストをしています。ritouです。 今日はパスキーとID連携についてお話させていただきます。 この発表では次の3点について話します。 それぞれの特徴/特性 ID連携のIdP/RPそれぞれがパスキー認証をサポートすることで得られるもの 関連するOIDC/OAuth 2.0の仕様 まずはそれぞれの特徴、特性から見ていきます。 パスキー、具体的には「FIDOクレデンシャルを用いた認証方式」について、特徴を振り返ります。 まずは公開鍵暗号を利用すること、ブラウザなどの仲介によるフィッシング耐性による安全性です。 そして、利用者の確認としてローカル認証と呼ばれる画面ロック解除の仕組みを利用すること、各プラットフォー

ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2023　の 初日の記事です。 こちら、参加者を募集中です！気軽に参加してみてください！してくれよ！はよ！ なんの話か ちょっと想定以上に反応をいただいたこちらの記事について、ちょっとだけ補足をしたいと思います。 なんの話か詳しく 自分のはてブのコメントをつけたポストにもたくさん反応いただきました。 実際、海外のサービスはメアドをキーにして参照してるところも多く これはサービスのDBのUserテーブルがemailをプライマリキーにしているという話ではありません(が、そう思われた方からDMが来ました)。 最初にパスワード認証やメールでリンクを送信して認証させる仕組みを実装している状態から、ソーシャルログインを実装しようとする際に "email" をキーにした参照をすることがあるんよ

ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単！けどこれ指紋認証だけ？弱くなってない？ SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった？ この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする

こんばんは、ritouです。 今回はこれを試してみます。 まずはパスキーを有効にします。 PCの画面だと右上のプロフィール画像をクリックするとワーっと出てくる中の "Feature preview" ですね。 "Passkeys" のところを選んで こう！ (Enable) で、右に表示されている "Add a Passkey" を押してもこれ ただの画像なので何も起こらないですよ。 本物は "Settings" -> "Password and authentication" と進めばあります。 2FAで使っていたPasskeyの昇格 追加してみようと思うと、再認証が必要...わかります。 そういえば自分は2FAで既にHybrid Transportを使ってAndroidのPasskeyを利用していました。 とりあえずそっちで再認証を終わると... ・・・おや！？ 2FA用のPasske

ritouです。 最近、というかずーーっと前からなんですが、世の中に○○認証と言われるものがたくさんあります。 ある程度専門性の問われる分野の用語は正しい意味で使われている気がしますが、一般的なWebアプリケーションなどで使われているものは割と意味を理解しないまま使われているものも多いと感じています。 ざっくりこんな分類ができるのかなと思っています。 他にこんなのもあるというのがあったらコメントやTwitterなどで指摘いただければ追記します。 パスワード認証、パスキー認証、生体認証… : 当人認証の方式 2段階認証、2要素認証、他要素認証 : 当人認証の方式の組み合わせ方 SMS認証、メールアドレス認証 : 当人認証の方式の一部とも言われるが、SMS番号/メールアドレスの所有を確認する処理として以前から使われている Twitter認証、Google認証、OAuth認証()、OIDC認証、

ritouです。 Venturaさんじゃなくても普通に使えるようになったらしいですね。 iPadOSやMontereyでも動くなら、と、試してみました。 1. パスキー生成&ログイン @ MacOS Safari Safari@MacOSでの動作確認動画です。 ユーザー名を入力してパスキー生成 discoverable credentials を利用してパスキーでログイン 2. iCloud Keychainで同期しているiPadOSからパスキーでログイン iCloud Keychainで同期しているiPadOS 16.1のSafariからパスキーでログインします。TouchID失敗してパスコードのところは大目にみてください。 動画をとるためにこれ試したの2回目で、初回はキーボード周りがもうちょっと違うUIだった(パスキー使うってのがどーんと出てた)気がします。 次の動画にも出てきますが、

ritouです。 最近ちょっと気になってしまう人が多そうな話です。 passkeyが気になっちゃう 最近、passkeyという仕組みに注目が集まっています。 docomoも対応予定だと発表があった件です。 デバイス単位ではなく、プラットフォーマーのユーザー単位で秘密鍵が同期される...FIDO認証におけるアッピールポイントの一つである堅牢性みたいなポリシーを緩めてもリカバリー困難問題を解消しに行ったこの方針に、ついつい考えたくなるのがクレデンシャル管理です。 デバイス単位で秘密鍵が保存され、ローカル認証により正当なユーザーが利用したことを検証された上で公開鍵暗号を利用した認証処理が行われるのがFIDO認証 それがユーザー単位になるってことは...これまでのFIDO認証よりセキュリティレベル？は下がってしまうよね??? Attestationのところが空になったらサービス側が検証できなくなる

ritouです。 先日の idcon っていう勉強会で Android の passkey 対応について聞きました。 Googleアカウント+Chromeパワーでなんとかしちゃうのかなと思っていましたが、Android端末間での同期みたいな感じのようでした。そこで、想定される機種変更の時にどうなるかを確認してみました。 準備 詳しい人がTweetしてたこの辺りのドキュメントを見て、ベータテスターになってGoogle Play Services betaを入れることで使えるようになりました。CanaryじゃないChromeでも使えます。あと、Androidたんで困った時は再起動とかガチャガチャしてれば使えるようになります。 後は端末を2台用意。Android Srudio使っても普通にできそうだけど実機があるのでおk。 では早速みてみましょう。 動作確認に使ったのはここです。 ログインの時は

ritouです。 背景 これまで数年に渡り、「新規登録/ログイン時に登録状態がわかるレスポンスを返してくれるな。」というお話をしてきました。 SMSやEmailを入力して認証コードなどを送るタイプのログイン方法でも同様の実装は可能であり、表向きは「認証コードを送信したよ。受け取った値を入れてくれよな。」としつつ実際は既に登録済みだからログインからこい、未登録だから新規登録から来い見たいな内容を送りつつ、画面では正規のユーザーと同様のトークンなりを送り検証が絶対通らん！ みたいなのを実装したりしています。 ではこれをWebAuthnなりネイティブ機能で提供されるFIDO認証でこれを実現したいとなった時にどうしたら良いか、細かく考えたらやっぱりめんどいなって話をします。 想定する環境 パスワード認証と組み合わせる2FA用途ではなく、FIDO認証のみでログインさせる 最初にユーザー識別を行うかど

おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2