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