レッスン 1-5

認証の仕組み

パスワード、セッション、トークン、パスキーは、守る範囲が違います。

目安 60 分トラック 1 基盤の 5 本目

読み終えたらパスキーがフィッシングに強い理由を、ドメインとの結び付きから説明できる

この頁の流れ

1なぜ通るのか
2脆いコードと直したコード
3ログでの見え方と検知
4直し方と確かめ方
5関わる事例
6確認クイズ
7説明課題
8一次資料
9次へ

パスワードは速いハッシュではなく、ソルトと手間を足した方式で保存します。ログインのあとはセッションの番号が本人の代わりになります。多要素認証でも、打ち込む型の確認コードは偽のサイトに中継されます。パスキーはドメインに結び付いているので、偽のサイトでは使えません。記録での見え方と、直ったことの確かめ方までを扱います。

出典を確かめた日 2026年10月24日

なぜ通るのか

小さな通販の画面に、ログインを付けるとします。決めることは 3 つあります。パスワードをどう保存するか、ログインしたあとの人をどう覚えておくか、パスワードのほかに何を確かめるかです。

どれも「ここが守られているはず」という前提の上に立っています。前提が 1 つ崩れると、ほかが正しくても入られます。

パスワードの保存

保存したパスワードの表は、いつか漏れる前提で作ります。漏れたとき、攻め手は手元で候補を次々にハッシュ (元に戻せない要約) にして、表の値と照らします。

SHA-256 のような速いハッシュは、この照らし合わせも速くします。OWASP の Cheat Sheet は、速いハッシュはパスワードの保存に向かないとしています。NIST SP 800-63B も、パスワードはソルト (人ごとに違う乱数) を足し、手間の大きさを決めた方式でハッシュにするよう求めています。

OWASP が勧める設定は次の通りです。

方式	最低限の設定
Argon2id	記憶 19 MiB、繰り返し 2、並列 1
scrypt	手間 2^17、塊 8、並列 1
bcrypt	手間 10 以上。入力は 72 バイトまで

セッション

ログインに通ると、サーバーはセッションの番号を渡し、以後はこの番号で本人を見分けます。つまり番号を持っている人が本人です。

OWASP の Session Management Cheat Sheet は、番号には少なくとも 64 ビットの予測できなさを持たせ、ログインなどで権限が変わったら番号を作り直すよう勧めています。作り直さないと、ログインの前に誰かが渡した番号が、そのまま本人の番号になります。

多要素認証とパスキー

リスト型攻撃は、よそで漏れた ID とパスワードの組を、別のサイトで試す攻撃です。パスワードの使い回しがあると通ります。OWASP は、多要素認証 (パスワードのほかにもう 1 つ確かめる仕組み) を、これに対する最も強い守りに挙げています。

ただし NIST SP 800-63B は、確認コードを人が打ち込む型は、フィッシングに強いとはみなさないと定めています。打ち込んだコードは、どのサイトとのやり取りかに結び付いていないので、偽のサイトがそのまま本物へ中継できるからです。

パスキー (WebAuthn という仕様の鍵) は、この結び付きを持ちます。

鍵は登録したサイトの名前 (RP ID) ごとに作られ、ほかの名前では使えない
RP ID は、開いているページのドメインか、その上位のドメインに限られる
ブラウザは、署名する中身に開いているページの住所 (origin) を入れる
サーバーは origin と RP ID の要約が自分の物かを確かめる

偽のサイトは名前が違うので、本物の鍵を呼び出せません。NIST はこの性質を「確かめる側の名前への結び付き」と呼び、WebAuthn をその例に挙げて、フィッシングに強い方式に数えています。

脆いコードと直したコード

ラボの中の小さな関数で比べます。Python に付いている hashlib、hmac、json だけで動き、外とは通信しません。

速いハッシュか、ソルトと手間を足すか

脆いコード速いハッシュで保存する

def store(pw):return hashlib.sha256(pw.encode()).hexdigest()

直したコードソルトを足し scrypt で保存する

def store(pw):salt = os.urandom(16)h = hashlib.scrypt(pw.encode(), salt=salt,n=2**17, r=8, p=1,maxmem=2**28)return salt + h

2 人が同じパスワード「haru-no-umi」を選ぶと、脆い方は同じ値を保存します。表を見るだけで、同じパスワードの人が分かります。直した方はソルトが違うので、値も違います。手元で測ると、SHA-256 は 1 回 1 マイクロ秒に満たず、scrypt は 1 回 0.2 秒ほどでした。1 つの候補を試す手間が、数十万倍になります。照らすときは、同じソルトで計算し直し、hmac.compare_digest で比べます。

origin を見るか、見ないか

パスキーのログインで、サーバーが受け取った中身を確かめる所です。本物の確かめでは署名も確かめますが、ここでは省き、結び付きの確かめだけを見ます。

脆いコード種類とチャレンジだけを見る

def verify(cdata, auth, chal):c = json.loads(cdata)return (c["type"] == "webauthn.get"and c["challenge"] == chal)

直したコードorigin と RP ID も見る

def verify(cdata, auth, chal):c = json.loads(cdata)rp = hashlib.sha256(RP_ID.encode()).digest()return (c["type"] == "webauthn.get"and c["challenge"] == chaland c["origin"] == ORIGINand auth[:32] == rp)

ORIGIN は https://shop.example、RP_ID は shop.example です。似た名前の shop-example.test で作られた中身を渡すと、脆い方は通し、直した方は止めます。WebAuthn の仕様は、origin が期待した物か、RP ID の要約が合うかを、サーバーが確かめる手順に入れています。

ログでの見え方と検知

リスト型攻撃は、1 つのアカウントに何度も試すのではなく、多くのアカウントに少しずつ試します。ログインの記録には、たとえば次のように残ります。

記録ログインの失敗の記録

login_failed user=u1021 src=lab-alogin_failed user=u2307 src=lab-alogin_failed user=u0815 src=lab-alogin_ok     user=u3342 src=lab-a

1 人ずつ見ると失敗は 1 回で、ロックの決まりに当たりません。送り元ごとに、何人のアカウントに試したかを数えると見えます。守る側は次を見張ります。

見る物	なぜ効くか
送り元ごとの、試したアカウントの数	リスト型攻撃は人数に出る
失敗が続いたあとの成功	当たった組の印になる
origin が合わずに止めた数	偽のサイトの中身が届いた印になる
多要素認証の例外のアカウント	例外は入口の一覧として持つ

直し方と、直ったことの確かめ方

自分の PC の中だけで行います。外のサービスや、他人のアカウントには向けません。

作業用のフォルダで、利用者の表を持つ小さなログインの仕組みを動かす (待ち受けは 127.0.0.1)
脆い store で 2 人に同じパスワードを登録し、表の値が同じになることを確かめる
直したコードに置き換え、値が違うこと、正しいパスワードでだけ通ることを確かめる
ログインに通ったら、セッションの番号を作り直すようにする
下の試験を足し、直す前のコードに戻すと試験が落ちることも確かめる
終わったら、作業用のフォルダごと消す

Python直ったことを固める試験

def test_same_pw_differs():assert store("haru") != store("haru") def test_other_origin_rejected():cd, ad = make("https://shop-example.test","shop-example.test")assert not verify(cd, ad, "abc")

試験は「同じ入力で、直す前は通り、直したあとは止まる」ことを固定します。

すでに速いハッシュで保存している表は、次のログインのときに正しいパスワードから作り直して入れ替えます。多要素認証は、例外のアカウントを作らないことから始めます。

関わる事例

アスクルでは、2025年10月に、多要素認証を例外的に適用していなかった業務委託先向けの管理者アカウントの ID とパスワードが漏れ、不正に使われました。同社は、検知の 5 日後までに管理アカウントへ多要素認証を適用しています。

Colonial Pipeline では、2021年5月に、使われていないはずの古い VPN (社外から社内の網へつなぐ仕組み) のプロファイルが悪用されました。その VPN には多要素認証が無く、パスワードだけで通ることを、CEO が上院の公聴会で認めています。

Change Healthcare では、2024年2月12日に、盗まれた認証情報で遠隔接続の窓口に入られました。親会社の CEO は、その窓口に多要素認証が無かったと下院の公聴会で証言しています。

KADOKAWA では、2024年6月の被害について、フィッシングなどで従業員のアカウント情報が盗まれたことが根本原因と推測されています。経路と方法は分かっていないと、会社が公表しています。

4 件とも、盗まれたアカウントの情報で入られています。そのうちアスクル、Colonial Pipeline、Change Healthcare の 3 件は、入口に多要素認証がありませんでした。例外を作らないことと、打ち込む型より強い方式を選ぶことの両方が要ります。

確認クイズ

1 問目

ログインに、スマートフォンに届く 6 桁の確認コードを足しました。偽のログイン画面に誘われた利用者は、どうなりますか。

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。

2 問目

パスワードの保存の方式として、OWASP の Cheat Sheet が勧めるのはどれですか。

答えだと思う選択肢を押すと、その場で正誤と理由が開きます。

説明課題

次のことを、自分の言葉で 3 行にまとめてください。書けたら、このレッスンは修了です。

パスキーがフィッシングに強い理由を、ドメインとの結び付きから

あなたの 3 行

模範解答を見る

パスキーの鍵は、登録したサイトの名前ごとに作られ、ほかの名前では呼び出せない。偽のサイトは名前が違うので、本物の鍵で署名させられず、ブラウザが署名に入れる住所でもサーバーが見分けられる。打ち込む型のコードと違い、人がだまされても、答えが偽のサイトとのやり取りに使えない。

一次資料

どれも 2026年10月24日に開いて、題と中身を確かめました。

NIST Special Publication 800-63B (NIST、英語)。パスワードはソルトと手間を足してハッシュにすること、打ち込む型はフィッシングに強いとみなさないこと、確かめる側の名前への結び付き
Web Authentication An API for accessing Public Key Credentials Level 3 (W3C、英語)。鍵が RP ごとに作られること、RP ID の決まり、origin と RP ID の要約を確かめる手順
Password Storage Cheat Sheet (OWASP、英語)。速いハッシュが向かないこと、Argon2id と scrypt と bcrypt の設定
Session Management Cheat Sheet (OWASP、英語)。番号の予測できなさと、権限が変わったときの作り直し
Credential Stuffing Prevention Cheat Sheet (OWASP、英語)。多要素認証がリスト型攻撃への最も強い守りであること
ランサムウェア攻撃の影響調査結果および安全性強化に向けた取り組みのご報告第13報 (アスクル、日本語、2025年12月12日)。アスクルのサイバーセキュリティのページから開ける報告。業務委託先の管理者アカウントに例外的に多要素認証が無かったこと、検知の 5 日後の 10月24日に管理アカウントへ多要素認証を適用したこと
S. Hrg. 117-429 Threats to Critical Infrastructure, Examining the Colonial Pipeline Cyberattack (米上院国土安全保障・政府問題委員会、英語、2021年6月8日の公聴会の記録)。古い VPN のプロファイルの悪用 (CEO の書面の証言)、その VPN が 1 つの要素の認証だけだったこと (質疑での CEO の答え)
Testimony of Andrew Witty, Chief Executive Officer, UnitedHealth Group (米下院エネルギー・商業委員会、英語、2024年5月1日)。委員会の公聴会のページに載る証言書。2024年2月12日に盗まれた認証情報で遠隔接続のポータルに入られたこと、そのポータルに多要素認証が無かったこと
ランサムウェア攻撃による情報漏洩に関するお知らせ (KADOKAWA、日本語、2024年8月5日)。フィッシングなどで従業員のアカウント情報が盗まれたことが根本原因と推測され、経路と方法は不明であること

次のレッスンは「名前解決と信頼の境目」です。人を確かめたあと、機械どうしの通信で「社内だから信じる」がなぜ成り立たないのかを扱います。

次のレッスン 1-6 名前解決と信頼の境目