衝撃！Have I Been Pwnedが2.0にアップデート！
引用元：https://news.ycombinator.com/item?id=44035158
法務事務所と組んで、企業の過失による情報漏洩で集団訴訟を起こすべきだね。被害者には直接送金できるように銀行サービスと連携してさ。賠償金で企業に痛い思いをさせるんだよ。ヒーローになれるかも。投資家向けに訴訟情報を売るのもありだけど、情報漏洩が株価を下げるのが当たり前になるのが理想だよね。
＞何百万もの人に直接送金
少額の賠償金を良い目的のために簡単に寄付できたらいいのに。そうすれば集団訴訟に登録する価値も出るかも。
たぶん無理だろうけど、悪いことした企業から罰金を徴収して、道路を直したり家を建てたりするための基金を作るのはどう？
罰金を歳入源にするって考え方は、なんか嫌なんだよね。罰金って本来は抑止力のはずじゃん。理想は徴収額ゼロなんだよ。それを収入にしちゃうと、行動を抑止するんじゃなくて、罰則を課すこと自体が目的になっちゃうんだ。
いや、違うよ。公式サイトの「About」ページには「私は Microsoft では働いていません」って書いてあるよ。
「 Microsoft Regional Director 」って？言葉遊びかもしれないけど、会社の肩書きで自分を説明してるなら、それは…雇用のよう association があると僕は思うよ。
それは全く言葉遊びじゃないし、君の誤解だよ。彼は肩書きで自分を説明してないし、 Microsoft の社員じゃないって書いてる。君の logic だと、 CCIE 持ってたら Cisco の社員？大学で修士号取ったらそこの社員？電気技師の免許を持ってたら EnergySafe Victoria の社員？違うよね。
まさにベルギーで起こったことだよ。予算に交通違反の罰金が入ってたんだ。だから、罰金以外の交通改善策は、状況改善と罰金減収で二重のコストがかかることになったんだ。
へぇ、いかにもアメリカの反応。訴えて弁護士が儲けるけど何も変わらない。 EU では NIS2 みたいに過失には罰金。1000万ユーロか売上2％だよ。例えば Apple が80億ドル罰金受けたら、結構変わると思うけどね。笑
EUの解決策ってどうやってユーザーを完全に救うわけ？ せめて集団訴訟なら，ユーザーはほんの少しでも金が見れるのに．別に強い規制機関に反対してるわけじゃないよ．それは絶対必要だ．ただ，ユーザーが受けた搾取やひどい扱いに対して補償があればいいなって思うだけ．
USの解決策はユーザーを完全に救わないし，何も大きく変えない．EUの解決策は問題起こした会社の行動を大きく変えるんだ．俺は数ヶ月ごとに郵便で6ドルの小切手もらうより，情報漏洩が劇的に減る方がずっといいな．
問題はさ，1．他にどうやって企業にペナルティ科す？
2．罰金で他に何すんの？
罰金があるなら，それを見込んで予算立てないのは馬鹿げてると思うけど．
ルール決める責任者を選んだり，さらに強制するための組織を作るための選挙プロセスみたいなのを設計することもできるね．多分今回は，汚職や贈収賄を抑制するためのもっと良い方法を考え出せるかも．
個人的には分かるけど，理論とは違ってさ．NZで何回も罰金くらって免許失った人知ってるけど，一時的には痛手でも長期的な行動は変わらなかったんだ．NZには刑務所出たり入ったりしてる人もいるけど，ペナルティじゃ長期的な行動は変わらない．もっと根深い問題があるし，ペナルティは大事だけど全部じゃないよ．
企業に罰金かけて橋の資金にすればいいじゃん。
これって逆効果だと思うんだよね。
今だって企業が情報漏洩を公表するのって大変なのに、あんたの案だと余計難しくなって、后果が怖いからもっと隠蔽されちゃうよ。
俺は企業がやらかしたのを知ってパスワード変えたい派かな。知らないよりマシでしょ。
それって同じ分類じゃないよ。
分類は”役職”で、雇用を意味するやつね。”Regional director”は役職だけど、他のは違うよ。
もしあんたの理想が、みんなが常にルールを守る完璧な社会なら、すごくガッカリするだろうね。
理想的な徴収額は、違反の実際の発生回数に罰金の額をかけたものだよ。
そしてその収入は、厳密に改善や回復のための司法に使うべきだね。例えば、スピード違反の罰金はスピード違反を抑止して道路を安全にするための道路改善に使うとか。
もし誰もスピード違反しなきゃ、その必要はないけどね。でも人はいつだって法律を破るもんさ。
それはスローガンとしては良いかもしれないけどさ、本当に司法制度に収入を集めるっていう追加の権限を持たせたいわけじゃないでしょ？
要するに、また民事没収みたいなもんだよ。
うん、そっちの方が良い名前だね。でもそれが彼をMicrosoftの従業員にするわけじゃないよ。
＞ EUの解決策は、違反した企業の行動を意味のある形で変える。← 出典必要だよ。
俺の想像だけど、壊れたプロセスを直すのに巨額を投資する代わりに、結局罰金を払うために価格にちょっと上乗せするだけなんじゃないの？
EUが出した罰金のリストと、それぞれの企業の利益を比較すると、奴らは防ぐ代わりにただその間違いをする余裕があるってことがわかるよ。
”Microsoft Regional Director”は役職じゃないんだ。
あれはMicrosoftが非従業員だけに授与する”賞”だよ。
あの賞の名前が紛らわしいって思うかもしれないけど、それは正しいね。
でも、あの賞の名前が紛らわしいからって、その賞が誰かを従業員にするって主張するのは正しくないよ。
それは”言葉遊び”の問題じゃなくて、もしあの賞が彼を従業員にするって主張するなら、あんたは単に間違ってるんだ。
メインアドレスとサービスごとのアドレス使い分けマンだけど、ドメイン検索が有料になったら不便になったわ。自分のドメインで調べたら”2,243 Total Breached Addresses”とか”18 Addresses excluding Spam Lists”とか出たのに、詳細見ようとしたら課金しろって。ダウンロードも404エラーだし。単一アドレスならいいかもだけど、ドメイン持ちには使いにくいね。
俺もキャッチオールとかエイリアスでアドレスたくさん使ってるから、手動で全部確認なんて無理ゲー。ドメイン検索の有料化はメンドイけど、Troyたちも食っていかなきゃならないし、会社向け有料化はわかる。個人ドメインユーザーは微妙な立ち位置だね。もっと細かい設定があればいいのに。HIBPも大変だろうし。結局、サブスク登録して確認後すぐ解約したよ。手間だったけど、まあ仕方ないか。短期アクセスがあればよかったなー。
ああ、俺もそのグレーゾーンにいるわ。確かドメインあたり10件までしか見れなくて、俺はそれ以上漏れてるから見れないんだよね。サービスごとにアドレス使い分けてる個人は無料で見れて、会社はちゃんと金払う、っていううまいやり方がないのは残念だよなー。
俺も似た設定で、一つのドメインでアドレスいっぱい使ってるよ。でも、課金してない（はず）だけど、普通にドメインのワイルドカード検索できるし、漏洩したアドレスも全部見れるんだよね。どの漏洩元かは表示されないけど、アドレス見ればどのサービス用か分かるから、それは別にどうでもいいかなって感じ。
昔はアドレスに＋somethingって付けてたんだけど、今はちゃんとマスクされたアドレス作るようにしてるんだ。最初は自分のドメイン名でバカなことしたけど、今はFastmail.comで作ってるよ。
OPは、たぶん「aaa+facebook@smthg.com」みたいに使ってたから、メインの「aaa@smthg.com」がバレるってことを言ってるんじゃないかな。「facebook@smthg.com」だけ使うのと違ってさ。
最初は前者（＋something）みたいにやってて、それから後者（サービスごと）に変えたんだ。その@smthg.comってドメインは俺のだんだけど、中に俺の名前が入ってるから、名前と結びつくのがなんか変かなって思ったんだよね。
ああ、なるほど、説明ありがとうね。
名前入りのドメインだと、これはよくある問題だよねー。
もっとコメントを表示（1）
自分のドメイン名に名前が入ってるからね。プライバシーのためにやってるのに、なんか逆効果じゃんって思っちゃったんだ。
会社ごとにアドレス変えてるのって、メインアドレスから派生させてる？もしそうなら、それ“email tumbling”って呼ばれてて、メインアドレスを特定できちゃうサービスもあるんだよ。
俺も会社/サービスごとにメールアドレス分けてて、メインとは無関係だよ。ドメイン名使うとAIに見破られるかも。理想はランダム生成されたアドレスで、サーバーで判別するシステムだけど、そんなのないし作る時間もないんだ。でも今のところ問題なし。
前はちょっと複雑なシステム使ってた時期があって、Appleには“strawberry.cake@example.com”とか、メーリングリストへの投稿は“steve@12.2025.example.com”（これは1ヶ月でMXレコード消えるようにしてた）みたいな感じでやってたんだ。
でも結局、facebook@example.comとかinstagram@example.comみたいな、分かりやすい名前に落ち着いたよ。
＞ 記事の「人間なのにブロックされるのは一桁%」って話。
記事の回避策は「もう一回クリック」「再読込」だけ。
ブロックされるなら手紙送ろうかと。HIBPは無料だけど、 CloudFlare Turnstile や Google Recaptcha が増えると、一桁%の人が現代社会に参加できなくなるんだ。
IPアドレスとか古いブラウザとか、同じ理由で同じ人が引っかかり続けるよ。
前職でbot対策入れたら、社内や友達みたいに善意のユーザーまで曖昧なエラーでブロックされまくり。
社内の人間ですら原因分からず、外部の人はもっと無理。
友達が困っても、システムの詳細を言えないから助けられなかったよ。
SNSでも困ってる人が「ブラウザ変えろ」「Windows入れ直せ」とか言い合ってた。
不正対策は必要だけど、善意のユーザーを簡単に犠牲にする運用見て、会社へのロイヤルティ下がったね。
6時間後、やっぱりだよ。
Slackにログインしようとしたら、見えないcaptchaでブロックされちゃった（https://snipboard.io/h1E86S.jpg）。
開発者ツール見たら、また“bot”扱い。
見えないから何もできない。
これ、仕事のペンテスト用のクリーンなブラウザなんだ。
uBlockとか何も入ってないのにさ。
同感だよ。どうやら俺の（固定）IPアドレスが、なんか知らんけど Google と CF に引っかかってるみたいだ。
家からスクレイパーとか動かしてるわけじゃないけど、NoScriptは使ってる。
NoScript使ってるからbot扱いされちゃうの？たぶんね。
うん、俺、uBlock Originでかなり厳しくブロック設定してるんだ。
Googleは1ヶ月くらい前から俺をブロックし始めて、マジでクエリ出すたびにcaptcha解かないといけなくなったんだ。
無効にすると元に戻るから、uBlockが原因だって分かってるよ。
まあ、これのおかげで、代わりにDuckDuckGoとかBrave Searchを使う新しい筋肉の記憶（習慣）がついたけどね。
新しいデザイン、なんか信頼できなく感じる人、他にいる？
たぶん、同じようなテンプレートばっかり見すぎて慣れちゃっただけだろうけど、別に何か悪いところがあるわけじゃないのに、本物じゃなくてパチモンのサイト開いちゃったんじゃないかって思っちゃうんだよね。
ああ，うんうん同意．今回の新しいバージョン，安っぽいグラデーション（なんて説明すればいいか分かんないけど）の安っぽいテンプレート使ってるみたいに見えるね．それだけで一気に信用できなく見えるわ．
うん，そうだね．ウェブサイトのリデザインってマーケティングとか開発者の趣味で，ユーザーにはあんまメリットないと思うわ．Nasa ADSも昔 fantastic なサイトだったのに，余計な装飾つけて結局中身変わんないし．
あと，パフォーマンス horrible だし scroll hijack してる．あのサイト，マジで horrendous だわ．
LinkedIn みたいなデカいサイトが，この10年以内で unsalted なパスワード保存してるとか amazing だね．現代でどうやったらそんな失敗すんの？
実はうっかりやっちゃうのって easy なんだよ．途中の middleware とかにとってはパスワード field って他の field と同じ扱いだからね．logging や tracking，analytics で request body を log してたりすると問題になることがあるんだ．abuse prevention system とかでもあり得る．パスワード database への保存は uncommon だけど，API gateway の log で sensitive マーク忘れとかは結構ある話．
LinkedIn みたいな big な会社はさ，生成した password でサイトに bot でアクセスさせて，ログとか disk を調べて漏洩箇所を探すべきだよ．小さい会社でもやってる．しくじるのは easy だけど，responsible な会社は対策する．LinkedIn は絶対もっとできる．
いつも思うんだけど，$large_organisation の middle manager って，こういう問題聞くと政治的なメリットとか考えちゃうんじゃない？もし Fred の logging 機能がパスワード保存してると分かったら，Fred の栄光を奪えるか，味方として扱うか，潰すタイミング待つか，とかね．大組織が良い技術判断するのってあんま見たことないから，きっとそんな感じ．
＞ 現代でどうやったら失敗すんの？
たぶん ancient な legacy system とか，誰も modern に移行する時間や budget がない integration のせいじゃないかな．会社が大きいほど ”business critical” なものの ossification リスクがデカいんだ．だって1時間の outage でもすごい損失になるからね．
AI Slop って騒ぐけど，何十年も前から Outsourced Slop に苦しめられてるのってあんま言われないよね．LinkedIn の fail もそれが原因だと思う．俺の経験上ね．AI code と同じで，competent な management が要件とかテストとかちゃんとやらないと，見た目だけ equivalent で中身が slop ってことになるんだ．
LinkedIn は ancient って言えるほど古くないし．2003年ローンチだし，その頃ですら plaintext でパスワード保存なんて提案したら笑われただろうに．
これってさ、パスワードをサーバーに送る前に、クライアント側で公開鍵（よく変えるやつ）で暗号化しとけば解決しない？ ネットワーク通る間に復号化されて保存されるのは、最後の認証サービスだけって仕組み。
なんか中間管理職がみんなそんなサイコパスみたいに思ってるのって、相手じゃなくて君自身の問題じゃない？
たしかにそういう人もいるけど、大半は違うでしょ。イギリスの人は「陰謀より失敗」って言うよ。
昔LinkedInってさ、連絡先を見つけやすくするためとか言って、みんなにメールのパスワードとか渡すようにめっちゃプレッシャーかけてたんだよね。
だからまあ、LinkedInがIT Securityのしっかりしたとこだったためしがないのはその通りだよ。
いや、意識してMachiavellian schemeみたいにやってるわけじゃないかもだけど、中間管理職によくある態度だよ。
自分の評判にめっちゃ敏感だから、会社のためになることでも自分を悪く見せる人は罰するんだ。
セキュリティの穴とか無駄を見つけても、曖昧な敵意で返される。
「これ半年前に誰か言ってたよね？」って聞かれないように、感情的に話をそらすのに多くの人は気づけないんだよ。
彼ら（LinkedInとかユーザー）には、ちゃんとそうする理由があったんだよ。
例えば連絡先アプリみたいにね。問題は、それを安全に保管できなかったってことなんだ。
それってさ、結局インフラがまだ古いってことじゃないの？ 移行の時の技術的負債ってよく見るんだよね。
古いシステムと新しいシステムがしばらく一緒に動くから、レガシーなプロトコルとか設定を残しちゃうんだ。
それで、新しいシステムが完全に今の標準にアップデートされないままになっちゃう。
Pre win2k ADとか、ファイルパスの長さとか、暗号化とかね。新しいシステムは”up to date”でも、古い互換性設定が残ってるんだよ。
誰だって自分の評判にはめちゃくちゃ敏感だよ。
それはもう人間の性だから。
そういうのを考えて行動したり話したりできないのは、率直に言って基本的な対人スキルが足りてないだけじゃないかな。
安くて offshoreな開発とか、変なインセンティブが原因ってのもあるけど、もう引退したsenior cowboy coderも考慮に入れないとね。
たぶん将来的にはvibe codersとかAI powered juniorsも出てくるだろうけど、この業界で数十年やってきた身としては、そういうのにどう対処するかはもう分かってるよ。
この問題の既存の解決策はSRP (Secure Remote Passwords http://srp.stanford.edu/) ってやつだよ。
ただ、ちゃんと実装するのがめっちゃ難しくて、色んな言語で良い実装があんまりないんだよね。
最近調べてないから、もっと新しい、ヤバくないアプローチがあるかもだけどね。
でもさ、認証情報自体をサーバーに送らないやり方って、今回のみたいな問題を完全に止められるんだ。
Linkedinの”Xを招待”ボタン、ほんと意味ないんだよね。アカ持ってない人にメール送るだけで。断ってもまた違う言い方で聞いてくるし。
もっとコメントを表示（2）
面接でLeetcodeの難しい問題をもっと聞くべきだったんだろうね。
みんな評判に敏感なのはわかるけど、中間管理職は特にヤバいんだよな。技術わかんないくせに、上より目立つから変な立場になる。誰かが問題起こしそうだと、自分を守ろうとする。開発者がヤバいこと教えても、そいつが問題って見ちゃうマネージャー多いんだ。
最後に”コミュニケーション不足は社会性ない”ってのには同意だって。
SRPって最新版でも、残念ながら今どきのPAKEプロトコルに比べると全然ダメらしいよ。
https://blog.cryptographyengineering.com/should-you-use-srp/
テック系の連中が”誰も使わない”と思ってる機能（サイトのシェアボタンとか）が、実はめっちゃ使われてたりするんだよね。あれはきっとA/Bテストしまくった結果なんだろうね。それだけじゃなくて、Linkedinのシャドウプロフィールとか、それで人をおすすめしてくることについても言ってたんだよ。
LinkedinってMFA有効にするのに、パスポートと一緒に顔の生体認証スキャンが必要なんだぜ（登録時にはいらないのに）。それでいて”本人確認”とか言ってるし ;-)
あと、俺もうアクティブなLinkedinアカウント持ってないよ。
俺の記憶が正しければ、Linkedinは過去の漏洩の一つで、俺のLinkedinアドレスにスパムが来たんだよ。それを伝えたら、向こうは”うちじゃないです、あなたハックされたのでは”って。で、後になって”あ、うちでした、でも個人情報は盗まれてません”って。メールアドレスが個人情報じゃないってことかよ！キャッチオールメールドメイン使ってて、Linkedinで使ったアドレスをブロックできたのはラッキーだったわ。
昔いたユーザー数百万の会社、DBにパスワードが平文で保存されてたんだよ。自社開発で古かったし、忙しくて誰も直さなかった。Microsoftに買収されてシステム自体は無くなったけどね。
一度SQLで一番多いパスワード見たんだ。トップは”trustno1”、あとは定番ばかりだったよ。（ルールなかったし）
パスワード変更セッションごとに新しい公開鍵ってアイデア、なかなか面白いね。セッション開始時にセッションキーを取ってくるためにread-before-writeが必要になるっていう課題はあるけど、そういう処理の呼び出し頻度は低いだろうから、セキュリティ監査をシンプルにしたり、変更時のリスクを減らすためには小さい代償かもね。
新しいアプローチは、LLMエージェントを”雇って”仕事をさせることだと思うな。採用担当者がLLMでできるすべての方法を使い果たしたことを証明できない限りね。
Plaintext、まあそうだけど、短いパスワードだとすぐ破られちゃうSHA-256を使うのもまだ一般的だったよね。
これはfeature flagサービスがいかにミッションクリティカルになるかって話でもあるね。だって、整理されないfeature flagの後ろで全部リリースされちゃうんだから。
残念だけど、新しいUIでは流出した電話番号を検索できなくなったよ。古いのはできたんだけどね。これは告知にも書いてあるけど、ドイツでfacebook相手の訴訟があって、そこで参加できるか知るためにこの機能が使われてたから、削除するにはホントにタイミング悪いと思うな。
APIではまだサポートしてるから、新しい解決策を実装するのはまだ可能だと思うよ。告知で説明されてる機能を削除した理由は、もっと広い影響を考えると、すごく納得できるものに思えるな。
自分のメールが流出したすべてのデータ漏洩を、縦スクロールのタイムライン（ロゴとか説明文付き）で見せてくれるんだって。なんてゾッとしながらも楽しいんだろう。
ちょっと無力感を感じるな。俺にできるのは、クレジットを凍結することくらいだ。
え？なんで物によって違うパスワード使わないの？信用できないサイトで買い物する時はprivacy.comみたいな一回きりのクレカ作れるサービス使うのがおすすめだよ。あと、絶対に必要じゃない限り大事な個人情報は自ら提供しちゃダメ。オンラインサービスにデタラメな情報与えるのも違法じゃないし、漏洩時に悪用されにくくなるかも。無力とかじゃなくて賢くやるんだよ。HIBPは悪用される前に知るためのツールなんだ。（重要なメアドは通知設定推奨）
アプリごとのクレカ番号は法律で義務付けるべきだと思うな。俺のカード何回かスキミングされて、新しい番号でアカウント全部更新すんのがホント面倒だった。オンライン購入は、店が直接決済プロバイダに登録するべきで番号なしにすべき（ED25519公開鍵とかで？）。
追記:対面カードも永続番号じゃなくて、かざすたびに新しい鍵作るとかにすれば？
