SMS認証は「もう古い」?泥棒に狙われるあなたの鍵と、最強の防具「FIDO2」の話
こんにちは。セキュリティの世界で長く戦っていると、「なぜもっと早く対策しなかったのか」と悔やむ現場に何度も遭遇します。今日は、皆さんが当たり前のように使っている「SMS認証(スマホに届く6桁の番号)」の危うさと、私たちが向かうべき「次世代の鍵」についてお話しします。
セキュリティは、堅苦しいルールではなく「泥棒との知恵比べ」です。一緒に紐解いていきましょう。
—
1. SMS認証という名の「合鍵を郵送する」行為
皆さんは自宅の玄関に鍵をかけるとき、わざわざ「合鍵を郵便で送ってからドアを開ける」なんてことはしませんよね? それをやってしまうと、郵便を途中で盗み見られた瞬間に家に入られてしまいます。
実は、SMS認証はこれと全く同じことをしています。
なぜSMS認証は危ないのか?
1. SIMスワップ: 悪意のある攻撃者が通信キャリアを騙し、あなたの電話番号を自分のSIMカードに紐付けてしまいます。すると、本来あなたのスマホに届くはずの「6桁の番号」が、攻撃者のスマホに届くようになります。
2. フィッシングの巧妙化: 今のフィッシングサイトは「本物そっくり」です。偽のログイン画面にIDとパスワードを入力させ、その直後に「認証コードを入力してください」と表示させます。あなたが入力したそのコードを、攻撃者が即座に本物のサイトへ入力し、裏でログインを完了させてしまうのです。
いわば、「泥棒があなたの目の前で『その番号、今すぐ教えて』と言っている」ような状況です。これでは防犯になりませんよね。
—
2. フィッシング耐性のある認証「FIDO2/WebAuthn」とは?
そこで登場するのが「FIDO2(ファイド・ツー)」という技術です。これは、「番号をやり取りする」という古い常識を根本から覆します。
「鍵」を渡すのではなく、「署名」で証明する
FIDO2は、あなた自身が持つデバイス(スマホの生体認証や、PCの指紋センサー)の中に「電子的な秘密のサイン(秘密鍵)」を隠し持っています。
- SMS認証: サーバーから送られた「番号」を、ユーザーがサーバーに返す。
- FIDO2: サイト側が「あなたが持っている鍵で、このデータにサインして」と求め、デバイスが「はい、これが証明の署名です」と返す。
ここで重要なのは、「サーバーにパスワードも番号も送らない」という点です。物理的にあなたの手元にあるデバイスがないとログインできないため、遠隔地の攻撃者がフィッシングサイトを作っても、あなたのデバイスの「署名」を得ることは絶対にできません。
—
3. 開発者としてどう実装すべきか?
Webサービスを開発する際、まずは「パスワードのみ」から脱却し、WebAuthn APIを活用した多要素認証の導入を検討しましょう。
実装のヒント(概念的なフロー)
サーバー側で公開鍵を管理し、ブラウザを介してデバイスとやり取りを行います。
// フロントエンドでの認証要求例
// ユーザーがボタンを押した時に実行されるイメージです
async function startAuthentication() {
// サーバーから送られてきたチャレンジコード(なりすまし防止用)
const challenge = new Uint8Array([/ サーバーから受け取ったランダム値 /]);
const publicKeyCredentialRequestOptions = {
challenge: challenge,
allowCredentials: [{
id: credentialId, // 登録済みの認証器ID
type: ‘public-key’,
}],
userVerification: ‘required’, // 指紋認証などを強制する
};
// ブラウザのWebAuthn APIを呼び出す
const assertion = await navigator.credentials.get({
publicKey: publicKeyCredentialRequestOptions
});
// 取得した署名データをサーバーに送って検証してもらう
console.log(“署名が生成されました。これをサーバーへ送信!”);
}
現場のセキュリティ担当者からのアドバイス
最初は全てのユーザーに強制するのは難しいかもしれません。まずは、「管理権限を持つユーザー」や「重要な操作を行うユーザー」から、SMS認証を廃止してFIDO2(パスキーなど)への移行を促すのが、現場での泥臭い、しかし最も効果的な第一歩です。
—
まとめ:一歩ずつ、強固な城を築こう
セキュリティ対策に「これで完璧」という終着点はありません。しかし、SMS認証という「穴の空いた鍵」から、FIDO2という「本人しか開けられない扉」へ切り替えることは、攻撃者にとって最も高い壁になります。
まずは、皆さんが開発しているアプリケーションの「認証設定」を見直してみてください。「なぜこの認証方式を使っているのか?」と問いかけるだけで、あなたのサービスは一歩先の安全を手に入れることができます。
もし実装で悩んだら、いつでもまた聞きに来てくださいね。一緒に、より安全なインターネットの世界を作っていきましょう!
コメント