フィッシング対策観点でメールでリンクが送られない世界を目指すために我々は何ができるか

Security Antiphishing email

ritou です

急に寒くなりましたね。

この記事は何の話か

最近のメール経由のフィッシングの話で、

  • その辺のユーザーにとって、メールの送信元が正規のものかどうかの確認は容易ではない
  • さらに、メール本文に含まれるURLの確認が容易ではない

という現状があります。

前者がうまいこと解決されると一番良いんでしょうけれども、そうもいかないのでしょう？ 後者のところでよく「メールに含まれる怪しいリンクをクリックしないでください」と言うのがあります。 そもそも怪しいかどうかがわからないからクリックするわけなので、「怪しい」部分を説明するのも大事なことですが、細けーことは一般ピーポーには無理なので、「メールに含まれるリンクをクリックしないでください」まで振り切る方がいい気がしてます。

しかし、これはこれで

  • サービスはユーザーとのコミュニケーションツールとしてリンクを送る(クリックして欲しい)
  • ユーザーはメールのリンクをクリックせずに、お気に入りなどからサービスにアクセスして内容を確認してください

という不整合が起こり、サービスが期待する処理をユーザーが進めてくれないという事案にもつながりかねません。 こんな状況よりは、

  • サービスがメールを受け取れるユーザーにのみ可能な処理を行わせるためにリンクを送る
  • ユーザーがそのリンクをクリックして処理を続ける

というUXにリスクがある前提で話を進め、

  • メールをコミュニケーションのツールとして捉えるのではなく通知の仕組み程度の用途に止める
  • メールを受けた後にユーザーが適切に処理を継続させられるような誘導ができる世界を目指す

ような変化をしていくという方向性も検討する余地があるのではと思っています。

そこでこんなTweetをしてみました。

我々一般開発者がワーワー声を上げても基本的に何も起こらないもので、セキュリティに詳しい人の集まりでこの辺りが少しでも話題になることがあって何かしらの反応や動きにつながったら良いなと期待しております。

現状に対してこんなことしないといけないのでは？みたいな話はzennの記事で書きました。

zenn.dev

これの続き的な立ち位置で、今回は、 サービスがメールでURLを送ってユーザーがそれをクリックして何かの処理が行われるようなフローをなくすために何が必要なのか をもう少し考えてみます。

そもそもメールでリンクが送られるのはどんな時？

色々あるとは思うんですが、大きく分けて2種類あるかなーと思っております。

  • メールを受け取れるユーザーにだけ次の処理を許したい
    • パスワード再設定リンクを送信
    • マジックリンクでログイン
  • 何かを伝えたい
    • メッセージを受信しました + リンク
    • サービスからのお知らせとか + リンク

他にあったら教えてください。

代替案

メールを受け取れるユーザーにだけ次の処理を許したい : リンククリック -> OTP送信

「メールを受け取ったことを確認したければ、OTPを送ればいいじゃない」 という案です。

OTPを使うと、厳密には「今画面を操作しているユーザーがメールを受け取ったこと」を確認できるのでいわゆる経路外認証としてログインで使われていたりもします。 あと、動線がメール受信後のリンククリックの後にで分かれてしまうのも避けられるので、使い所によってはその後の繋ぎが便利になるかもしれません。 面倒な点といえばOTPのコピペですが、そこはWebOTPで頼む、ということですね。

何かを伝えたい : サービス内コンテンツへの誘導リンク送信 -> お気に入りなどから確認を促す

これもよく言われていることですが、実際は結構辛い気がします。 お気に入りからって言いますけど、お気に入りそんなにちゃんと使われてると思いますか？ ってことで、この辺りもう少しいい感じにできないのかなーと前に思ってたことを思い出しました。

まずはブラウザについてですが、例えば Google Chrome とかだとブランクなページを開くと最近使ってたサービスみたいなのを表示してくれたりしますよね。自分ので試したら Gmail / Twitter / GitHub / 自分のブログ ... みたいな感じでした。これも履歴みたいなもんではありますが、このようにざっくりでいいのでサービス単位の管理ができれば良いのでは？と思います。

その上で、サービスは次のような自サービスのメタデータを定義しておき、そこにリンクできる HTTP Header なり meta タグなりを仕込みます。 メタデータの扱いについてはこれまでもいくつかのWeb標準なAPIなどで利用しているものもあると思いますし、それを束ねる仕組みもできそうです。

あとはブラウザはそのメタデータを読み込みに行ったりキャッシュしたりして、ユーザーを期待するページに誘導可能なのではないか？と言う案です。

  • トップページ
  • お知らせ一覧 : 重要なお知らせがあることをメールで通知しつつここから誘導を試みる
  • ヘルプ / 問い合わせ
  • 利用規約 / プライバシーポリシー : ●●が変わりますメールを送りつつ実態はここから誘導を試みる

画像はイメージです。

なんとなく、こんな感じならお気に入りよりももうちょっとなんとかなるんじゃないか、そうでもないかも、みたいな感じですね。

まとめ

  • フィッシング対策とサービス側の意識の違いなんとかならんか
  • メールからリンクを無くす方法を考えてみた
  • なんだかんだでメールをコミュニケーションツールから通知ツールに格下げしようとしている私をお許しください

以上です。

はてブのコメントどうもです！

サービス登録機能はあるといいなと思うけどiGoogleがまだあれば、ほしかったなと思う気持ちがある

サービス管理のあたりは確かにあの頃欲しかったところですね。

URL入らなくなったらユーザサポートめんどくさくなるなぁという感想。

確かに、ユーザーサポートの負担を上げずに実現できる方法はもうちょっと探っていきたいところです。

今回はメールも通知目的に全振りしてはどうかな話なので、例えば今のSMSで送られる情報ぐらいには最小化できるのでは？ という意図で書いています。

ヘルプデスク的な業務もしてる自分としては、FAQのここ見ろやバーンってURLを送りつける機能は残してもらいたい。

これも同意ですが、バーンと送られ的たリンクをクリックしないでください！みたいな現状は切ないので、正規のサービスとの繋ぎの部分はもう少し考えていきたいところです。