アカウント名:
パスワード:
［独自記事］7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05498/ [nikkeibp.co.jp]
が分かりやすいです。
ただし、上記記事は、全く異なる2つの脆弱性の話が書かれているので、混同しないようにご注意ください。
【脆弱1 : OpenID Connectのアクセストークン未検証】
OpenID Connectのアクセストークンを検証していなかったので、ID（メールアドレス等）さえわかれば、パスワードが分からなくても、OAuthが成功したことにして他人がログインできる脆弱性があった。あまりにも酷すぎる脆弱性ですね！
【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】
実は、7iD 自体をOpenIDとして、他のサイトにログインすることが可能なAPIを提供していました。ところ、がこのAPIのアクセスコントロールがガバガバで、API経由で他のアプリを含めた広範な個人データ、ハッシュ化されたパスワードなども取得可能だったのです。7iD で信頼できないサイトや脆弱性のあるサイトにログインしたら大変なことになるということです。
脆弱性2については、仕様ともいえますが、まぁ危険ですね。Googleアカウントでどっかのサイトにログインしたら、そのサイトがGoogleアカウントのハッシュからGoogleドライブへのアクセス権やらGmailの送信権やら全取得、しかもAPIのアクセス権設定は無しで全承認しかないとかだったら、大騒ぎですよね。7iDはそういう仕様なのです。
結局のところ、7payは、OAuthの認証が成功したというデータを送り付けるだけで、OpenIDのID(メールアドレス等)が分かるだけでログインできたのでした。
つまり、チャージされた残高は、メールアドレスさえわかれば、第三者が使用可能でした。
そして、登録されているクレジットカードからのチャージには、OpenIDでログインした場合を含めて追加で認証パスワードが必要なのですが、OpenIDでログインした状態ならば画面に表示される、お問い合わせ番号、7iDメアド、nanaco番号（すべてアプリに表示）だけあれば、それもリセットできました。https://twitter.com/ppp_payland/status/1146924240970514432 [twitter.com]
7payの悪用はリスト型攻撃だと言われてましたが、メールアドレスとパスワードのリストではなく、メールアドレスだけのリストで攻撃可能だったのです。
まぁ、リスト型攻撃には変わりないといったら変わりないのですが……。
すげーなー、というしかないなぁ。7payと社長が矢面に立たされ袋叩きにされたけど、実際はベンダーの方の責任の可能性が高いってことか。今後のことを考えると、どこなのか公開して欲しいところ・・・
でも、その成果物を受け取って検収し、サービスインしたのは7-11側なので一義的に責任は7-11側にある。どこがベンダーであっても一緒ですよ。それをもってサービス提供側をを甘やかしてはならない。
確かにそうだが、検証できるだけの技術ある人もいないだろうに。まぁそれが問題なんだけど。
なんで日本の大企業は自分とこで技術者抱えて作ろうとしないんだろ。本当にバカだよねぇ。
脳筋脳花企業では往々にしてシステム屋と言う「何か訳のわからん事をやっている奴ら」は隅っこに追いやられるか、子会社に追放される。
そういう業者に発注したのもセブン側でしょ。
とりあえずモックだけ作って本格実装は後回しにして開発進めていたら、その開発期間では無理です、実装が間に合いませんと問題を申告した技術者が本部の意向で左遷されて、後任のYESマンはなにもわからず本部の言われるとおりにした結果、本番環境でもモックのままサービスインしてしまった．．．みたいなことだって、ありえるんだから。
合言葉は「動いているから良いじゃない」。
責任者が被害しゃぶるのは良くないよ。
苦汁「しゃぶれよ」
あるいは発注者側責任者『何か起きたら全部責任は俺が取る！』と豪語する↓900件5500万円のクラック被害発生、セブングループとコード決済の信用が地に落ちる↓発注者側責任者『』、あるいは他グループ、競合他社に夜逃げ、あるいは首吊り自殺
7iDのAPIは認証通れば、フル住所・生年月日・メールアドレス・電話番号・パスワードハッシュ他、あらゆる情報全取得可能。
証拠https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
認証通っているなら良いのでは？ というのは間違い。だって、7iDのパスワードと追加認証の決済パスワードが同じなら、パスワードハッシュから解析できてしまうし（弱いパスワードはハッシュからでも解析可能）、APIから取得できる情報が、決済パスワードリセットの本人確認情報にもなるので、そこから攻めることもできる。
OpenID Connect (OIDC) 1.0 準拠の分権的な認証プロトコルのオープンスタンダードを採用と聞くと、モダンで最先端なスラド民が喜びそうだが、大した知識がないのにそういう最先端の実装をすると、個人情報も何もかもオープンになってしまうのである。omni7を認証基盤にして、シンプルで最先端でかっこよいシステムを作ろうとして墓穴を掘った感じ。
たいしたスキルも無いのに、オープンソースとか、オープンスタンダードだとか、そういうのを重視する「意識高い系」の人は大迷惑。
最先端のシステム（OpenID Connectやら7iD認証基盤）を導入せずに、素直に独自のIDとパスワードで認証して、初回設定時と新規ログイン時にはSMSで確認コードを送る（二段階認証）という、古臭くてレガシーな仕様にしとけばこんな問題（不正ログインや不正チャージなど）はおきなかった。
画像のURLミスっておんなじ画像になってたので修正
sp-api.omni7.jpのAPIにトークン投げた結果
証拠画像1: https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]証拠画像2: https://pbs.twimg.com/media/D-yY4uKVUAEzApG.jpg:large [twimg.com]証拠画像3: https://pbs.twimg.com/media/D-1pQMHUIAEYw-7.jpg:large [twimg.com]
技術者としてはJSONでこう綺麗にあらゆるデータがまとまって返ってくるのは気持ちいいんんですけどねクラッカーにとっても気持ちいい設計です
firstNameKana: ラlastNameKana: マとは？
何がおかしいのか分からないんだが……
こういうのってACCS不正アクセス事件みたいに不正アクセス禁止法違反にならんの？
まあ今のセブンの立場で実験者告発してたらノンストップ炎上になるとは思うが（やらない保証はない）。
ACCS不正アクセス事件じゃ、試験目的だから良いだろ～ってノリで試験して実証したらACCSが告発して研究員刑事処分されたしなあ。
脆弱性2の方はTwitterで検証ツイートが出回ってたやつですねhttps://twitter.com/bulkneets/status/1147460171066560512 [twitter.com]まあ仰るとおり仕様とも言えますし騒ぐほどの事でもないかなと。
問題は脆弱性1の方で、何人かは事件後に気付いてたようですが、さすがに口外した人はいなかったですね。パスワードリセットのメールが来ていない被害者が乗っ取られたのはこれを悪用されたと見て間違いないんじゃないかと。
> これを悪用されたと見て間違いないんじゃないかと。
この手口は使われていないと広報が新聞に答えてますね。
セブンＨＤによると、専門家から、セブン―イレブンアプリに外部のＩＤから接続するシステムに欠陥があり、個人情報が他者から見られる危険性があると指摘されたという。「今のところ情報漏洩の形跡はない」（広報）という。https://www.asahi.com/articles/ASM7C647CM7CULFA02D.html [asahi.com]
この手口だとすると不可解なのは、逮捕された出し子には、パスワードを伝えていたというのをどう説明するのか。
出し子に脆弱性1でログインさせたわけではないとすると、どうやってパスワードを得たのか？
親コメ見て、ええ…これはヤバ過ぎるだろ、と思いながら見てたけど、それですら無いのか。なんだこのセキュリティホールのバーゲンセールは？
API叩いてパスのハッシュ抜けたらしいし、外部IDで入ってAPI叩いてパスクラ掛ければ行けたんじゃね？
実際には弱いパスワードならハッシュから解析されちゃうから、ハッシュにしても漏洩しないように管理しなければいいことに変わりはないんだけど、パスワードってハッシュ化すると厳重に管理しなければという意識が薄れてしまって今回のようにAPIとして垂れ流すといった問題が起きちゃうんですよね。
パスワードハッシュをAPIから取得可能にする意味あるのかな？ と疑問だけど、データベースに入れた情報は原則全部APIから叩けるようにしたんだろうね。
Salt付きハッシュなら漏洩しても、まあ別に……# Adobe漏洩事件のように全部同じSalt振ってなければ、ね# ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた？
salt付きだと解決するのはレインボーテーブル攻撃が防げるだけだよ。高速に解けないだけで、時間かければ解ける。
900件同時多発と言うから、まあ無理だな解読（が原因とは考えがたい）
# ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた？
普通に考えたらパスワードに埋め込まれているんでは？そうでないなら、普通ではないというだけだろう。今更不思議に思うことではない。
見た感じ問題の文字列はSHA-512っぽい長さなので、saltがくっつけられてるとは思えんよね。
固定ソルトかソルト無し、やろなぁ……ハッシュをAPIで返すのが意図通りの仕様であるなら、検証もAPI叩いた側でできる→追加情報不要→ソルト無しって事になるが……単にDB吐いてるだけなら固定ソルトもありうるかな。
まぁハッシュとソルト持ってかれたら、総当たりないし辞書攻撃で短いないし弱いパスは突破されるね。ソルト類はレインボーテーブルでの超高速攻撃などは防ぐがほかは微妙。
16桁のも破られているのでPW解読突破の線は薄い。あるいは複合的手法によりクラックされたとも考えられるが、短期間に900件同時多発とすると考えにくい（OpenID経由でクラックしたと言うのが最もしっくりくる）
ソルト無しだったならレインボーテーブルで突破できた可能性もあるけど……apiの大穴以上にサーバ自身に任意コード系の穴があった可能性も考えたほうがいいかな。
社長が「二段階認証」という単語を知らなかったことについて謎の擁護の流れができているようなんだがそういうのは一事が万事なんだよな
社長が仕様を提示したんですかねぇ・・・
二段階認証はあくまでも基本設計レベルの話なんで、二段階認証に対応しててもOpenID Connectの大穴みたいにガバガバに実装だと何の意味もないし。
要するに2018年末にSIerとベンダー交替して7ヶ月の突貫工事でオンボロシステムで大事故、大損害、と言う経営層の誰かクビが飛ぶか首吊り自殺しても全然おかしくないレベル
社長だって知っててもおかしくない、バカにされても仕方ないレベルかもしれんが、どっちかと言えばあそこにそういう事について受け答えできる人が用意されてないのが悪い。コレをネタに社長をバカにすることと技術的な問題や社内体制の問題をアレコレ言い合うのとは別の問題だよ。社長が技術的につよつよだったところで社内体制がダメだったら同じ事が起きるんだから。
>【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】これを脆弱性と呼んでる人たち正直技術者としては二段階認証を知らない社長と同レベルでは？という疑問がある問題が切り分けできないなら技術的なこと喋るのやめたほうがいいですよ。
技術者得意の答え『それは仕様です』って奴ですか？
ま7iD側がID Providerやるケースはレアケースで、実際にそれを設定していたユーザもごく少数でしょうから、900件の情報漏えいルートとしての可能性は低いでしょう。
ただし、この脆弱性だけでも（5500万円損害事故が起きて無くても）個人情報漏洩事故として官庁（内閣府個人情報保護委員会等）に対し速やかに報告が義務付けられるレベルだけど！？
んー、情報が全部取れ流のは最悪仕様としてもパスワードハッシュが取れるのは脆弱性かな？ 不必要だし。とはいえ、脆弱性１に比べれば大した話では無い。監査とかでは指摘あると思うけどね。このレベルでも。事業者側でリスク判断レベルで。
リンク先の記事以上に#3651026の概要が分かりやすくて助かります。
> 脆弱性2については、仕様ともいえますが、まぁ危険ですね。社長が会見で利便性の方を優先したようなことを言ってと思いますが、アプリ(や連携するサイト)の設計思想として、セキュリティよりも利便性を重視する方針なんでしょうかね？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
パスワードなしで他人のアカウントにログインできた (スコア:5, 参考になる)
［独自記事］7pay不正利用問題、「7iD」に潜んでいた脆弱性の一端が判明
https://tech.nikkeibp.co.jp/atcl/nxt/news/18/05498/ [nikkeibp.co.jp]
が分かりやすいです。
ただし、上記記事は、全く異なる2つの脆弱性の話が書かれているので、混同しないようにご注意ください。
【脆弱1 : OpenID Connectのアクセストークン未検証】
OpenID Connectのアクセストークンを検証していなかったので、ID（メールアドレス等）さえわかれば、
パスワードが分からなくても、OAuthが成功したことにして他人がログインできる脆弱性があった。
あまりにも酷すぎる脆弱性ですね！
【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】
実は、7iD 自体をOpenIDとして、他のサイトにログインすることが可能なAPIを提供していました。
ところ、がこのAPIのアクセスコントロールがガバガバで、API経由で他のアプリを含めた広範な個人データ、
ハッシュ化されたパスワードなども取得可能だったのです。
7iD で信頼できないサイトや脆弱性のあるサイトにログインしたら大変なことになるということです。
脆弱性2については、仕様ともいえますが、まぁ危険ですね。
Googleアカウントでどっかのサイトにログインしたら、そのサイトがGoogleアカウントのハッシュからGoogleドライブへのアクセス権やらGmailの送信権やら全取得、
しかもAPIのアクセス権設定は無しで全承認しかないとかだったら、大騒ぎですよね。
7iDはそういう仕様なのです。
メールアドレスだけで決済もクレジットカードチャージも可能 (スコア:5, 参考になる)
結局のところ、7payは、OAuthの認証が成功したというデータを送り付けるだけで、OpenIDのID(メールアドレス等)が分かるだけでログインできたのでした。
つまり、チャージされた残高は、メールアドレスさえわかれば、第三者が使用可能でした。
そして、登録されているクレジットカードからのチャージには、OpenIDでログインした場合を含めて追加で認証パスワードが必要なのですが、
OpenIDでログインした状態ならば画面に表示される、お問い合わせ番号、7iDメアド、nanaco番号（すべてアプリに表示）だけあれば、それもリセットできました。
https://twitter.com/ppp_payland/status/1146924240970514432 [twitter.com]
7payの悪用はリスト型攻撃だと言われてましたが、メールアドレスとパスワードのリストではなく、メールアドレスだけのリストで攻撃可能だったのです。
まぁ、リスト型攻撃には変わりないといったら変わりないのですが……。
Re: (スコア:0)
すげーなー、というしかないなぁ。
7payと社長が矢面に立たされ袋叩きにされたけど、実際はベンダーの方の責任の可能性が高いってことか。
今後のことを考えると、どこなのか公開して欲しいところ・・・
Re:メールアドレスだけで決済もクレジットカードチャージも可能 (スコア:1)
でも、その成果物を受け取って検収し、サービスインしたのは7-11側なので一義的に責任は7-11側にある。
どこがベンダーであっても一緒ですよ。それをもってサービス提供側をを甘やかしてはならない。
Re: (スコア:0)
確かにそうだが、検証できるだけの技術ある人もいないだろうに。まぁそれが問題なんだけど。
なんで日本の大企業は自分とこで技術者抱えて作ろうとしないんだろ。
本当にバカだよねぇ。
Re: (スコア:0)
脳筋脳花企業では往々にしてシステム屋と言う「何か訳のわからん事をやっている奴ら」は隅っこに追いやられるか、子会社に追放される。
Re: (スコア:0)
そういう業者に発注したのもセブン側でしょ。
とりあえずモックだけ作って本格実装は後回しにして開発進めていたら、その開発
期間では無理です、実装が間に合いませんと問題を申告した技術者が本部の意向で
左遷されて、後任のYESマンはなにもわからず本部の言われるとおりにした結果、
本番環境でもモックのままサービスインしてしまった．．．
みたいなことだって、ありえるんだから。
合言葉は「動いているから良いじゃない」。
責任者が被害しゃぶるのは良くないよ。
Re: (スコア:0)
苦汁「しゃぶれよ」
Re: (スコア:0)
あるいは
発注者側責任者『何か起きたら全部責任は俺が取る！』と豪語する
↓
900件5500万円のクラック被害発生、セブングループとコード決済の信用が地に落ちる
↓
発注者側責任者『』、あるいは他グループ、競合他社に夜逃げ、あるいは首吊り自殺
トレンドに乗ろうとして、最先端の認証プロトコルのオープンスタンダードを採用するから…… (スコア:2, 参考になる)
7iDのAPIは認証通れば、フル住所・生年月日・メールアドレス・電話番号・パスワードハッシュ他、あらゆる情報全取得可能。
証拠
https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
認証通っているなら良いのでは？ というのは間違い。
だって、7iDのパスワードと追加認証の決済パスワードが同じなら、パスワードハッシュから解析できてしまうし（弱いパスワードはハッシュからでも解析可能）、
APIから取得できる情報が、決済パスワードリセットの本人確認情報にもなるので、そこから攻めることもできる。
OpenID Connect (OIDC) 1.0 準拠の分権的な認証プロトコルのオープンスタンダードを採用と聞くと、モダンで最先端なスラド民が喜びそうだが、大した知識がないのにそういう最先端の実装をすると、個人情報も何もかもオープンになってしまうのである。
omni7を認証基盤にして、シンプルで最先端でかっこよいシステムを作ろうとして墓穴を掘った感じ。
たいしたスキルも無いのに、オープンソースとか、オープンスタンダードだとか、そういうのを重視する「意識高い系」の人は大迷惑。
最先端のシステム（OpenID Connectやら7iD認証基盤）を導入せずに、素直に独自のIDとパスワードで認証して、初回設定時と新規ログイン時にはSMSで確認コードを送る（二段階認証）という、古臭くてレガシーな仕様にしとけばこんな問題（不正ログインや不正チャージなど）はおきなかった。
素晴らしいAPIとJSONの活用 (スコア:2, 参考になる)
画像のURLミスっておんなじ画像になってたので修正
sp-api.omni7.jpのAPIにトークン投げた結果
証拠画像1: https://pbs.twimg.com/media/D-yY32pU0AAXuxl.jpg:large [twimg.com]
証拠画像2: https://pbs.twimg.com/media/D-yY4uKVUAEzApG.jpg:large [twimg.com]
証拠画像3: https://pbs.twimg.com/media/D-1pQMHUIAEYw-7.jpg:large [twimg.com]
技術者としてはJSONでこう綺麗にあらゆるデータがまとまって返ってくるのは気持ちいいんんですけどね
クラッカーにとっても気持ちいい設計です
Re: (スコア:0)
firstNameKana: ラ
lastNameKana: マ
とは？
Re: (スコア:0)
何がおかしいのか分からないんだが……
Re: (スコア:0)
こういうのってACCS不正アクセス事件みたいに不正アクセス禁止法違反にならんの？
まあ今のセブンの立場で実験者告発してたらノンストップ炎上になるとは思うが（やらない保証はない）。
ACCS不正アクセス事件じゃ、試験目的だから良いだろ～ってノリで試験して実証したらACCSが告発して研究員刑事処分されたしなあ。
Re: (スコア:0)
脆弱性2の方はTwitterで検証ツイートが出回ってたやつですね
https://twitter.com/bulkneets/status/1147460171066560512 [twitter.com]
まあ仰るとおり仕様とも言えますし騒ぐほどの事でもないかなと。
問題は脆弱性1の方で、何人かは事件後に気付いてたようですが、さすがに口外した人はいなかったですね。
パスワードリセットのメールが来ていない被害者が乗っ取られたのはこれを悪用されたと見て間違いないんじゃないかと。
Re: (スコア:0)
> これを悪用されたと見て間違いないんじゃないかと。
この手口は使われていないと広報が新聞に答えてますね。
この手口だとすると不可解なのは、逮捕された出し子には、パスワードを伝えていたというのをどう説明するのか。
出し子に脆弱性1でログインさせたわけではないとすると、どうやってパスワードを得たのか？
Re: (スコア:0)
親コメ見て、ええ…これはヤバ過ぎるだろ、と思いながら見てたけど、それですら無いのか。なんだこのセキュリティホールのバーゲンセールは？
Re: (スコア:0)
API叩いてパスのハッシュ抜けたらしいし、
外部IDで入ってAPI叩いてパスクラ掛ければ行けたんじゃね？
パスワードをハッシュ化の害 (スコア:0)
実際には弱いパスワードならハッシュから解析されちゃうから、ハッシュにしても漏洩しないように管理しなければいいことに変わりはないんだけど、
パスワードってハッシュ化すると厳重に管理しなければという意識が薄れてしまって今回のようにAPIとして垂れ流すといった問題が起きちゃうんですよね。
パスワードハッシュをAPIから取得可能にする意味あるのかな？ と疑問だけど、データベースに入れた情報は原則全部APIから叩けるようにしたんだろうね。
Re: (スコア:0)
Salt付きハッシュなら漏洩しても、まあ別に……
# Adobe漏洩事件のように全部同じSalt振ってなければ、ね
# ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた？
Re: (スコア:0)
salt付きだと解決するのはレインボーテーブル攻撃が防げるだけだよ。高速に解けないだけで、時間かければ解ける。
Re: (スコア:0)
900件同時多発と言うから、まあ無理だな解読（が原因とは考えがたい）
Re: (スコア:0)
# ところでDB情報を全部APIから叩けると仮定するとSaltはどこへ消えた？
普通に考えたらパスワードに埋め込まれているんでは？
そうでないなら、普通ではないというだけだろう。
今更不思議に思うことではない。
Re: (スコア:0)
見た感じ問題の文字列はSHA-512っぽい長さなので、saltがくっつけられてるとは思えんよね。
Re: (スコア:0)
固定ソルトかソルト無し、やろなぁ……
ハッシュをAPIで返すのが意図通りの仕様であるなら、
検証もAPI叩いた側でできる→追加情報不要→ソルト無しって事になるが……
単にDB吐いてるだけなら固定ソルトもありうるかな。
まぁハッシュとソルト持ってかれたら、
総当たりないし辞書攻撃で短いないし弱いパスは突破されるね。
ソルト類はレインボーテーブルでの超高速攻撃などは防ぐがほかは微妙。
Re: (スコア:0)
16桁のも破られているのでPW解読突破の線は薄い。
あるいは複合的手法によりクラックされたとも考えられるが、短期間に900件同時多発とすると考えにくい（OpenID経由でクラックしたと言うのが最もしっくりくる）
Re: (スコア:0)
ソルト無しだったならレインボーテーブルで突破できた可能性もあるけど……
apiの大穴以上にサーバ自身に任意コード系の穴があった可能性も考えたほうがいいかな。
Re: (スコア:0)
社長が「二段階認証」という単語を知らなかったことについて謎の擁護の流れができているようなんだがそういうのは一事が万事なんだよな
Re: (スコア:0)
社長が仕様を提示したんですかねぇ・・・
Re: (スコア:0)
二段階認証はあくまでも基本設計レベルの話なんで、二段階認証に対応しててもOpenID Connectの大穴みたいにガバガバに実装だと何の意味もないし。
要するに2018年末にSIerとベンダー交替して7ヶ月の突貫工事でオンボロシステムで大事故、大損害、と言う経営層の誰かクビが飛ぶか首吊り自殺しても全然おかしくないレベル
Re: (スコア:0)
社長だって知っててもおかしくない、バカにされても仕方ないレベルかもしれんが、どっちかと言えばあそこにそういう事について受け答えできる人が用意されてないのが悪い。
コレをネタに社長をバカにすることと技術的な問題や社内体制の問題をアレコレ言い合うのとは別の問題だよ。
社長が技術的につよつよだったところで社内体制がダメだったら同じ事が起きるんだから。
Re: (スコア:0)
>【脆弱性2 : 7iD の API のアクセスコントロールがガバガバな仕様】
これを脆弱性と呼んでる人たち正直技術者としては二段階認証を知らない社長と同レベルでは？という疑問がある
問題が切り分けできないなら技術的なこと喋るのやめたほうがいいですよ。
Re: (スコア:0)
技術者得意の答え『それは仕様です』って奴ですか？
ま7iD側がID Providerやるケースはレアケースで、実際にそれを設定していたユーザもごく少数でしょうから、900件の情報漏えいルートとしての可能性は低いでしょう。
ただし、この脆弱性だけでも（5500万円損害事故が起きて無くても）個人情報漏洩事故として官庁（内閣府個人情報保護委員会等）に対し速やかに報告が義務付けられるレベルだけど！？
Re: (スコア:0)
んー、情報が全部取れ流のは最悪仕様としてもパスワードハッシュが取れるのは脆弱性かな？ 不必要だし。
とはいえ、脆弱性１に比べれば大した話では無い。監査とかでは指摘あると思うけどね。このレベルでも。事業者側でリスク判断レベルで。
Re: (スコア:0)
リンク先の記事以上に#3651026の概要が分かりやすくて助かります。
> 脆弱性2については、仕様ともいえますが、まぁ危険ですね。
社長が会見で利便性の方を優先したようなことを言ってと思いますが、アプリ(や連携するサイト)の
設計思想として、セキュリティよりも利便性を重視する方針なんでしょうかね？