本記事では、Okta Workforce Identity Cloud (以降、Okta WIC) での「Phishing resistant (フィッシング耐性)」について解説します。 Security > Authentication Policiesで、Rule内のTHEN以下の設定を見ると「Phishing resistant」というチェックボックスがあります。 これを有効にすれば「フィッシング攻撃に耐えられるものだけを認証に使う」という指定なんだな、ということは名称から想像がつくと思います。 また、Oktaドキュメントの「フィッシング耐性のある認証」には、FastPassとWebAuthnとの記載があるので、「それらを使えば、フィッシング攻撃に耐えられるんだな」ということまでは分かります。 言い換えますと、このPhishing resistantを有効にすると、このRuleにおいては、それら以外の認証器 (オーセンティケーター) は使えなくなる、例えばスマートフォンのOkta Verifyプッシュは使えなくなる、ということです。 「パスワードだけじゃダメなのはなんとなく分かるけど、スマートフォンのOkta Verifyプッシュを使ってもフィッシング攻撃を回避できないの？なんで？」というという疑問が沸きますよね？ そこで本ブログ記事では、その疑問解消の一助として、「Phishing resistant (フィッシング耐性)」について解説します。 以降の解説は、以下のブログ記事の内容を実施済み (理解済み) の前提で進めていきます。 はじめてのOkta Workforce Identity Cloud (WIC) トライアル環境の構築 はじめてのOkta Workforce Identity Cloud (WIC) [第1回] ユーザーと認証器の関係を紐解く はじめてのOkta Workforce Identity Cloud (WIC) [第2回] 多要素認証を紐解く はじめてのOkta Workforce Identity Cloud (WIC) [第3回] 「Hardware Protected」って何だ？ フィッシング攻撃とは そもそもフィッシング攻撃とはどういうものなのか、順を追って説明していきます。 パスワードによる認証フロー (IdP-Initiated) まずはシンプルに、ユーザー名とパスワードで認証が成功するまでの流れをご説明します。 アイデンティティプロバイダー (以降、IdP) であるOktaのドメインは、kaisha.okta.com とします。 サービスプロバイダー (以降、SP) は、app.atko.jp とします。 (1) ユーザーAは、Webブラウザで kaisha.okta.com へアクセスします。 (2) kaisha.okta.com から認証フォームが返ってきます。 (3) ユーザーAは、自身のユーザー名とパスワードを入力してSubmitします。 (4) 認証が成功すると、ユーザーAはHTTPステータスコード 302レスポンスでOktaダッシュボードへリダイレクトされます。 (5) kaisha.okta.com からユーザーAにOktaダッシュボードが返ってきます。 (6) ユーザーAは、SPである app.atko.jp にアクセスしたいので、app.atko.jp のアイコンをクリックします。 (7) 既にユーザーAの認証は完了しているので、その証として、kaisha.okta.com からはSAMLレスポンス (SAMLアサーション) がユーザーAに返ってきます。 このSAMLレスポンスには、kaisha.okta.com の秘密鍵による署名が付与されています。 (8) このSAMLレスポンスは、ユーザーAのブラウザで動作するJavaScriptによって自動的にSPである app.atko.jp へリダイレクトされます。(ユーザーAが何かアクションを起こす必要はありません。) (9) SPである app.atko.jp は、SAMLレスポンスの署名をkaisha.okta.comの公開鍵で検証し、それが成功することで、「ユーザーAは kaisha.okta.com でちゃんと認証が成功したんだな」ということが分かります。 (10) 署名検証が成功したので、ユーザーAは app.atko.jp へのログインが許可されましたので、 app.atko.jp の画面がブラウザに表示されます。 以降、ユーザーAは、ユーザーAに許可された app.atko.jp 内のリソースへアクセスできるようになります。 フィッシング攻撃の成立 (パスワードだけの場合) パスワードによる認証フロー (IdP-Initiated) をベースに、フィッシング攻撃の流れを説明します。 IdPであるOkta WICとユーザーの間に攻撃者が割り込む形でフィッシングが成立します。 攻撃者(＝プロキシー)のドメインは kaisha.oktacom.io とします。 (0) 巧みな文章が記載されたフィッシングメールが攻撃者からユーザーAに届きました。ユーザーAは思わず、メールに記載されたURL: kaisha.oktacom.io をクリックしてしまいました。 (1) ユーザーAは、Webブラウザで kaisha.oktacom.io へアクセスしてしまいます。 (1x) 攻撃者は宛先URLを kaisha.okta.com に書き換えて、Okta WICに送ります ＝ ユーザーAとして振る舞います。 (2) kaisha.okta.com から認証フォームが攻撃者へ返ってきます。 (2x) 攻撃者は、ユーザー名とパスワードが kaisha.oktacom.io に返ってくるように認証フォームを書き換えてユーザーAに送ります。.