2022年11月1日、パスワードに代わるオンライン認証のための技術仕様の標準化を推進する非営利団体「FIDOアライアンス」(ファイドアライアンス)に、スポンサーメンバーとして加盟したメルカリ。これまでも、フィッシング詐欺やクレジットカード不正利用などのサイバー犯罪の被害を防ぐため、24時間365日のモニタリング、不正の可能性が高いと判断したアカウントの利用制限、EMV-3Dセキュアの導入、フィッシングサイトの早期検出および閉鎖依頼などに継続して取り組んできましたが、不正犯の攻撃はますます巧妙化する一方なので、より一層の注力が必要な状況であることは間違いありません。
では、このタイミングでFIDOアライアンスへ加盟することの意図はどこにあったのか?それは、メルカリの各種サービスへの「FIDO認証」の実装を推進するのと同時に、FIDOアライアンス加盟企業との連携を深めていき、業界全体への貢献していくことにありました。昨今のパスワードをめぐる状況、FIDOに期待されること、メルカリとして発揮していくべきリーダーシップ…などなど、CISOの市原尚久がファシリテートするカタチで、FIDO認証の実装を推進するメンバーたちにぐぐっとお話しを聞いていきました。テキスト量以上に高い熱量をぜひ感じ取ってください!
この記事に登場する人
-
市原尚久(Naohisa Ichihara)東京理科大学大学院理工学研究科経営工学専攻修士課程を修了。その後、NTTデータ通信株式会社(現 株式会社NTTデータ)にてセキュリティ関連業務に携わる。2015年にLINE株式会社へ入社し、各種セキュリティ課題改善プロジェクトに従事。2022年5月、株式会社メルカリ執行役員 CISOに就任。 -
篠原孝明(Takaaki Shinohara)フリーランスのWebディレクターを経て、2012年にグリー株式会社入社。2014年に株式会社ビズリーチへ入社し、転職メディアを立ち上げる。2017年9月に株式会社メルカリ入社。Director/Head of CREを務め2020年4月より株式会社メルペイへ異動。アライアンスプロジェクト責任者を経て2021年1月に株式会社ソウゾウを設立し、Head of Product就任。2022年7月、執行役員不正対策日本統括就任。 -
田中啓介(Keisuke Tanaka)2007に年三井住友カードへ入社し、不正検知ルール、新しい技術の導入など不正対策やRPA等を活用したオペレーションの業務効率化を主な担当として従事。2020年メルペイに入社し、メルペイ・メルカリの既存サービス、新規サービスに関する不正監視施策や3D-Secure導入、フィッシング対策に従事。直近はマネージャーとしてKYC、TnS Productを担当。 -
大井光太郎(Kotaro Oi)2013年にヤフー株式会社入社。エンジニアチームで、ログインや認証・認可のサービス開発に従事。2022年にメルペイに入社し、PdMとしてIDP領域を担当。 -
狩野達也(Tatsuya Karino)2018年にメルカリに入社し、『メルカリ』のマイクロサービス化に携わる。19年からメルペイのIDPチームにジョインし、現在はチームのTech Leadとして、他のマイクロサービスとのハブ役を果たし、メルカリ・メルペイのIDP領域について未来図を描き戦略策定を行っている。
深刻化するパスワード問題、UXを毀損せずにどう解決するか
──まずは昨今のパスワードをめぐる状況と、FIDOがどのようなものか教えてください。
@ichihara:インターネットがはじまる前、情報システムが世の中に登場したときからパスワードはあって、世の中に脅威が増えてくれば増えるほど、外部の攻撃者にとってのお金儲けの道具になってきた。企業のサーバーから個人情報を盗んだりするのもそうですが、パスワードも一緒に盗めると、その人の資産まで狙えるようになっていった。いまではダークネットでパスワードとアカウント名がセットになって大量に売られているんですね。
そもそも、いくら難しいパスワードにしても覚えられないという問題がありますし、いくら長くしたところで盗まれてしまったら無意味です。しかも難しくすればするほど、同じパスワードをあらゆるところで使いまわしてしまう「パスワードリユース問題」が深刻になってきた。
市原尚久(@ichihara)
つまり、攻撃者側はひとつのパスワードを持っていたら、いろんなところへ攻撃できるチャンスがあるというわけです。こうした負の連鎖がパスワードの世界では起きていて、そこからなんとか脱却しなくてはという動きが2000年代前半からありました。いろんなアプローチがあった中で有効な方法として、例えば生体認証があります。ただ、生体認証には難しさがあって、指紋の情報や顔写真をサーバに置かなくてはならなかった。生体認証をサーバに置くことのプライバシーの問題もそうですが、もし一回漏れたら死ぬまで再利用されてしまう情報じゃないですか。それを保守管理するのはコストが高かったので、パスワードに代替されるものとしては普及しなかったんですね。
また、ICカードを使うという方法も検討されました。ICカードは紛失しない限りは認証を正しくできるし、物理的に盗まれない限り攻撃できないわけですけど、まずもって「どうやってICカード配るのか」という問題にはじまり、「ICカードをなくしたときにどうするのか」とか、現実的ないろんな課題があって、政府系がマイナンバーカードみたいなものを配るのとは違い、民間企業ではそこまでのことはとてもじゃないけどできなかった。
そうこうしているうちに、2012年にNok Nok Labsという北米の会社がFIDOの原型になった独自のプロトコルを開発して、次世代の認証技術の標準にしよう、彼らの仕様を標準化するために、FIDOアライアンスが設立されました。
FIDOのプロトコルは、何か特殊な仕組みがあるわけではなく、言ってみれば既に世の中にあった技術の組み合わせだったんです。ただ「サーバーとユーザーで秘密の情報を共有しない」というアイデアが非常にスマートだった。「公開鍵暗号方式」を採用していて、サーバーに置くのは「公開鍵」と言う誰でも見られる鍵で、誰にも見せてはいけない「秘密鍵」はクライアント側に置きます。生体認証の情報もクライアント側にしかないので、サーバー側には盗まれて困る情報は何も置かないという考え方です。
日本だとNTTドコモが、2015年にいち早くFIDOアライアンスに加盟をしていて、私はNTTドコモの当時のFIDO導入プロジェクトに関わっていました。なので、FIDOのことはかれこれ10年近く前から知っていますが、そのときからセンスのいい技術だなと思ったし、これからの標準になると直感していたんですね。だから、LINEに入社したときもFIDOを導入しない理由がないだろうと言ってFIDOアライアンスに加盟しました。それはLINEだけのためではなくて、業界のためというのもあります。FIDOアライアンスで得た知見を業界で共有し、間接的であってもパスワードの問題に貢献することはすごく大事なことだと思った。これはメルカリにおいても同じです。
いま、FIDOには「パスキー(Passkeys)」という、新しい概念が取り入れられようとしていて、パスワードレス認証の仕組みを使い、複数デバイスでも同じようにログインできるというもので、これは私の中でサードウェーブだと思っています。ちょうどこのタイミングで、メルカリとしてFIDOアライアンスに加盟することになりました。こういうコントリビューションを通じて、メルカリの「安心・安全」のバリューを上げていくこともできると思っているので、私はそこにも注力していきたいなと思っています。
──メルカリとしてのポリシーであったり、どうあり続けていくと目指すべき「安心・安全」が実現されていくかを教えていただけますか。
@unryu-in:メルカリはお客さま同士の取引を提供するプラットフォームなので、そこには必ずお金のやり取りが発生します。「メルカリ社」としてではなくて、当然ですが売主に売上金が入ってくる。その中で「安心・安全」なサービス、そして組織をつくっていくときに、なにを改善指標として設定していくのは議論になるのですが、不正に対する補填額を削減していくことがお客さまのために一番わかりやすい目標なんですよね。
ちなみに、不正の補填額はどういうところで発生してるのかというと、CtoC間での配送のトラブルなどもあるのですが、圧倒的にボリュームが大きいのが不正決済です。次いで、フィッシングによるアカウント乗っ取りで、せっかく貯めた売上金を外に持ち出されてしまうことへの補填です。よって、「不正決済」と「アカウントの乗っ取り」が最優先でクロージングしなければならない課題でした。
篠原孝明(@unryu-in)
不正決済はEMV3Dセキュア(3Dセキュア2.0)の実装によって、10分の1以下に激減させることができています。では、フィッシング対策は何を行うのかというと、わりとジェネラルなんですけど2段階で認証するアプローチをやっていかざるを得ない。フィッシングの被害については、メルカリプラットフォームだけがことさら伸びてるわけではなく、IT業界全体で急速に伸びていて、不正犯のやり口も巧妙化してきています。僕や市原さんみたいに常に意識を払ってる人間でも、気を抜くと引っかかっちゃうぐらい巧妙なんですよ(笑)。
SMSの認証や2段階認証など、有効な対策を講じてお客さまをリスクから守れるようにサービス提供者として改善はしているんですけど、いちプロダクトマネージャーとしては「UXの毀損」がどうしても気になるところですよ…。
認証を複数回要求すると、その分お客さまの手間がかかりますが、多くのサービスでも同様に複数回認証を要求するようになってきています。そうなると使用するパスワードにも偏りが出てくるし、パスワードを個別のサービスで変えてしまうともはや覚えられない…そういうすごい当たり前すぎる課題があるので、リスク対策をお客様に委ねるのではなく、特に意識せずともリスクに遭遇しないという体験をメルカリとしてはつくっていきたい。
FIDOはパスワードレス認証なので、まずもってUXが良くなりますし、パスワードを忘れてしまったというケースも基本的には考えなくていい。また、何か情報が漏えいしてしまったとしても、生体情報を使っていないのでフィッシング対策としても有効です。今後、トレンドになっていくことは間違いないでしょう。
しかし、歴史的に見るとFIDOはもう10年ぐらい前からあるにも関わらず、あまり普段耳にしないと思うんですよね。これはおそらくFIDOを導入したことによる、成功事例が表に出ていないからではないかと思います。導入にあたっての懸念となるポイントが想像しづらい状況です。営利企業としてサービスを運営していたら、「FIDOを入れることによるデメリットは何か?」という話は各社でしているはずです。でも、それに対する最適解はまだそんなにないし、少なくとも日本では耳にする機会が少ない。僕らとしては後発であるけど、そこの発信でリーディングカンパニーとなっていきたいので、事例をいろいろ発信していきたい。さらにいうと、僕は同時にUXをとにかく磨き込みたいと考えています。FIDO導入時に、UXアカウントリカバリーにおけるオペレーションをどう組むのが正解なのかを探っていきたいですね。
@ichihara:まさにそう!サードウェーブのリーダーシップをとりたいぐらいの思いを持ってます。
@unryu-in:メルカリグループだけがFIDOでフィッシング対策を強化できましたと言ったところで、ぜんぜん本質的ではないんですよね。そもそもFIDOに限らず、不正の対策って、自社サービスだけを強化してもあんまり意味がないんです。それはなぜかというと、異なるサービスとサービスを掛け合わせたところに不正がよく発生するんですよね。なので、業界全体で対策を強化していくことが肝になってくる。
メルカリプラットフォームにおける不正対策を科学していくだけだと、プラットフォームの中と外のギャップ分析ができないので、できるだけ僕らも事例を積極的に発信していくし、特に国外のサービス事業者との接点をどんどん増やしていって、「海外の先行事例と仕入れながらそれを実装していって、先行事例としてどんどんアウトプットしていって業界全体を底上げしていく動きをとりたいですね。
どこにリスクが潜んでいるか?想像力を働かせて攻撃者にとってのコストを上げる
──では、メルカリにおける独自の課題は?
@ichihara:メルカリのアプリは、CtoCのマーケットプレイスがあれば、ペイメントやバーチャルカード、今後は仮想通貨(メルコイン)など、セキュリティの観点で言うと、全然違うセキュリティ要件が求められるものが1つのアプリの中に入ってるんですよね。アプリ同士が一体型になった中で、FIDOをどうやって最適化していくのかというのは大きなチャレンジだと思っていて、やっぱりメルカリなりの一つの解はいち早く示していくべきだなとと思っています。kei.tさんもunryuin-inさんと同じ目線で不正対策にこれまで関わってきている中で、FIDOに対してはどのような期待感を持っていますか?
@kei.t:フィッシング自体が当社でも半年ぐらい前に多発してまして、ここの問題点はどのような対策をしても、けっきょく手口が巧妙化していきます。また、このコロナ禍でネットで買い物をする人が増えたということもあって、これを機にインターネットを頻繁に使うようになった方々がフィッシングされている状況がありました。
いま、メルカリとしてフィッシングを減少させられてはいるんですけれども、あくまで過渡期の対応の中で減少させられたというところがあるので、また巧妙化してくる可能性は十分あります。そうするとまた、経営のPL(損益計算書)上で圧迫してくる話になります。そうならないために、早めに認証をSMSなどから、FIDOに切り替えていきたいという思いがありますね。
あと、過渡期の対応としてSMSを乱立する形になってしまったので、SMSの通信料などのコストが上がってしまっています。お客さまにとってもいい影響はなく、何をするにもSMSで認証を求められる不便なUXになっていると思ってます。コストリダクションの話と、UXの向上、不正対策の考慮、の3点からもいち早くFIDOを推進していきたいと考えてます。
田中啓介(@kei.t)
@ichihara:メルカリはお客さまの幅がかなり広いので、ケアをしていかなくてはいけない問題ですね。
@kei.t:私自身は、元々カード会社で働いていたので、ご自身が設定しているパスワード以外にも、あとはログインしやすくなるように各種サービスとのID連携がされていたりしたので、パスワードが類推されやすいという課題があって、それを動的なパスワードに切り替えていこうということは、この5年ぐらいずっと言われていますが、なかなか業界全体として進められてないのが現状です。
それはお客様への周知であったりもそうですが、例えばメルペイだとお客さまとのコミュニケーションをアプリで行われるというの馴染んでますけど、カード会社とお客様の接点が必ずしもアプリではないので、生体認証についてどうやって伝えていくのかは課題です。こうした、なかなか進みづらいところをメルカリが率先してやっていくってことの意味はかなり大きいですよね。
@ichihara:先ほど、PLの圧迫の話が出たんですけど、今年の4月の決算発表のときにフィッシングの被害が直接的な原因で赤字になりました。PLの圧迫によって黒字化できなかったというのは、業界的にも目立ったニュースというか、企業活動に深刻な影響を与える問題だというのが世の中にも伝わったんじゃないかと思います。会社として一つの突破口としてFIDOはやっぱり大きな期待ができるのかなと思います。
@kei.t:プロジェクトの課題としては、FIDOが大事だというのは共通認識としてみんなが持ってるんですけど、それを「いつやるのか」というところが結構難しいかなと思っています。不正対策の立場とすると一刻も早くやりたいけど、他の全社的に優先されるべきものからするとどうなのかという議論になりやすいです。いま、足元のフィッシング被害が減ったからで大丈夫じゃないかという見解を持つ人もいるので、これから起こりうるリスクについて伝えながら、このプロジェクトの重要性を継続的に伝えていく必要があるんでしょうね。
あとは私たちがつくっていくプロダクトは、フィッシングリスクをゼロにすることは難しいと思うんですけども、そこで必要なのは想像力じゃないかと思っています。「こうされたら突破されるよね」とか「ここにリスクが潜んでいるよね」とか、メンバーの間でいろんな観点から想像力を働かせて、議論しながら進めていくことが重要かなと思います。
@ichihara:そうですね。フィッシングリスクをゼロにすることは、セキュリティのリスクをゼロにすることとほぼ同じ意味を持ってると思うんですけど、結局のところ攻撃者にとってのコストを上げていくのを続けるしかないという話だと思います。いま、フィッシングが幸いにして減っているのも、メルカリの対策の効果があってです。その努力を続ける中の一つの大きな活動がFIDOだと捉えています。
──ちなみに、攻撃者の傾向というのは、地理的な要因が関係あるものなのでしょうか?国内も国外も同じように巧妙化が進んでいるのか、例えば日本においてはレガシーな産業が遅れていて狙われやすいとか、そういう潮流のようなものはあったりしますか?
@ichihara:サイバーセキュリティ全般的に攻撃者自体の拠点は、日本よりもむしろ海外の方が多いと言えます。レガシーなところや弱いところを狙うというのはおっしゃる通りです。製造業とか病院とか、本業の中心がITではないような業界や企業が狙われているんですね。ただ、それがどれぐらいお金になるのかという話や、攻撃した後のスケールしやすさとかを考えると、やはり大手のアプリのほうが攻撃者にとっては魅力的です。メルカリはユーザー数が多く、ユーザー層も幅広いので常に狙われる立場にあると思いますね。
いま、まさにそうした対策に全力で取り組んでるのが、koiさんとkokukumaさんなわけですが、まずkoiさんからお話しを聞いていきましょう。UXの作り方も含めて、FIDOの鍵みたいな概念をお客さまにどう理解を促そうとしているのかうかがえますか?
@koi:FIDOの安全というものは正規のお客さまが、正規のフローで登録できていることを前提に成り立つ話になりますが、登録に至るまでの認証であったり、認可のタッチポイントを攻撃者が狙ってきます。そこでいかに本人性を高めて、セキュアに登録できるかっていうところを精査していく必要があります。過程にどんなリスクが潜んでいるのかを洗い出すのが難しいところで、懸念を見つけても、一企業だけでは解決が難しいこともあります。そのため、FIDOアライアンスでの動きを筆頭に業界の標準を常にキャッチアップしつつ、考えていかねばならないところだと考えています。
従来の自分たちの実装ではフィッシングリスクがぬぐいきれない部分がどうしてもありましたが、後から出てきた新たなソリューションを取り入れることによって、解決の目処を立てるなど安全のために決断と実装を進めています。このように、エンジニアたちと日々試行錯誤してリスクを潰していきつつ、お客さまに安心して使ってくださいと伝えていくことを目標としています。機能の有効性を説明するガイドであったり、メルカンでの情報発信もそうですけど、啓蒙活動を継続していくことも自分たちの役目だと思っています。また、周知活動もメルカリ単体でやるのではなくて日本でFIDOを利用している企業全体、ひいては世界の団体と一緒に広めていく活動が重要になってくる。それこそが、アライアンスに加盟することの意味だと思っています。
大井光太郎(@koi)
オープンな仕様だからこそ、今後メルカリが貢献していけることがある
@ichihara:ユーザーごとにリテラシーの違いというのもあると思うし、今までどういうふうにメルカリを使ってきたかも人によって違ったりするので、あらゆるパターンを検討していくところの難しさはすごいありますよね。kokukumaさんにもお話しを聞いていこうと思うんですけど、人によっては何度も何度も今SMS認証が要求される状況がありますよね?「さっきSMS認証したんだから、今回はスキップさせてくれよ」という気持ちがお客さまにはあることは容易に想像されますが、FIDOの場合はそこの負担感は減ると想像していいでしょうか?
@kokukuma:「Authenticatorが安全な方法でそのアカウントにbindingされた」ということが大前提になりますけど、その状況であれば、一度どこかのエンドポイントで認証したとか、ログインにおいてFIDOの認証を使ったという情報をもとにして、他の追加認証をスキップさせるということはやりたいことの一つとしてはありますね。
FIDOの導入について、会社として温度感が高まってる要因はメルコインがかなり大きな割合を占めています。FIDO導入するモチベーションは、先ほどichiharaさんが話されたことが一般的には正しくて、どの会社においても否定されるものではないと思うんですけど、実際に「やりましょう」という話になっても一気に進まないと思うんですよね。過去にメルカリにおいてもFIDOを導入しようという話が出てるのですが、結局導入するには至らなかった。セキュリティもいいし、UXもいい、入れない理由ないよねという話をしたとしても、それに対するプロダクト側のモチベーションがあまりなく、実験的な取り組みとして受け取られやすい状態だったかなと思います。
それが去年6月の段階でフィッシングが大きな問題となり、それへの対策がイタチごっこし続けているような状態になっていたため、これを解消するにはFIDOしかないという立ち位置になってきたことが大きい。加えて、当時設計が進められていたこのメルコインにおいて、フィッシング可能な認証要素がベースになっていては、メルコインをお客さまに安心して使ってもらうことができないという話があったからです。どちらかの要因がなかったら、今でも「FIDOを入れたいね」のままだったと思います。
@ichihara:長年FIDOに関わってきて、よく直面してきた問題なんですけど、いわゆる”nice to have”になってしまう問題があります。FIDOによって、間違いなくセキュリティも良くなるし、UXもよくなるんですけども、やっぱりプロダクトをつくってる人たちの視点だと、お客さまにとって、より魅力的なものをつくる方を最優先に行いますから。
FIDOには少しR&Dぽい要素もあるから、それも含めてプロジェクトとしてやっていくんだと旗を振っていくパワーが会社に無ければ、リーディングしていくこと自体が簡単ではない。実際に、ガチャッと取り付けたら全てうまくいくみたいなもんでもなく、いろいろ難しさや課題はあるけど、これだけフィッシングが流行っていて、パスワードの問題がある以上、いまのままで続けるのはもう限界だという認識になってきた。世界的に見ても、W3C(World Wide Web Consortium)のようなインターネットの標準をつくっている団体と、FIDOがアライアンスを組んで、FIDOを実現するためのインターネット標準「WebAuthn」が規定されて、主要ブラウザやNativeアプリ向けのAPIでサポートされている状況です。
「パスキー」という新しい仕様が登場して、まだまだ課題はあるんですけども、こうした問題は大幅に改善しようとしていて、”nice to have”の世界からずいぶんと変わろうとしています。ちょうど今年、MicrosoftとGoogleとアップルが、パスキーについての共同声明的な宣言をしたんですけど、メルカリの中でどう実装するかという話を検討しているところですが、メルカリに導入するときの実装上の課題とかはいかがでしょうか?
@kokukuma:現状の実装は、multi-device credentialやhybrid transportが出る前の状態での実装だったので、Credential / Authenticatorの登録や、2つ目のAuthenticator登録方法とか、そのあたりをパスキー前提に設計し直さなくてはいけない。問題はその既存の鍵なり、既存の環境にいるユーザーを、どうやってそのパスキー使える環境にシームレスにマイグレーションしていくかです。そこは今まさに検討している状況になります。
狩野達也(@kokukuma)
@ichihara:前提のお話をすると、メルコインでFIDOは既に実装していて、それはパスキーというものがない前提の実装になっています。今後、パスキーに切り替えていく方が、いろんなUXの面を含めて当然いいと思います。メルペイについても当然パスキーを前提にする方がいいに決まっていますが、1人の同じユーザーの方が、メルコインでは「パスキー対応する前のFIDO」を使っていて、メルペイの方では「パスキー対応した後のFIDO」になってるというときに、どうやってユーザー体験として、パスキー前からパスキー後にシームレスに使わせることができるかとかは、実装面もそうだし、UX的な面でも課題があります。これらは今のメルカリの事情だからこそ考えなくちゃいけない課題であり、メンバーの間での議論が白熱してるところです。
基本的にFIDOってオープンな仕様だから、攻撃者でも仕様かわかるようになっていますが、それは逆にセキュリティ観点ではとても良い仕様なんですよね。セキュリティでクローズドな仕様というのが一番ダメで、「誰も知らない暗号アルゴリズムは危険」とよく言われるぐらいです。メルカリが悩んで検討してきた作業の結果をこと細かく発信してしまうと、それが攻撃者に抜け道を教えてしまうことになるかもしれないので、そこは気をつけないといけないと思うんですけども、ただ今後メルカリほど大きくない会社でFIDO実装するときに、その労力を減らすための貢献というのができたら、それこそがメルカリができる役割だなと思っているし、それはぜひやっていきたいですね。