推奨初期値 — 20 文字、全文字種
length: 20 sets: lower + upper + digits + symbols pool: 87 chars
g7#Lq2!vWp9Bz@Yx5dKr ≈ 128.7 bits (very strong)
新規アカウント全般に対する安全な既定値です。128 ビットはオフラインブルートフォースで数十年単位でも到底届かない領域です。
すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
スライダーで長さを変えるか直接入力し、使う文字種(小文字・大文字・数字・記号)をトグルすると、パスワードが自動で再生成されます。エントロピーバーは結果のブルートフォース耐性をビット数でおおまかに示します。40 ビット未満は弱、60 以上が一般的なアカウントには十分、90 以上は金庫のマスターパスワード相当です。
「曖昧文字を除く」トグルは、フォントによって見分けにくい文字(I・l・1・O・0・o・`・'・"・|)を除外します。画面を見ながら打ち込む場合や電話で口頭で伝える場面で役立ちます。乱数は crypto.getRandomValues から取り、モジュロバイアス防止のためのリジェクションサンプリングで各文字が等確率になるよう調整しています。何もブラウザ外に送信しません。
length: 20 sets: lower + upper + digits + symbols pool: 87 chars
g7#Lq2!vWp9Bz@Yx5dKr ≈ 128.7 bits (very strong)
新規アカウント全般に対する安全な既定値です。128 ビットはオフラインブルートフォースで数十年単位でも到底届かない領域です。
length: 16 sets: lower + upper + digits (no symbols) no ambiguous: yes pool: 52 chars
k7QxR2nbCa3VsT5p ≈ 91.2 bits (very strong)
電話で口頭で伝える場面、スマートフォンで入力する場面、記号を正しく扱えないシステム(一部のレガシー SSO や特定の DB)で使う場面に向きます。
length: 6 sets: digits only pool: 10 chars
482703 ≈ 19.9 bits (weak)
推測回数が制限されている場面(3 回試行で止まる銀行カード、スマートフォンのロック画面)では 6 桁 PIN で十分です。攻撃回数に制限がない相手にはまったく持ちこたえません。
12 文字を超えた段階で、長さは複雑さよりも効きます。レート制限のあるオンラインアカウントには、混合文字種で 16 文字あれば十分です。パスワードマネージャのマスターパスワードやディスク全体の暗号化なら 20 文字以上を目安にしてください。暗号化された塊が盗まれた場合、これらはオフラインブルートフォースに晒されます。
ブラウザが提供する暗号学的に安全な RNG である crypto.getRandomValues を使い、OS のエントロピー源で初期化しています。ブラウザの TLS 鍵生成と同じ生成器であり、現実的な脅威モデルにおいて RNG が最も弱い箇所になることはありません。
いいえ。生成はブラウザ内で行われ、結果はコピーまたはリロードまでページ上にしか存在しません。ログ・同期・保存は一切しません。とはいえクリップボードに入れた時点で漏洩経路が増えるため、コピーした直後に対象フィールドへ貼り付け、クリップボード履歴に残さないようにしてください。
記憶して入力するパスワード(金庫のマスター、ディスク全体の暗号化など)にはパスフレーズが優れています。ランダムな文字列より人間が覚えやすいためです。それ以外のパスワードマネージャに格納するパスワードには、同じエントロピーをより少ない文字数で得られる長いランダム文字列で十分です。
同じ設定で同じ生成器が作りうるパスワード総数の log2 を見積もります。60 ビットなら候補は約 10^18 個で、1 ビット増えるごとに倍になります。実際の攻撃難度はパスワードがどう保存されているかに依存します。高速ハッシュ(MD5・SHA-1)なら攻撃側は秒間で数十億回試行できますが、低速ハッシュ(bcrypt・Argon2)なら GPU 1 枚で秒間数十回程度です。
パスワードの強度は独立した 2 つの要素で決まります。文字列の長さと、各位置に現れうる文字の種類です。対数空間で掛け合わせるとエントロピー(ビット)になり、これは攻撃者が試すべき候補数の log2 です。70 文字プールから 12 文字を引いたパスワードは約 73 ビット、24 文字に倍増させればビットも 146 に倍増します。長さは最も安価な調整つまみで、複雑さは最も過大評価された要素です。
NIST が 2017 年に発表し以後再確認してきた SP 800-63B のルールは、古い助言を明確に廃止しました。定期的な強制変更、文字種混合の必須化(「数字 1 個と記号 1 個を含む」など)、秘密の質問によるフォールバックは廃止です。代わりに、長めの最小長、印字可能な任意の文字を許容、漏洩コーパスとの照合、ログイン回数制限、覚え方はユーザーに任せる、というアプローチです。新規生成したランダムパスワードのエントロピーは、それを保存するパスワードマネージャこそが実体としての対策であることの証拠です。文字列を当てられるよりも、マネージャへのアクセスを失うことのほうが現実的な失敗モードであり、ここを設計で塞ぐ必要があります。
Google Authenticator や 1Password 互換の TOTP(RFC 6238)を生成。base32 シークレットまたは otpauth:// URL を貼り付けるとリアルタイム更新。完全ブラウザ内処理。
鍵とメッセージから HMAC 署名(SHA-1 / SHA-256 / SHA-384 / SHA-512)を計算。hex / base64 出力切替、Web Crypto API でブラウザ内処理。
RSA 公開鍵・秘密鍵ペアを PEM フォーマット(PKCS#1 / PKCS#8)で生成。JWT 署名鍵・SSH テスト・単発の暗号化用。本番鍵は OpenSSL を推奨。
ランダムUUID(v4)をブラウザ内で生成。最大100件まとめて生成可能。
パスワードは crypto.getRandomValues を使ってブラウザ内で生成されます。外部送信はありません。