パスワードの新常識8選｜定期変更不要・bcrypt・ソルト

パスワードの常識って、実はここ数年で大きく書き換わったんですよね。

昔の正解を、いまも守り続けている現場は少なくありません。良かれと思って続けているルールが、いまは非推奨だったりします。今回は、常識が逆転するものを8つ集めました。1つでも知らなかったら儲けものです。

① パスワードの定期変更は、もう推奨されていません

「3ヶ月ごとにパスワードを変更してください」——このルール、実は転換済みです。

米国の標準機関NISTのガイドラインは、定期変更の強制を推奨しない方針に変わりました。日本の総務省も同じ方向に転換しています。

理由は、人間の行動です。定期変更を強制すると、みんな「password1 → password2」のような予測可能な変え方をします。付箋にも書きます。結果として、かえって弱くなるんですよね。

いまの推奨は、漏洩の兆候があったときに変える。それまでは強いものを使い続ける。「昔の正解」が現役で残っている代表例です。

② bcryptは、73文字目以降を読んでいません

パスワード保存の定番ハッシュ、bcrypt。有名な仕様があります。

入力の先頭72バイトしか使いません。それより後ろは、無視されます。

つまり100文字の長いパスフレーズを設定しても、73バイト目以降がまったく違う2つのパスワードが、同じハッシュになって両方ログインできるんです。多くの実装ではエラーにもならず、黙って切り捨てられるだけ。

しかも数えているのは「文字」ではなく「バイト」。UTF-8の日本語は1文字3バイトなので、日本語なら24文字あたりで上限です。長い入力を受け付けるサービスを作るときは、この上限を知ったうえで設計する必要があります。

③ パスワードのハッシュには、「遅さ」が必要です

「処理は速いほど良い」——パスワード保存の世界では、逆です。

SHA-256のような汎用ハッシュは、速すぎるのが弱点なんです。攻撃者は盗んだハッシュに対して、候補を秒間数十億回試せてしまいます。

だからパスワード専用のハッシュ（bcrypt、Argon2など）は、わざと計算を遅く・重くする設計になっています。1回の検証に数十ミリ秒かかるようにすれば、総当たりのコストが桁違いに跳ね上がるんですよね。

正規ユーザーは1回だけ、攻撃者は何十億回。この非対称を作るのが「遅さ」なんです。

④ ソルトは、隠さなくていいんです

「ソルトって、秘密にしなきゃいけないんですよね？」——実は、違います。

ソルトはDBにハッシュと並べて、そのまま保存してかまいません。秘密であることに意味はないんです。

役割は2つ。

• 事前計算した対応表（レインボーテーブル）を無効化すること
• 同じパスワードの人が、同じハッシュにならないようにすること

ソルトが無いと、流出したとき「同じハッシュの人たち」が一目で分かって、まとめて破られます。ユーザーごとにランダムなソルトを付けるだけで、攻撃を1人分ずつに分断できるんです。

⑤ 「秘密の質問」は、認証として最弱です

「母親の旧姓は？」「最初のペットの名前は？」

この方式、NISTのガイドラインで使用しないことが明確に求められています。

理由はシンプルで、答えが秘密ではないからです。SNSをたどれば分かる情報ばかりですし、本人が答えを忘れる率も高い。しかも複数のサイトで同じ質問が使われるので、1箇所漏れれば全部に効きます。

「本人しか知らないはず」という前提が、SNS時代に崩れた。仕組みは変わっていないのに、世界の方が変わって弱くなった例なんです。

⑥ パスワード付きzipのパスワードを、同じメールで送る意味

いわゆるPPAP問題です。

zipを送って、直後に同じメールでパスワードを送る。盗聴者は両方とも受け取れるので、暗号化の意味がほぼありません。日本の中央省庁も、この運用の廃止を打ち出しました。

さらに「ほぉー」なのがここで。パスワード付きzipの伝統的な暗号方式は、そもそも強度が低いことが知られています。総当たりに耐えられない古い方式が、いまも互換性のために生き残っているんですよね。

「暗号化した気持ち」と「実際の強度」は別物、という教訓です。

⑦ 記号を混ぜるより、長くする方が強いです

「大文字・小文字・数字・記号を混ぜて8文字」と「小文字だけで16文字」。どちらが強いと思いますか。計算すると、答えが出ます。

桁が7つ違います。パスワードの強さは、文字種の派手さより長さが支配的なんです。

だから現在の指針は「複雑さの強制」より「長さの確保」。2025年に確定したNISTの最新版では、パスワードだけでログインさせる場合の最低文字数が15文字に引き上げられました。覚えられる長いパスフレーズの方が、覚えられない記号8文字より強い、という逆転です。

⑧ 「漏れたか」を、パスワードを送らずに調べられます

自分のパスワードが過去の流出に含まれているか、照合してくれるサービスがあります。

「え、そのサービスにパスワードを送ったら本末転倒では？」——ここが美しいところで。

送るのは、パスワードのハッシュの先頭5文字だけなんです。

サービス側は、その5文字で始まる流出ハッシュの一覧（数百件）をまとめて返します。最後の突き合わせは、手元で行う。つまり相手には、あなたのパスワードを特定する情報が一切渡りません。

k-匿名性と呼ばれる考え方で、「調べたいけど渡したくない」を両立させた設計です。仕組みそのものが「ほぉー」なんですよね。

番外編：今日からできる3つ

使い回しを、やめる
漏洩事故の定番は、他のサイトから漏れたパスワードでのログイン試行（リスト型攻撃）です。強いパスワードでも、使い回した瞬間に「一番弱いサイトの強度」になります。

パスワードマネージャーに任せる
全部を覚えるのは無理なので、覚えるのはマスターパスワード1つに絞る戦略です。サイトごとにランダムな長いパスワードを持てます。

多要素認証は、SMSより認証アプリ
SMSは通信の乗っ取りリスクがあるため、NISTでは制限付きの位置づけです。認証アプリやセキュリティキーの方が一段強いんです。

RJCでも、セキュリティと向き合っています

RJCが携わる保険、金融、決済のシステムは、認証とパスワードの扱いがそのまま信頼になる世界です。

社内では、チーム主催で脆弱性を体験するゲーム大会（CTF形式）を開いたこともあります。攻撃の手口を安全な場で体験すると、守りの設計が具体的になるんですよね。

こういう知識を、Techチームで共有しながら開発しています。

よくいただくご質問

Q. まずどれから見直すべきですか？
A. ①の定期変更かなと思います。社内ルールの見直し提案として、今日から根拠つきで話せるようになります。

Q. 結局、パスワードはどう作ればいいですか？
A. 長さを優先して、使い回さない。この2つが本体です。覚えられる長いパスフレーズか、マネージャーに生成させたランダム文字列がおすすめです。

Q. 自分のサービスでは、どう保存すればいいですか？
A. bcryptやArgon2のような専用ハッシュ＋ユーザーごとのソルトが定石です。自作せず、実績のあるライブラリに任せるのがいちばん安全なんですよね。

Q. 未経験からでも、セキュリティは学べますか？
A. 学べます。今日の8つのように「なぜそうするのか」を1つずつ辿れば、暗記ではなく理解で積み上がる分野です。

昨日の正解が、今日の脆弱性

今日の8つを並べてみて思ったのが、これでした。

定期変更も、秘密の質問も、複雑な8文字も。かつてベストプラクティスだったものが、いまは非推奨になっています。

セキュリティは「一度覚えたら終わり」ではなくて、常識ごと更新し続ける分野なのかなと思います。

みなさんの職場に残っている「昔の正解」、よかったら教えてください。