niyase のパスワード設計 — Passkey を主役に、HIBP・ライブチェックを脇役に、根拠のない記号必須は採用しない

TL;DR

• Passkey を主役にする。パスワードは過渡期のセーフティネット
• パスワードを使う場合は 12 文字 + 大小数字 を要件にする（記号は任意）
• HIBP（Have I Been Pwned）でリアルタイムに漏洩チェック、漏洩済みパスワードはサインアップを block
• ライブ checklist で要件が満たされていく様子を可視化（緑チェック ⇄ グレー丸）
• 記号必須は採用しない：UX を悪くするだけで実効性が薄い

背景：「複雑なパスワード」は古い常識

「8 文字以上で記号必須、90 日ごとに変更」というルールは、長らく業界標準でした。しかしこのルールは、今や 逆効果 だと NIST と OWASP の最新指針が明確に示しています。

NIST SP 800-63B（2017 改訂以降）の方針

NIST のデジタル ID ガイドライン B.4 が推奨しているのは、ざっくり次の方向です：

• 長さを重視（8 文字以上、できれば 15+）
• composition rule（記号 / 数字 / 大文字を必須にするルール）を課さない
• 定期変更を強制しない（漏洩が確認されたときだけ変更させる）
• すべての印字可能 Unicode + 空白を許容
• 漏洩済みパスワードリストとの照合で拒否する

理由は単純で、人間の行動原理に逆らうルールは結果として弱いパスワードを生む からです。

「複雑性ルール」がもたらす逆効果

「大文字 + 数字 + 記号必須、最低 8 文字」を強制すると、ユーザーは次のような予測可能なパターンに走ります：

• Password1! → 「P」を大文字、末尾に「1!」
• Welcome2024@ → 季節 + 年 + 「@」
• 過去パスワード + インクリメント： Spring2024! → Spring2025!

形だけ複雑性ルールを満たしながら、エントロピーは実質的に上がっていません。むしろ覚えにくくなることで使い回しが増え、付箋に書かれ、メモアプリに平文で保存される という二次被害を引き起こします。

「PPAP（パスワード付き ZIP を別便で送るアレ）」も同じ構造です。形式的にはセキュリティ対策に見えるが、実効性は薄く、運用コストだけが高い。

niyase のスタンス

長期ゴールは 「パスワードを使わない世界」。Passkey が普及するにつれ、パスワードは不要になっていきます。それまでの過渡期、パスワードを使うユーザーには次の 3 つで守りを固めます。

1. Passkey を最優先に押し出す

ログイン画面では、Passkey ボタンを最上段に置いて視覚的に勧めます。新規ユーザーには「パスワードを覚えなくていい、フィッシングも防げる」というメリットを伝え、最初から Passkey を登録してもらう導線を用意しています。

なぜ Passkey が圧倒的に優れているのか：

• フィッシング耐性：パスワードはコピペで攻撃側に渡るが、Passkey はドメインバインドなので別ドメインに送れない
• サーバ漏洩時のリスク：パスワードはハッシュが漏れたらクラックされうるが、Passkey は公開鍵しか保管されない（漏れても無価値）
• ユーザーの記憶コスト：ゼロ（生体認証）
• 使い回しの問題：サイトごとに別鍵が自動生成されるので、原理的に発生しない
• MFA 相当：単独で「所有 + 生体」の 2 要素を満たす

2. パスワードの要件は「12 文字 + 大小数字」だけ

GCP Identity Platform の passwordPolicyConfig を ENFORCE で設定し、次の要件を課しています：

12 文字 × 62 種（大小英数字）で約 3.2 × 10²¹ 通り。ハッシュ攻撃でも数兆年スケールで、現実の脅威モデルに対して十分です。記号を必須化しても理論エントロピーは少し増えますが、ユーザビリティ低下と引き換えるほどの差は出ません。

3. HIBP で「既に漏洩しているパスワード」を block

最大の脅威は クラック耐性 ではなく、漏洩済みパスワードの再利用 です。Password1234（policy は通る）でも、すでに過去の漏洩データに含まれていれば、攻撃者が credential stuffing で試してきます。

ここで使うのが Have I Been Pwned の Pwned Passwords API。漏洩データ約 13 億件と照合できる公開 API です。

k-anonymity でプライバシーを守る

HIBP API は k-anonymity 設計で、パスワード自体は外部に送信しません：

1. クライアントが SHA-1 ハッシュを計算（例：5BAA61E4C9B93F3F0682250B6CF8331B7EE68FD8）
2. 先頭 5 文字（5BAA6）だけ を HIBP に送信
3. HIBP は該当 prefix を持つ約 500-1000 件の hash suffix を返却
4. クライアントがローカルで完全照合 → 該当があれば漏洩済み

niyase は クライアントから直接 HIBP API を叩く 設計にしています。niyase バックエンドを経由しません。これによりパスワード派生情報すら niyase インフラに通さない、最強のプライバシー設計になります。

[cloud / desktop / mobile]
    │ 1. SHA-1(password) を client 側で計算
    │ 2. GET https://api.pwnedpasswords.com/range/{prefix5}
    │    （k-anonymity: hash の先頭 5 文字のみ送信）
    ▼
[HIBP API]
    │ 該当 prefix の suffix リストを返却
    ▼
[client がローカルで完全照合 → 漏洩済みなら赤バッジ + submit を block]

4. ライブ checklist で要件を可視化

ユーザーがパスワードを入力するたびに、要件が満たされていく様子を 緑チェック ⇄ グレー丸 で可視化します。HIBP 漏洩チェックも 5 番目の項目として live で表示されます。

パスワード
┌─────────────────────────┐
│ ••••••••••••              │
└─────────────────────────┘
✓ 12 文字以上                ← 緑（達成）
✓ 大文字を含む               ← 緑
○ 小文字を含む               ← グレー（未達）
○ 数字を含む                 ← グレー
○ 漏洩チェック（公開リストとの照合）  ← グレー（4 項目達成後に発火）

policy 4 項目を満たした瞬間に HIBP チェックが debounce 500ms で発火します。短い・弱いパスワードでは HIBP API を叩かないので、無駄なリクエストもありません。

設計判断のまとめ

おわりに

セキュリティ対策は「形だけ強そうに見えるルール」より、実効性のある仕組み を選ぶことが大切です。記号必須を 90 日変更させるよりも、Passkey を勧めて、漏洩済みパスワードを拒否する方が、実際の被害を防ぎます。

niyase は会計業務を扱うサービスとして、規模を問わず同一強度のセキュリティ を提供することを設計原則にしています。一人親方でも大企業でも、Passkey・HIBP・ライブチェックといった現代的な防御が同じように働きます。そして将来的には、パスワードを完全に過去のものにすることが、最終的なゴールです。

関連リンク

• NIST SP 800-63B（Digital Identity Guidelines）
• OWASP ASVS 5.0（Application Security Verification Standard）
• Have I Been Pwned API（Pwned Passwords）
• FIDO Alliance — Passkeys