2025年の2月ごろから、主に証券会社を中心とする日本の金融機関の顧客アカウントへ大量の不正ログインが発生するようになりました。ログインされてしまうだけではなく、その口座の資金が抜かれたりするなどの実際の被害も確認されています。4月末時点で被害総額はなんと1,000億円にものぼるとのことです。

証券会社各社におけるネットサービスのレベルは高い水準にあったとは言いづらく、二段階認証も必須化されていたわけではありませんでした。実際、二段階認証が設定されていないアカウントが被害のうち多くを占めているようです。とはいえ二段階認証を設定しているアカウントの被害報告も少なくなく、その場合はこちらからどうすることもできないように感じられます。一体どうすればよかったのでしょうか？

今回は初心に立ち返り、現代の主なアカウント認証の仕組みやよくあるハッキング手法について広く扱います。この機会にぜひご自身の各アカウントのセキュリティを見直してみてください。内容は今号と次号で二回にわかれており、前編では主にアカウント認証システムについて詳しく見ていきます。

認証（アカウントログイン）の基本的な仕組み

ITの世界で認証という言葉を使うとき、それは「誰であるかを判別する」という意味で話されます（※1）。平たくいえば「本人確認」のことであり、さらに一般化するなら特定のサービスやアカウントにログインする仕組みそのもの、といえるでしょう。

認証においては「この人は自分がAさんであると名乗っているが、本当にAさんなのかを確かめる」という作業が目的になるので、ログインする側である私たちは様々な方法を使ってこれを証明しようとします。例えば以下です：

・ AさんというIDに対して設定されているパスワードを "知っている" ことで証明とする

・ 既にAさんとして認証済みのGoogleアカウントなどを "借りて" きて再利用する

・ Aさんしか持ち得ない生体情報によって使える鍵を "持っている" ことで証明とする

どの方式を使うにせよ、各サービス側は提出されたこれら情報が適切であるかを厳密に確認し、その結果がOKであれば晴れてログイン成功となります。このままそれぞれの方式についても詳しく見ていきましょう。

単純なパスワード（+データベースに保存）

古来から使われている方式であり、かつ現代の認証システムにおいても（ベースとしては）根強く残り続けているものです（※2）。

パスワードをそのままデータベースに保存していると、もしデータベースの中身が流出したりサーバー内部に侵入されたりした場合にユーザーのアカウントもすべて侵害されてしまうため、パスワードは必ずハッシュしてから保存します（※3）。しかし、それだけでは「password」などの簡単なパスワードがハッシュ化された結果の一覧を持ってさえいれば流出後にユーザーのパスワードを逆引きすることが可能になってしまうため（※4）、「ソルト」というユーザーごとに異なるランダム文字列を付加したうえでハッシュするのが一般的です。

とはいえ、実際にはまだまだ多くのユーザーが非常に単純で安易なパスワードを使用してしまっているのが現状です。そのような状態では上述した一般的な対策の効果もかなり薄れてしまうので、このあとに続く別の認証方式への移行ないしは二段階認証の設定などが推奨されます（その前にすぐさまパスワードを強化すべきですが）。

フェデレーション認証（SSO系）

インターネット上のサービスにログインするとき、「Googleでログイン」などのボタンを見かけたことがあるかと思いますが、あれらはフェデレーション認証やSSOなどと呼ばれる一連の仕組みによって成り立っています。

例えばブラウザでGoogleに既にログインした状態のとき—―これを「セッションがある」などといいますが、ログインしようとする第三者のサービスが「Googleのセッションによって認証も可能です！」という取り決めに則っている場合、Googleが認証した結果をそのまま渡すことによって当該サービスへのログインにも使う、ということが可能になります。

注意点として「フェデレーション認証を選択したからそのサービスでは新規アカウントを作らなくていい」と考えてしまうことがあるかもしれませんが、これはよくある誤解です。そもそもアカウントというものはそのサービスにおけるただの人格の表現でしかなく、どうやってログインするかは完全に別の概念なのです。たしかに新たにパスワードを作成して記憶しておく必要性はひとつだけ減らせますが、それ以外は基本的に何も変わらないと理解しておくとよいでしょう。

パスキー（生体認証、その他）

随分と普及が遅れているのですが、最近になってようやく広まりつつある最新の推奨方式です。実際にパスキーという言葉を認識するようになってきた方も多いかと思います。

これはiOSのFace IDをはじめとする生体認証を使ってそのままログインできるようにするもの…ではありません。実は厳密にはもう少し違う仕組みです。

パスキーは「サービスとユーザーの端末の間における公開鍵暗号」といえます（※5）。パスキーを使ったログインフローをざっくり述べると、①サーバーがその回でのみ使用するためのランダムな文字列（チャレンジといいます）を発行し、②それを受け取ったデバイス側はパスキーとしての秘密鍵を使ってそのチャレンジに署名してサーバーに返送、③あらかじめパスキー登録時にサーバーに保管した公開鍵を使ってその署名を検証する、という流れです。

生体認証は上記フローでいうところの②の部分において、デバイスの秘密鍵を使う権利を得るために使用されます。しかし実際にはこれが生体認証である必要はなく、PINコードでもパターン入力でもなんでもいいのです。重要なのは、サービス提供側にパスワードが保存されていないこと、ログインフローの中でパスワードに相当するようなものを何も送信していないこと、です。

それと、パスキーの認証先がドメインごとに管理されているポイントも見逃せません。つまり、ログインしようとする先が実はユーザーが思っているサイトとは別のもの（悪意のあるサイト）だったとしても、これはドメインが違うのでどうやってもログインできないのです。間違って正規のパスワードを入力してしまうということもパスキーの特性上起こり得ないため、フィッシングサイトに対して高い効力を発揮します。

二段階認証（2FA、MFA）

これは認証方式のひとつではなく別種の概念ではありますが、説明の都合上ここに含めています。

単純なパスワードのみの方式では攻撃が成功する可能性が他の方式より圧倒的に高く、十分な複雑さを持ったパスワードを設定できていない場合は「セキュリティ的に極めて脆弱な状態である」と思ったほうがよいです（※6）。この場合において付加的にセキュリティ強度を上げられる仕組みを二段階認証と呼んでいます。2FA、MFAなどとも言われますが、最近ではこれらは厳密に区別されることはなくなってきており、ここでもすべて同じものとして扱います。

これは「追加の認証ステップを必要とすること」を指し、多くはパスワードとは別の認証方法を用いることになります。例えばSMSやメールに届くワンタイムパスワード（OTP）を入力させる、時間ごとに切り替わる専用のワンタイムパスワードアプリ（TOTP）と連携させる、などがあります。

サービスによっては二段階認証に用いる認証方式をいくつかの選択肢から選べることがありますが、この場合、最初の認証ステップとなるべく関連が薄い認証方式を追加するようにしましょう。例えば、ひとつめの認証方式が「入力したメールアドレスにログイン用URLが発行される」というパターンであるのに、二段階認証でも「メールにワンタイムパスワードが届くようにする」という設定であると、もしメールアカウントが既に侵害されていたらどちらも簡単に突破されてしまい、二段階である意義が失われてしまいます。最初の認証ステップがもし突破されてしまった場合に最後の砦として機能するのが二段階認証であるということですね。

また、冒頭で触れた証券口座乗っ取り問題においてもにわかに取り沙汰されていた点ではありますが、システムの穴をつくことで二段階認証の存在をうまく回避される可能性も否定できません（※7）。例えば顧客の資産を引き出すときに二段階認証のような追加の認証ステップがあったとしても、不正ログインが成功してしまったあとに二段階認証の設定の変更自体を追加の認証なしに実行できてしまう場合、これはバイパスとなってしまい資金は奪われてしまいます。

最後に重要なポイントとして、そもそもの認証方式にパスキーを設定している場合は二段階認証の設定は基本的には不要です。パスキーひとつで二段階認証を設定しているのと同程度の強度が得られますし、事実としてそもそもパスキーの規格上でも「多要素認証である」という評価になっています（※8）。ゆえに多くのサービスではパスキーを設定していると二段階認証はセットできなくなるという設計が増えていますが、もし併用が許容されるサービスならセットしておくとよいでしょう。セキュリティに絶対はなく、多重防護が肝心です。

後編では不正ログインに関する代表的な攻撃例をご紹介したのち、少しでもセキュリティを強化するためにはどうすればいいかを考えます。