認証
このタグの記事 7 件
パスワードリセットの設計欠陥 — 認証を固めても、ここが弱いと全部通る
リセット機能は『パスワードを知らない人に、パスワードを作らせる仕組み』＝それ自体が認証経路。だから認証本体をいくら固めても、リセットが弱ければそこが実際の認証強度になる。壊れる型は5つ——推測できるトークン／失効しないトークン／メールに残り続けるリンク／リンクの宛先を外から差し替えられる（Hostヘッダ）／応答の差でアカウントの存在が分かる。OWASPが明示している要件と、仕様が数字を決めていない部分（長さ・期限）を分けて扱うのが実装の勘所。
レート制限と濫用対策 — 「回数を絞る」だけでは、総当りもコスト暴走も止まらない
レート制限の失敗は『緩すぎ』より『問いを立て違えた』ことで起きる。設計に必要な問いは3つ——誰を数えるか（IPは偽装され得るので、何を識別子にするかが先）、何を数えるか（回数だけでなくコスト・サイズ・件数）、上限に達したらどうするか（拒否は正規利用者へのDoSにもなる）。NISTは連続失敗100回までを上限としつつ、遅延やCAPTCHAで正規利用者を締め出すなと明記。OWASPはAPIの上限に『支出上限』を含めており、これが金銭被害の最後の砦になる。
ログインを付けただけで安心していないか — 認証と認可の違い
認証＝『誰か』を確かめること、認可＝『その人が何をしてよいか』を決めること。両者は別物で、ログインを付けただけでは認可にならない。データに所有者（user_id）でのスコープが無いと『ログイン＝全データ閲覧』になる（OWASP最上位の Broken Access Control）。さらに認証スキャフォールドの登録開放が重なると、第三者が登録して中に入れる。守りは、全クエリを所有者で絞る／不要な登録を閉じる／多層防御／監査・アクセスログを事故る前に／新規登録を検知。
パスキーとは — パスワードを使わない、盗めないログインの仕組み
パスキー＝共有秘密（パスワード）を持たないログイン。端末内の秘密鍵＋生体認証で署名し、サーバは公開鍵しか保存しない。だから漏れても悪用できず、偽ドメインでは署名が成立しない＝フィッシング耐性が構造的に高い。パスワード＋SMSコードより安全で、移行は重要アカウントから段階的に進めるのが現実的。
パスワードの安全な保存方法 — ハッシュ化とソルトの正しいやり方
サービス側でパスワードを安全に保存する実践ガイド。平文・暗号化・素のハッシュがなぜダメかを理解し、『ユーザーごとのソルト＋わざと遅い専用ハッシュ（Argon2id推奨、次点bcrypt/scrypt）』に集約する。自前実装せず標準関数を使い、コストは定期的に見直し、既存の弱いハッシュはログイン時に再ハッシュして移行する。
パスワードのハッシュ化とは — 元に戻せない一方向変換で安全に保存する仕組み
パスワードのハッシュ化＝元に戻せない一方向変換でパスワードを保存する方法。平文保存はNG。暗号化と違い復号できないのが利点。ただしMD5/SHA-256を素で使うとレインボーテーブルや総当たりで破られる。正解は『ユーザーごとのソルト』＋『わざと遅い専用ハッシュ（bcrypt/Argon2/scrypt）』。自前実装せず標準ライブラリに任せる。
JWT（JSON Web Token）とは — 署名付きの通行証の仕組みと安全な使い方
JWTは、サーバが署名して発行する改ざん不能な『通行証』。header.payload.signatureの3部からなり、サーバは署名で本物か検証する。要注意＝①署名を必ず検証し期待するalgを固定（alg:none拒否）②中身は誰でも読めるので秘密を入れない③有効期限を短くし失効戦略を持つ。デコード（中身を読む）と検証（署名で本物か確かめる）は別物。