2019年7月9日のtwitterセキュリティクラスタ

7payからアプリの認証の話へ

そもそもスマホアプリ の時代、もはやauthenticationですらないと思うのよね。(何を言ってるかわからねえだろうと思うが。)

スマホでアプリをインストール。初起動し、この時点でサーバと恒久セッションが確立。新規利用登録をして利用開始。このときID・パスワード登録は要らない。そのままサービスを利用できる。アプリを終了させて再びアプリを起動しても、当該恒久セッションが続いて、そのままサービスを利用できる。

問題は、このスマホを紛失したときや、機種変更したとき、初期化する必要が生じたとき、当該セッションは失われるので、サービスを継続できなくなること。
これを解決するための何らかの手段、つまりアカウントを別端末に引き継ぐ方法の提供が求められる。

それはどんな方法でも構わないのだが、ID・パスワーを用いるというのが一つ。
このように、ID・パスワードはログインのための認証というよりも、アカウントを引き継ぐためのキーに過ぎないと、もはや言うべきではなかろうか。スマホアプロにログイン概念など無用なのである。

ログインという発想は、20世紀の昔、1台のコンピュータを複数の人で入れ替わり立ち替わり使っていた文化の名残にすぎない。この文化はWebにも引き継がれた。PCは自分専用ではなく、また、キオスク端末のWebブラウザから使うために、「ログイン」は用意されていたのだ。

そんな流れもあり、Webのステートは一時的なものとの常識が確立された。Webのcookieはクリアされるものであり、クリアされてもサービスできるようにWebアプリは作らなければならないという固定観念が成立した。しかしそれはWebの文化にすぎない。スマホアプリがそうする必要はないのである。

実は、Webでも同じことをやってよい。いまどき、PC(のOS)は(マルチユーザなので)一人ひとりに専用になっているのだから、初回接続・利用登録時の恒久セッションを維持したまま使い続けていいのだ。何らかの都合でcookieが失われたときの手段さえ提供しておけばよい。

そのような復元の手段(アカウントの引き継ぎ手段)は、登録済みメールアドレスへのワンタイムキーを含むURLの送信で可能だ。受信したメールのURLを開くとセッションが回復する。
これは視点を変えれば、パスワードリマインダと等価である。むしろ、リマインダはアカウント復元機能だったのだ。

この復元手段は、登録済み電話番号でも可能だ。SMS送信するもよし、自動架電の音声読み上げもよし。ワンタイムコードを盗聴されず本人だけに届け(られるのを前提に)入力させることでセッションを回復できる。
これは視点を変えると、二段階認証の電話パートと等価である。むしろ復元機能だったのだ。

電話番号もメールアドレスも変わってしまうユーザもいるだろう。なので、初回登録時に、アカウント復元コード(100ビット程度の数字)を発行して表示し、印刷して金庫にしまうなり保管せよと指示しておけばよい。もはやユーザが決めるID・パスワードの出る幕はないのである。

復元コードは慣れないうちは無視される恐れがある。しかし、ID・パスワードの登録のないサービスが当たり前になると、保管しておくことの重要性が理解されるようになる。
今すぐ使いたいのにまずパスワードを決めろと言われて安易なものにしてしまう現状よりよほどよい。復元コードは後で確認できる。

天動説で始まったWebは、パスワードリマインダや秘密の質問といった、逆行運動があった。これをスマホアプリ時代の地動説の視点で見れば、上記の通りシンプルに周転しているだけなのである。7payの設計は、天動説のままであったが故に、破綻したリマインダを設けてしまった。

(ただし、上記の例には、メールが途中で盗聴されないこと、SMSが盗聴されず本人確実に届くことなどの前提があり、本当にそれでいいのか?と割り切れないところがある。しかし、天動説のリマインダーではその割り切りを既にしており、実績も積まれているわけであり……。)

4年前に書いた記事。同じことを言っているが当時よりだいぶ研ぎ澄まされてきた。
web.archive.org/web/2015030200…

ログインのユーザ認証には、端末(ブラウザ)を勝手に他人が触り得るリスクを想定して、利用を終えたらログアウトすることで解決する機能も同時に含まれていた。スマホアプリの今日では、それは端末のアンロック機能や、アプリに追加のローカル認証(生体認証やPIN)が担い、機能が分離されている。

複数のアカウントを使用するアプリ(Gmailとか)なんかは、「1台のコンピュータを……」と同じ構造のように思える。同一人物でも複数のペルソナ(?)が入れ替わり立ち替わり使う、みたいな。逆に、旧来のログインもアカウントを引き継ぐためのキーと言えるように思える。 twitter.com/HiromitsuTakag…

twitter.com/MizunoMe_ppc/s…
複数アカウントを切り替えて使うのが本質的なサービスでは、アプリ自体が複数アカウントを同時使用できるように設計されるべき。Webブラウザと異なりそれは簡単にできる。

天動説設計から地動説設計へ:7payアプリのパスワードリマインダはなぜ壊れていたのか(序章)- 高木浩光@自宅の日記(2019年7月8日)
takagi-hiromitsu.jp/diary/20190708…
7payの方式はなぜ許されないのか、なぜあんな設計になってしまったのか、どう設計するのが正しいのか、急ぎ書かなくてはいけないのだが… pic.twitter.com/ULBbk1zEmB

googleのパスワード管理機能で自然とこれに近い運用になっている。現在の懸念は、googleからアカウントのバンされる可能性があること… / “高木浩光@自宅の日記 – 天動説設計から地動説設計へ:7payアプリのパスワードリマインダはなぜ壊れていたのか(序章)” htn.to/22W4pxbCEa

確かにパスワードはもはや不要な段階に来てると思う。真面目にサイトごとにパスワード変えると覚えきれないから、ブラウザの記憶だよりになってしまう。 / “高木浩光@自宅の日記 – 天動説設計から地動説設計へ:7payアプリのパスワードリマインダはなぜ壊れていたのか(序…” htn.to/2dngbuzhrD

そもそもパスワードってのは同じ端末を複数人で利用する前提でログアウトとペアになってる設計。専用の端末を持てるなら不要。 / “高木浩光@自宅の日記 – 天動説設計から地動説設計へ:7payアプリのパスワードリマインダはなぜ壊れていたのか(序章)” htn.to/i7jivcacYE

高木浩光@自宅の日記 – 天動説設計から地動説設計へ:7payアプリのパスワードリマインダはなぜ壊れていたのか(序章)
takagi-hiromitsu.jp/diary/20190708…
去年ぐらいからユーザーにパスワードを設定させるのに限界があるとは考え始めていたなぁ。ただサーバーから割り当てられるパスワードに法則性があるとダメ

1年に1回しか使わないサイトのパスワードはたいてい忘れているので、パスワード忘れ→メール→再設定をしている。もうこのサイト、メール受け取ったらログインでいいよなって思うことある。 / “高木浩光@自宅の日記 – 天動説設計から地動説設計へ:7payアプリのパスワード…” htn.to/4nHdXXfNcB

固定パスワードがある種のハンドルネーム的だった感覚、わかるw。あとは、この時代から変わった辺りとして、パスワード管理アプリとかが結構増えて来た感が(アレはアレで、マスターパスワードは残るのだけど) / “高木浩光@自宅の日記 – 天動説設計から地動説設計へ:7pay…” htn.to/2Ev9BetVhr

AppleやGoogleは2-Step AuthenticationとMulti Factor Authenticationとを区別してる。あとスマホであればUXを犠牲にせずMFAを実装できるので、単に技術がないか工数をケチっただけっぽいな / “いまさら人に聞けない『 #二段階認証 』とは?(神田敏晶) – 個人 – Yahoo!ニュ…” htn.to/TKUnKzzsug

@masanork スマホのみで閉じたシステムであればそうでしょうが、PCでアカウント登録してスマホを割り当てるようなケースもあるので、MFAを「必須」にはできないのでは? オプションとしてMFAを実装する話ですか?

@ockeghem 少なくともスマホアプリをサポートした時点でIDの設計を見直す必要があったと推察します。またMFAの定義次第ではありますが、普段使っている環境とは別の場所、ブラウザからログインした場合にリスクベース認証が発動する実装はPCでも一般的ですよね

@ockeghem いずれにしてもスマホアプリをリリースした段階で、あのID仕様はあり得ないですね。当初からOmnichannelを標榜するくらいなんだからリリース当初からスマホアプリに対しても適切に設計すべきでした

放っておくとエセ専門家が際限なく適当な事を言い続けるので一銭の得にもならないのに慎重に適当なこと言わないように真面目に検証して表現にも気を使ってあれこれ書いてんのに素人や一般市民やエセ専門家がそれを引用して際限なく適当なこと言い続けるので

セキュリティ施策は「何も問題が起きない」という状態がベストなため、効果の測定が難しいという問題があります。
良い施策が評価されないだけでなく、逆に、なんとなく安全そうというだけで安全性が向上しないような施策が受け入れられてしまうこともあります。

話題のQR決済不正利用。ペイペイはペイペイ側に多少の非はあるにせよいわば単純なクレカの悪用(クレカ持ってれば悪用される危険は常にある)。対してセブンペイはそもそものIDパスワード設定の仕組みが脆弱すぎる、いわば基本がなってないことが原因と推測されます

asahi.com/articles/ASM76…

決済事業者に不正防止の誓約書要求 経産省、セブンペイ問題受け
sankei.com/politics/news/…

→セキュリティー対策が不十分であれば、経産省は事業者登録を認めない方針
→不正防止対策が不十分だった場合、10月の消費税増税時のキャッシュレス決済によるポイント還元事業者の登録を取り消す

セブンペイでの大規模な「不正アクセス」の半年以上前に起きたペイペイでの「不正利用」。その違いと、今回のセブンの問題点を解き明かします。

セブンペイとペイペイ、狙われた隙は何が違う?問題点は:朝日新聞デジタル asahi.com/articles/ASM76…

【7pay事件】被害者・めるかばさん @methuselah3 に経緯を伺いました/7pay不正利用、セブンイレブンから情報漏えいか…セブンのセキュリティは極めて脆弱(ビジネスジャーナル) biz-journal.jp/2019/07/post_1…

その他に気になったことはこのあたり。

ATMを狙ったマルウェアを発見したけど、よく調べてみるとセキュリティ会社がペンテスト目的で作ったものでした。ATMを狙ったマルウェアが見つかると、同じ仕組みのツールを作って検証してるんですね。 pic.twitter.com/eKykl5PEy0

ビジネスロジックの脆弱性診断ってビジネスロジックの理解がないと難しいのよね。ワークフローのアプリで承認してるのに自由に編集できるとかは仕様知らなくても見つけられるけど、たまに承認終わってるのでも自由に編集可能というアプリもあったりするので、なんともはや

証券系のシステムなんかはとっても仕様がややこしいし。当然仕様書なんてもらえないし・・・

昔はカードで支払いするとカード番号全桁がレシートに書かれてたと思う。でも、開発するシステムのことしか見てなくて、カード番号は本人しか知らないという前提でシステム設計するとレシートから漏洩したカード番号で決済できるみたいなことも起こるわけで。

はてなブログに投稿しました #はてなブログ
TwitterのスパムDM「ONLY FOR YOU」についてまとめてみた – piyolog
piyolog.hatenadiary.jp/entry/2019/07/…

そう見えるのかもしれませんがちょっと違うような>「スミッシング」が拡大する気配

ここ数年は一部の大規模な仕掛け人がSMSを使うか使わないかに左右されていて、全体的な拡大傾向は見られません。昨年から今年にかけては、宅配便や携帯キャリア系グループが突出し、ほかはボチボチでしょうか。 twitter.com/taku888infinit…

佐川急便のフィッシングを仕掛けているMoqHao組が偽ヤマト運輸の中国版「黑貓宅急便」の営業を始めたようです(誘導手段は不明)。Android端末にはsmartcat.apkを投下、iOSはAppleの偽サイトに転送する、偽佐川急便と同じ手口です。 pic.twitter.com/qAiPw7WMUk

【ご注意頂きたいお知らせ】
PayPayをご利用頂きありがとうございます。

お互いにPayPay残高を送りあうと約束し、実際には、送り返さないという事例が確認されています。

Twitter等で見知らぬ人とのPayPayリレーはお控え下さい。

トラブルにつながる可能性がございます。paypay.ne.jp/notice/2019070…

2020年2月14日開催の制御システムセキュリティカンファレンス 2020が、講演者募集(Call for Presentation)開始。制御システムセキュリティ全般から講演テーマを募集。皆様のご応募を心よりお待ちしております。^YK jpcert.or.jp/event/ics-conf…

漫画村管理人の1人、星野ロミがフィリピンで逮捕されたとの報道。報じているのはフィリピンの放送局ABS-CBN https://t.co/7s2zt2XD8B

日本への引き渡しも

海賊版サイト「漫画村」運営者がフィリピンで拘束 現地メディアが伝える nlab.itmedia.co.jp/nl/articles/19… @itm_nlabから pic.twitter.com/rcAhjBEDqe

「漫画村」元運営者を比で拘束 香港行きの途中、強制送還へ ift.tt/2XxfiOF

SECCON Workshop広島開催概要を公開します! – SECCON2019 seccon.jp/2019/seccon201…

自宅セキュリティ研究所

自宅セキュリティ研究所 wrote 2681 posts

Tags

Post navigation


コメントを残す

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes:

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>