ゆめさくセキュリティ

レッスン 1-5

認証の仕組み

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

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

  • 目安60 分
  • 出典を確かめた日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 の中だけで行います。外のサービスや、他人のアカウントには向けません。

  1. 作業用のフォルダで、利用者の表を持つ小さなログインの仕組みを動かす (待ち受けは 127.0.0.1)
  2. 脆い store で 2 人に同じパスワードを登録し、表の値が同じになることを確かめる
  3. 直したコードに置き換え、値が違うこと、正しいパスワードでだけ通ることを確かめる
  4. ログインに通ったら、セッションの番号を作り直すようにする
  5. 下の試験を足し、直す前のコードに戻すと試験が落ちることも確かめる
  6. 終わったら、作業用のフォルダごと消す
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 桁の確認コードを足しました。偽のログイン画面に誘われた利用者は、どうなりますか。

  • ア コードは本物のサイトでしか表示されないので守られる
  • イ 偽の画面が、打ち込まれたパスワードとコードを本物へ中継できる
  • ウ コードは暗号化されているので中継できない
答えと理由を見る

答え イ

打ち込む型のコードは、どのサイトとのやり取りかに結び付いていません。偽の画面は、受け取ったコードを有効なうちに本物へ送れます。NIST SP 800-63B が、打ち込む型をフィッシングに強いとみなさないのはこのためです。

2 問目

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

  • ア SHA-256 に、全員に共通の文字列を足す
  • イ Argon2id に、人ごとに違うソルトを足す
  • ウ 復号できる暗号で保存する
答えと理由を見る

答え イ

速いハッシュは、漏れたあとの照らし合わせも速くします。全員に共通の文字列では、同じパスワードの人が同じ値になります。復号できる暗号は、鍵が漏れればすべて読めます。

説明課題

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

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

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

一次資料

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

次へ

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

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

このレッスンにつながる物