Passkey's Tips: モバイル端末を使ってPCにログインしたらその端末のパスキー登録に誘導する
ritou です。 パスキーに関するTips始めました 今回の内容 Apple, Google, Microsoftがパスキーパスキー言い出した時、FIDOアライアンスがこんな動画を出していました。みたことある方もいらっしゃるかもしれません。 この後半で、Android端末のパスキーを用いてWindows PCのブラウザでサービスにログインして、その直後にWindows Helloでもパスキーを登録するっていう流れが説明されています。 同じように、Android端末のパスキーを用いてMacOSのSafariでサービスにログインして、その直後にiCloud Keychainでもパスキーを登録するっていう流れも説明されています。 今でこそ1Passwordとかでクロスプラットフォームのパスキー利用が実現できそうなものの、最初の頃の「え？プラットフォームを超えた同期はできないの？そりゃそうか」と
パスキー対応における2つの段階と必要な機能
パスキー対応 という記事を見ると フィッシング耐性があるパスワードレスな世界が来る！ と期待を抱き、冷静に考えて パスワードが残ってるうちはリスクは残ってるしフィッシングにもやられるし何にもかわらねぇじゃねーか と遠い目をしてしまう皆さん、こんにちは。 ritou です。 いきなり一気に進むわけがないだろ。ということで、認証を必要とするサービスもユーザーも、パスキーにより理想的な状態となるまでには段階というものがあり、 大人の階段と同じで やるべきことがあります。そのあたりを理解することで、一喜一憂せずにやっていきましょう。 ２つの段階 既存の認証方式に加えてパスキーによる認証が利用可能 : 過渡期ってやつでしょうか。イマココ パスキーのみが利用可能 : 我々が望んでいる世界や！ あとはその前の なんもしてない段階 です。 そんなに新しい話でもないでしょう。 段階を進めるために必要な対応
パスキー時代の"認証要素"の考え方 ~単一要素の組み合わせ、おまとめMFAと同期~
ritouです。 前回は、パスキーやパスワードマネージャーを使う時の認証要素について触れました。 今回は、 同じ要素の認証を重ねる意味 同一端末やパスワードマネージャーだけで完結するMFA あるアカウントに紐づけられて同期されるクレデンシャル管理 についての 基本的な整理 をします。 前回に続き、書いていることは無難な内容だと思います。 (長いので先に)まとめ 単一要素を重ねる意味について、要素の種類によっては有効な場合もある SYK を重ねるケースは決済などでまだ見られるが今後は淘汰されていくのでは？ SYH の場合、管理デバイスを分離することで安全性を上げられる。ただし手間は増えるしフィッシング耐性は別途考慮する必要あり。 SYA を重ねる=単一SYAの精度を上げるのと同じ扱いになりそう(顔だけ、指紋だけ -> 顔 + 指紋など) 同一端末やパスワードマネージャー内で完結するMFAやプ
パスキー時代の"認証要素"の考え方 ~パスキーとパスワードマネージャー~
ritouです。 サービス、ブラウザ、OSそれぞれのパスキー対応が日々進んでいます。 その中で、パスキーを利用してみて認証要素についてふと考えてしまう人がいるでしょう。 パスキー簡単！けどこれ指紋認証だけ？弱くなってない？ SMS OTPを2FAに設定し、パスワードマネージャーも使ってたから使い勝手はあまり変わらない。むしろSMS OTPがないぶんだけ弱くなった？ この辺りについて整理します。 認証要素というと、次の3つです。 SYK: Something You Know. パスワード、PIN SYH: Something You Have. 認証アプリ、TOTP生成アプリ、バックアップコード、 SYA: Something You Are. 生体認証 前にこんな記事を書きました。 この内容を説明すると、「うん、わかってる」って人は多いです。 でも、実際に使ってみると心許なく感じたりする
Androidのpasskeyを使うと機種変更の時にどうなるか確認してみた
ritouです。 先日の idcon っていう勉強会で Android の passkey 対応について聞きました。 Googleアカウント+Chromeパワーでなんとかしちゃうのかなと思っていましたが、Android端末間での同期みたいな感じのようでした。そこで、想定される機種変更の時にどうなるかを確認してみました。 準備 詳しい人がTweetしてたこの辺りのドキュメントを見て、ベータテスターになってGoogle Play Services betaを入れることで使えるようになりました。CanaryじゃないChromeでも使えます。あと、Androidたんで困った時は再起動とかガチャガチャしてれば使えるようになります。 後は端末を2台用意。Android Srudio使っても普通にできそうだけど実機があるのでおk。 では早速みてみましょう。 動作確認に使ったのはここです。 ログインの時は
FIDO認証できるユーザーをスキャンさせない設計を考える
ritouです。 背景 これまで数年に渡り、「新規登録/ログイン時に登録状態がわかるレスポンスを返してくれるな。」というお話をしてきました。 SMSやEmailを入力して認証コードなどを送るタイプのログイン方法でも同様の実装は可能であり、表向きは「認証コードを送信したよ。受け取った値を入れてくれよな。」としつつ実際は既に登録済みだからログインからこい、未登録だから新規登録から来い見たいな内容を送りつつ、画面では正規のユーザーと同様のトークンなりを送り検証が絶対通らん！ みたいなのを実装したりしています。 ではこれをWebAuthnなりネイティブ機能で提供されるFIDO認証でこれを実現したいとなった時にどうしたら良いか、細かく考えたらやっぱりめんどいなって話をします。 想定する環境 パスワード認証と組み合わせる2FA用途ではなく、FIDO認証のみでログインさせる 最初にユーザー識別を行うかど
2022年5月末に利用できなくなる「ID/パスワードのみのGoogleアカウントへのログイン」とは何か
こんにちは、ritouです。 昨日、こんなTweetをしました。 これは何かという話です。 いきなりまとめ Googleへのログインの話 ではない カレンダーやメールなど古からのプロトコルでは パスワード認証を前提としたものがある それが OAuthに置き換わる 感じ PIM系プロトコルとパスワード認証(認可？) このネタどこかに書いた気がするな...ってので振り返ると、メールについてこの前記事書いてました。 今回も同じ話ですね。一部を除いてこれのリミットが来たってところでしょう。 OIDCじゃないのか？というところは、カレンダーやメール、アドレスブック情報へのアクセスが目的なのでやってることはリソースアクセス、なのでOAuth 2.0すね。 校長「GoogleがPIM系のパスワード認証を駆逐し始めるまでに12年かかりました。」
レゴブロックで整理する認証方式の段階/要素
おはようございます。ritouです。 Digital Identity技術勉強会 #iddanceのカレンダー | Advent Calendar 2021 - Qiita 4日目の記事です。 前にこんなTweetをしてしまったので書きます。 参考記事 ITS SINGLE STEP NOT FACTOR — clarifying more FIDO terminology | by Ackermann Yuriy | WebAuthn Works | Nov, 2021 | Medium いろんなサービスで2段階認証やられてますね。FIDOだと2要素認証だと言われてます。でも、プラットフォームの生体認証使ったりセキュリティキーに生体認証載ったら一回のユーザーアクションでいけますよね？それって段階としては１ですか？要素は2?要素と段階どっちが強いんです？…みたいな混乱を解消するための記事で
OAuth 2.1を見守る会
02と03の差分を調べました。 構成変更があって差分がたくさんあるように見えますが、特に新しい物は見当たりませんでした。 次回に期待しましょう。
OAuth 2.1の差分を見守る会 : draft 01-02
ritou です。 本投稿はOAuth 2.1って呼ばれたい感を出してる仕様の差分を見守る会です。 本投稿含め、差分を スクラップ - OAuth 2.1を見守る会 でまとめています。 3月にドラフトが01から02になってたのを放置していたので、その差分からどんな部分が強調されたり説明が追加されたのかなというのを見ていきます。 このやり方、新しい仕様においては最終的にRFCになるものに含まれない内容に触れることもあり、経緯なんてすっ飛ばして出来上がったものをいただく派には無駄に思える作業かもしれません。 しかし、このOAuth2.1ってのはこれまで出された仕様とベストプラクティスを踏まえたものなので、きっと無駄にはならないはず。 早速見ていきましょう。 差分 差分 目次 目次から見える差分としては Client Password 改め Client Secret Refresh Token
OAuth ClientのWebアプリ,APIのエンドポイントの設計
ritou です。 今回はOAuth Client側のエンドポイントの設計について書きます。 この話です。 世の中に溢れている "Rails + Devise + OmniAuth 入れてこうやってこうすれば動きますよ(ドヤ" な感じでも困らないなら別に良いと思いますが、 今回は少し細かくみていきましょう。 実装する必要がある機能 OAuthのClientが実装する必要がある機能は今までも何度か書いています。 認可リクエストを作成してセッションと紐付ける Authorization Server にリダイレクトして、Clientが要求するリソースアクセスに対するリソースオーナーの許可を得る Client に戻ってきて Access Token/Refresh Token を取得する リソースアクセス みたいな感じです。 ここで、ソーシャルログインとかが頭にあると「未ログイン状態でセッション
OAuth 2.0 の Client Type についての考え方
ritou です。 OAuth 2.0 のクライアントの種類、いわゆる Client Type についての基本的なお話です。 よくある認識 仕様だと Public : ClientSecret を安全に管理できず、他の方法でもセキュアなクライアント認証ができないクライアント Confidential : ClientSecret を安全に管理できる、または他の方法でセキュアなクライアント認証ができるクライアント と書いてあり、実際の分類となると Webアプリ : Confidential モバイルアプリ、SPA、デスクトップアプリ : Public となります。 Webサーバーの内部など、ある程度アクセス制限のされた状態で管理されているが、SPAのソースコードやモバイルアプリのバイナリの解析とかによって取得しうるみたいなのは直感的かと思いますが、これだけだといろいろ迷う人がいるらしい、とい
パスワードレスな認証方式やアカウントリカバリーについての振り返り2020
ritouです。 Digital Identity技術勉強会 #iddance Advent Calendar 2020 19日目の投稿です。 急に穴が空いたのでアカウントリカバリーとかの話でリカバリーしましょう。 今年は認証やら本人確認などが騒がしい年でありました。 大きな問題の話はおいといて、自分のブログ記事に書いたぐらいの話を用いて振り返ります。 1. 一般的なパスワード認証 - パスワード = メール/SMSを用いたパスワードレス認証? bosyuがTwitter/Facebookのソーシャルログインに加え、メールでリンクや認証コード的な文字列を送信、それを検証することでログイン状態とするパスワードレスな認証機能を実装されていました。 bosyuが実装したメールアドレスでの登録/ログイン機能とは!? - r-weblife (追記: ころちゃん氏が関連する記事を書いてました。パスワ
リアルタイム/中継型フィッシングの脅威と人類が取れる対策
ritouです。 絶望 パスワードリスト攻撃への対策として様々なサービスが２要素(段階)認証を導入しているものの、今度はリアルタイム、中継型などと呼ばれるフィッシングにやられるケースが見受けられます。 よく2段階認証で使われている Google Authenticatorのようなアプリで設定したTOTP SMSで送られて来るなんたらコード 机の引き出しにしまっとけって言われるリカバリーコード あたりはこのフィッシング攻撃にやられます。 この辺りが解説されているわかりやすそうなドキュメントもあります。 君達の資格情報は全ていただいた！ | Japan Azure Identity Support Blog WebAuthnなどのFIDOなら大丈夫とありますが、ちょうど今日ブログに書いた "手元のスマホ(で動いてるアプリ)でログイン" の場合はその中でFIDOを使っててもやられます。 2段階/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
