アカウント名:
パスワード:
［独自記事］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 のアクセ
実際には弱いパスワードならハッシュから解析されちゃうから、ハッシュにしても漏洩しないように管理しなければいいことに変わりはないんだけど、パスワードってハッシュ化すると厳重に管理しなければという意識が薄れてしまって今回のように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の大穴以上にサーバ自身に任意コード系の穴があった可能性も考えたほうがいいかな。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
計算機科学者とは、壊れていないものを修理する人々のことである
パスワードなしで他人のアカウントにログインできた (スコア: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 のアクセ
パスワードをハッシュ化の害 (スコア: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の大穴以上にサーバ自身に任意コード系の穴があった可能性も考えたほうがいいかな。