別のコメント者がこれをほぼ推測してたね。

投稿の法的な流れを追っていくと、すぐに絞られていく。著者は、大手の国際的なダイビング保険会社、インストラクター主導の学生登録ワークフロー、GDPRの適用、マルタの国家的な脆弱性開示ポリシーに基づくCSIRTマルタの明示的な関与を説明している。その組み合わせは非常に特定的だ。世界的に関連のあるダイビング保険会社は数社しかない。DANアメリカはアメリカに拠点があるし、DiveAssureはマルタの会社ではない。AquaMedはドイツの会社。実際にマルタに本社を置き、登録されている大手のダイビング保険会社はDANヨーロッパだけだ。組織がマルタに登録され、マルタの監督プロセスに従っているとされていることを考えると、構造と法的管轄だけでDANヨーロッパが最も可能性のある候補になる。

もしかしたら、ダイビングコミュニティでは「ダイバー向けのマルタの保険会社」って「青いチェックマークのある鳥をテーマにしたSNS」くらい分かりやすいのかもね。

かもしれないね。もしくは、彼らが知ってることをブラックハットに売るために利用したのかも。

パスワードシステムで同じ問題を見つけたことがあるよ。しかもパスワードがデータベースに平文で保存されてる状態で…すべてのパスワードをクリアして、長いハッシュを保持できるようにデータベースのフィールドを拡張した（パスワードフィールドは12文字くらいだった）。それから「パスワードをリカバーする」機能を設定して、終業前に全ユーザーにメールを送った。これを読んでる人への私の提案は、パスワードハッシュのメカニズムにバージョンを付けて、将来的に必要に応じてハッシュ方法をアップグレードできるようにすることだよ。私は通常「v{version}.{salt}.{hash}」を使っていて、saltと結果のハッシュはsaltと結果のbase64文字列にしてる。同じことのために複数のデータベースフィールドを使うこともできるけど、あまりやりたくないな… JSONや他のラッパーを使うこともできるけど、ドットで区切ったbase64で十分だと思ってる。ハッシュが後でアップグレードされたこともあったし、バージョンが変わったらログイン時に新しいエンコーディングでパスワードを（再）ハッシュすることもあった… 一定の期間が過ぎたら、ユーザーに通知して古いパスワードを消去してリカバリープロセスを要求するようにしてる。余談だけど、ログイン/認証システムの中程度の良い実装に関するガイドがもっとあればいいなと思ってる。SSOなどのアプリケーションが複雑なだけの泥沼になってしまうことが多いから。以前の雇用主のために作ったいいシステムがあって、結構広く展開されてるんだけど…オープンソースにする許可を得ようとしたけど、「セキュリティの懸念」で賛同を得られなかったんだ（皮肉だね）。いつかまた別のものを作るかもしれない。

数年前、ある会社で別の会社を買収したんだ。私たちのQAチームがそのサイトを一通りチェックするように頼まれたんだけど、彼らが見つけたことは今でも友人や元同僚の間で笑いのネタになってる。* アカウントIDは数字で、増加していく * ログイン後のURLに含まれている、例えば ?account=123456 * ログイン後のリクエストに認証がない だから、ちょっと興味がある人なら、account_id=123457に増やして別のアカウントにアクセスできちゃう。次は123458を試して、面白いものがないかスペースを列挙してみる… :face-palm: :cold-sweat:

同意するけど、セキュリティ研究者や私たちのコミュニティも、脆弱性がほとんどの非技術者にとっては異質なものであることを認識する必要があるよ。非技術的な組織に対して冷たく脆弱性の報告をすると、正直言って彼らは怖がる。まるで、会ったこともない人が「裏のバルコニーのドアはダミーキーで開けられるよ」と言ってきて、実際に試したから知ってるみたいな感じ。そういう組織はどうしたらいいか分からない。誰かが財務情報を盗んだかもしれないと考えて、怖がってるんだ。内部での争いや、いろんな憶測が飛び交うことが多いけど、コミュニケーションが戻ってくるまでには時間がかかる。セキュリティに前向きな組織がやってることとは全然違うから、「善意」が悪意として受け取られることが多いんだ。

シニカルだね。最悪な部分？この状況でできる最善のこと。こんな組織とこれ以上やり取りを続けるなんて想像もつかないよ。