0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

なぜパスワードは「もう十分ではない」のか

0
Posted at

少し前、友人のエンジニアがこんなことを言っていた。「パスワードマネージャー使ってる?使ってないなら、もう遅いかもしれない。」

半分冗談のように聞こえたが、実際には冗談ではない。

2023年、IPA(情報処理推進機構)が発表した「情報セキュリティ10大脅威」では、不正ログインと認証情報の漏洩が引き続き上位にランクインしている(出典: IPA, 2023)。マイナンバーカードの普及やeKYCの整備が進む一方で、パスワードによる認証だけでは防ぎきれない攻撃が増えている。

なぜパスワードは「もう十分ではない」のか。開発者の視点で整理してみる。

パスワードの根本的な問題とは

パスワードの弱点は、その仕組みにある。

ユーザーが設定したパスワードは、サーバ側にハッシュ化されて保存される。理論上は安全に見えるが、実際にはいくつかの経路で漏洩する。

①クレデンシャルスタッフィング攻撃 — 他サービスで流出したID・パスワードの組み合わせを、自動ツールで大量に試す手法。同じパスワードを複数サービスで使い回していると、一か所の漏洩が連鎖する。

②フィッシング — 本物そっくりのログインページに誘導し、入力させる。技術力がなくてもできるため、件数が多い。2022年の警察庁の報告によると、フィッシングによる被害件数は前年比約2倍に増加している(出典: 警察庁, 2022)。

③パスワードスプレー — よく使われるパスワード(「Password123」「123456」など)を、多数のアカウントに対して少しずつ試す攻撃。ロックアウトを回避するために件数を分散させる。

どれも、「ユーザーが正しいパスワードを知っている」という前提だけで認証が完了してしまう構造を突いている。

多要素認証(MFA)は解決策になるか

SMSによるワンタイムパスワードは、一定の効果がある。ただし完全ではない。

SIMスワッピングという攻撃手法では、攻撃者がキャリアを騙して被害者の電話番号を自分のSIMに移管する。これが成功すると、SMSで届く認証コードを傍受できてしまう。日本でも、携帯キャリアを装ったフィッシングとセットで使われる事例が報告されている。

TOTPアプリ(Google AuthenticatorやAuthyなど)は SMSよりも堅牢だが、フィッシングサイト経由でリアルタイムに転送される「リアルタイムフィッシング」には対応しきれないケースもある。

つまり、MFAは「パスワードだけよりずっとマシ」だが、「これで完璧」ではない。

パスキーと生体認証の登場

ここ数年で実用段階に入ってきたのが、パスキー(Passkeys)だ。

FIDOアライアンスが標準化したこの仕組みは、デバイス内に秘密鍵を保存し、サーバには公開鍵だけを置く。認証時にはデバイスの生体認証(顔認証や指紋)で秘密鍵を使い、署名を生成して送る。

何が変わるか。

まず、フィッシングが原理的に成立しなくなる。秘密鍵はデバイス外に出ないため、偽サイトで入力を求めることができない。次に、サーバ側に認証情報が残らない。流出してもそれ自体は使えない。

AppleのiCloudキーチェーン、GoogleのパスワードマネージャーはすでにPasskeysをサポートしている。国内でも、NTTドコモをはじめとした主要サービスが順次対応を進めている。

ただし、デバイスを紛失した場合のリカバリや、複数デバイス間の同期については、まだ実装上の課題が残っている。完璧とは言いにくい。

「本人であること」をどう証明するか

認証の問題は、実はもっと根本的な問いに行き着く。「このアカウントの操作者が、登録した本人であること」をシステムがどう確認するか、という問いだ。

パスワードもパスキーも、「正しい認証情報を持っているか」を確認する。だが、「その認証情報が本当に1人の人間に紐づいているか」は別の問題だ。

たとえば、ボットや自動スクリプトが大量に作ったアカウントがパスキーを使ったとしても、それ自体を止める仕組みにはなっていない。

こうした「人間であることの実在確認」という課題に、異なるアプローチで取り組んでいる動きもある。たとえば、World は生体情報を用いた分散型の本人確認の仕組みを開発しており、1人の人間が1つのIDしか持てない状態を目指している。国際的な取り組みではあるが、認証設計を考えるうえで参照できる視点を持っている。

開発者として今できること

では、実装側として何を優先すべきか。

①パスキーの導入を検討する — ライブラリは成熟してきた。WebAuthn APIはモダンブラウザで広くサポートされており、実装コストは以前より低い。

②SMSのみのMFAを再評価する — 利便性とのバランスはあるが、高リスクな操作(パスワード変更、送金確認など)には TOTPまたはFIDO2への移行を検討する。

③セッション管理を見直す — 認証成功後のセッションが長すぎると、トークン窃取のリスクが上がる。アイドルタイムアウトと再認証ポイントの設計は地味だが効果がある。

④漏洩検知を組み込む — Have I Been Pwned APIなどを使い、登録時または定期的にクレデンシャルが流出済みかチェックする。

まとめにかえて

パスワードが「もう十分ではない」というのは、煽りではなく、攻撃手法の進化に対してパスワード単体の防御が追いついていないという話だ。

かといって、すべてをすぐに置き換えられるわけでもない。既存システムとの互換性、ユーザーのリテラシー、リカバリフローの設計など、現実的な制約は多い。

パスキーも、MFAも、生体認証も、それぞれトレードオフがある。「これで終わり」という認証はない。正直なところ、それが今の状況だと思っている。

FAQs

パスワードマネージャーを使えば安全ですか?

かなり改善されます。ランダムで長いパスワードを使い回さずに管理できるため、クレデンシャルスタッフィングへの耐性が上がります。ただし、マスターパスワードの管理とマネージャー自体への不正アクセスには引き続き注意が必要です。

パスキーはスマートフォンを変えたら使えなくなりますか?

iCloudキーチェーンやGoogleアカウントと同期している場合、機種変更後も復元できます。ただし、同期先のアカウント自体を失うと復元不可になる場合があるため、バックアップ手段の確認が必要です。

SMSによる2段階認証は意味がないのでしょうか?

意味がないわけではありません。大多数の攻撃に対しては有効です。ただし、SIMスワッピングのような標的型攻撃には脆弱なため、高リスクな操作には TOTPやFIDO2が推奨されます。

中小規模のサービスでもパスキーは導入できますか?

WebAuthn APIを使えば導入自体は可能です。ただし、デバイスを紛失したユーザー向けのリカバリフロー設計が鍵になります。この部分の設計が甘いと、かえってサポートコストが上がる可能性があります。

生体認証のデータはサーバに保存されますか?

FIDOベースの実装では、生体情報はデバイス内にとどまり、サーバには送信されません。サーバ側には公開鍵だけが保存されます。この点がパスワードとの大きな違いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?