（2023/08/17一部追記しました）
私も使ったことがあるサービス pictSQUARE で情報漏洩があったというニュースを見て、セキュリティについてつらつら書きたくなったので書きます。
正確ではない記述があるかもしれないのでご注意ください。
さて私は pictMalfem と pictSQUARE を利用したことがありつつ両方退会済みなのですが、退会したユーザーのデータがデータベースから消えているとは限らないので他人ごとではありません。
（「論理削除」と言って、削除フラグを ON にしたデータは削除された扱いにするというルールで運用することがあり、この場合退会したユーザーのデータは物理的には削除されずにデータベースに残り続けています）
今回メールアドレスとパスワードが流出した可能性があるとのことで、運営元からは
他サービスで、当サービスと同じパスワードを使用されている場合、他サービスでのパスワード変更をお願い致します。
と言われています。
「パスワードの使いまわしをやめろ」とはよく言われることですね。
パスワードのハッシュ化
「現代の Web サービスだしパスワードは流石にハッシュ化されてるんでしょう？ 元のパスワードはわからないでしょう？」と思われる方もいるかもしれません。
そもそもハッシュ化とは何ぞやという点を簡単に書くと、ハッシュ関数を使ってあるデータ（「メッセージ」と呼ぶ）を別のデータ（「ハッシュ値」「メッセージダイジェスト」などと呼ぶ）に変換することです。
ハッシュ関数は次の性質を持ちます。
- 衝突発見困難性
- 同一のハッシュ値を生成する（H(x) = H(x’)）異なる二つのデータ（x, x’）を求めることが計算量的に困難であること
- 第 2 原像計算困難性
- データ（x）と、それに対するハッシュ値（y = H(x)）が与えられたとき、同じハッシュ値を生成する（y = H(x’)）データ（x’）を求めることが計算量的に困難であること
- 原像計算困難性（一方向性）
- ハッシュ値（y = H(x)）が与えられたとき、それを生成するデータ（x）を求めることが計算量的に困難であること
（引用：上原孝之，情報処理教科書 情報処理安全確保支援士 2023年版，2022 年 11 月 22 日，pp.516-517）
現代における大抵の Web サービスでは、ユーザーが入力した生のパスワードをハッシュ値に変換してからデータベースに保存しています。
そうすることで次のようなことが達成できます。
- 同一の入力値からは同一のハッシュ値しか生成されず、同一のハッシュ値となる元データを計算で求めることは困難なので、データベースに生のパスワードを持っていなくてもユーザーの認証は問題なく可能である。（ハッシュ値同士を比較している）
- ハッシュ値から元データを復元することは現実的に困難なので、仮にハッシュ化済みのパスワードが流出しても生のパスワードはわからない。
つまりピクスク運営元がパスワードをハッシュ化していたと仮定すると、データが流出したとしても元のパスワードは流出していません。
ハッシュ化していたかどうかはわかりませんが……。
＊ ＊ ＊
それでもデータの流出時に同じパスワードを使っている他のサービスのパスワードを変えろとよく言われるのはなぜかというと
- そもそもハッシュ化していないパスワードをデータベースに保存している Web サービスも未だに存在する
- ハッシュ化済みのパスワードから元のパスワードを推測する攻撃手法が存在する
- （2023/08/17追記）ハッシュ値から元のパスワードを復元することは理論上不可能なわけではない
などが理由としてあげられると思います。
「ハッシュ化していないパスワードをデータベースに保存している」は言わずもがな最悪なのですが、本当に存在します。
私は昨年、ハッシュ化していない数字 4 桁のパスワードをデータベースに保存している Web サービスを仕事で取り扱ったことがあります……。上場企業が運営しているサービスで。
これは本当に最悪のやつで、そもそもパスワードが数字 4 桁な時点で最悪なので、そんなサービスは即刻退会したほうがいいです。
でもここまで最悪でなくても未だにハッシュ化していないまま運用していることはあるので、仮に大企業が運営しているサービスでもあまり信用しないほうがいいです。
「ハッシュ化済みのパスワードから元のパスワードを推測する方法」にはレインボーテーブル攻撃というのがあります。
私も詳しくないので詳細な説明は省きますが、わかる範囲で説明してみると、たとえば「a075d17f3d453073853f813838c15b8023b8c487038436354fe599c3942e1f95」というハッシュ値から元のメッセージである「p@ssw0rd」を復元することは現実的に困難です。
でも「p@ssw0rd」をハッシュ化したら「a075d17f3d453073853f813838c15b8023b8c487038436354fe599c3942e1f95」になるということを知っていれば、もちろんハッシュ値から元のメッセージを特定できます。
つまり文字列とハッシュ値の組み合わせを予め大量に計算しておけば、ハッシュ値から元データを特定できる可能性があります。
だいたいこういう発想に基づくのがレインボーテーブル攻撃です。
（年に一回くらい話題になる「パスワードによく使われる文字列」はもうハッシュ値がわかっているので、そういうのをパスワードにするのは本当にやめましょう。）
ただしレインボーテーブル攻撃には対抗手法が存在します。
セキュリティに気を使っているサービスならきちんとやっていると思います。
対抗手法の一つは「ストレッチング」で、これはハッシュ関数を何度も重ね掛けするというものです。
何度もハッシュ関数を重ねればそれだけ元のメッセージにたどり着くのは困難になります。
もう一つは「ソルト」で、これは元のメッセージそのものにハッシュ関数をかけるのではなく、何らかの文字列を付与してからハッシュ関数をかけるというものです。
たとえば（単純な例ですが）「p@ssw0rd」に会員番号「1」を付け足し、「p@ssw0rd_1」という文字列にしてからハッシュ関数をかければ、それだけで元のメッセージを特定しづらくなります。
（2023/08/17追記）また前述の通り、ハッシュ関数の諸々の性質は「計算量的に困難」であるだけであって、理論的に不可能なわけではありません。
計算機の性能は年々向上するので、現在は安全とみなされているハッシュ値も、将来的には現実的な計算時間で同一ハッシュ値を生成できる別のメッセージが生成される可能性がありますし、最悪の場合は元のメッセージを復元可能になってしまう可能性もゼロではありません。
またハッシュ関数に理論上の脆弱性が発見されることもあります。
たとえば MD5 というハッシュ関数は理論上の弱点があることが知られており、現在「電子政府における調達のために参照すべき暗号のリスト(CRYPTREC暗号リスト)」では推奨されていません。
こういう、色々な要因によって暗号アルゴリズムの安全性が低下してしまうことを「危殆化」と言います。
Web サービス運営者にはパスワードのハッシュ化などに際しては危殆化したアルゴリズムを使わないこと、もし使っているアルゴリズムが危殆化したら新しいアルゴリズムに変更することが求められます。
レインボーテーブル攻撃や危殆化の問題があるので、ハッシュ化していれば絶対安全というわけではありません。
（2023/08/17追記ここまで）
ユーザーができるセキュリティ対策
パスワードの使いまわしは絶対やめましょう！
あとパスワードの強度に関する常識はどんどん更新されていきますが、現時点では長くて複雑な文字列のパスワードを設定しましょう。
短くて単純なパスワードはデータ流出してなくても総当たりで解読されます。
それと、パスワードとして設定可能な桁数が短いとか、数字しか指定できないみたいな Web サービスはできればそもそも利用しないほうがいいと思います。
そういうサービスの運営元は間違いなくセキュリティを軽視していますので……。
あと多要素認証が設定できる場合は設定しておくのがおすすめです。
設定しててもアカウント乗っ取られたみたいな話も聞きますが、設定してないよりは絶対に突破されづらいです。重要なサービスだけでも設定しておきましょう。
多要素認証用のデバイスが壊れたときのためにバックアップコードなども忘れず保存、再設定用のメールアドレスや電話番号があればきっちり設定しておきます。
ちなみに多要素認証というのは「知識」「所有」「生体」の要素の内の複数を組み合わせて認証することで、パスワードというのは「知識」なので、「所有」か「生体」を足す必要があります。
ときどき設定を要求される「秘密の質問」はパスワードと同じく「知識」なので、「二段階認証」ではあるかもしれませんが「多要素認証」ではなく、あまりセキュリティ的には強くありません。
でも秘密の質問って無くなりませんよね……。開発にお金がかからないからだと思うんですけど……。
現実的に強度が高いパスワードを覚えておくのは無理なので、信頼できるツールにパスワードを保存しておきましょう。
ブラウザでもいいですし、Mac のキーチェーンでもいいですし、その他のツールでも。
私は PC とスマホで使用しているブラウザが違うのでクラウドに保存するタイプのパスワード管理ソフトを「これが安全かは知らんけど俺は信じてるからな！」という気持ちで使っています。
信頼できるツールから流出した場合はまあ……そういうこともあります、ドンマイ。
それと最近は Twitter のせいでメールアドレス・パスワードでのログインに回帰してしまった気もするのですが、その辺の Web サービスよりは Google や Apple のほうが遥かにセキュリティが強いと思うので、Google ログインや Apple ID でのログインを使うようにするというのも個人的にはいいかなと思います。
もしこういう ID 連携でログインする場合、個人的見解としては Twitter や Facebook のような SNS アカウントでのログインはできるだけ避けたほうがいいと思います。
なぜなら悪意ある他人からの虚偽の通報などで簡単に凍結される可能性があるからです。
ID 連携は元が潰れると芋づる式に全部ログインできなくなる点がつらいので、なるべく凍結されづらい性質のサービスのアカウントを使うほうが安心です。
以上です！ 世の中悪意に満ちていて怖いけど頑張って身を守っていきましょう！