2019年7月に、比較的大きな事件となったセブンペイ事件。
「単に被害を受けた」だけでなく、セキュリティ対策が甘いことが大きな問題になりました。
（どうも、対応も大分問題あるようですけどね・・・）
しかし、こういった事件はセブングループだけの問題でしょうか？
サイバー犯罪は非常に速いペースで進化しており、それに伴ってセキュリティも日進月歩で進歩しています。
問題は、この変化についてこれている企業・組織はどの程度あるのか？ということです。
ちょっと見かけたサイト
ちょっと色々あって、見かけたサイト。
新規登録画面を見て愕然としました。
パスワードが「※半角英数記号4文字以上、16文字まで」というルール。
短すぎでしょ、いくらなんでも（特に最小が4文字の部分）。
これ、2019年7月23日に見つけたんだぜ・・・。平成でも昭和でもないんだぜ・・・令和なんだぜ・・・。
い、いや、まだだ。きっと、パスワードはがっちり守ってくれている・・・はず・・・。
推奨されるパスワード
なお、パスワードの推奨に関しては、総務省やJPCERT/CCがガイドを出しています。
パスワードを設定する側（ユーザ）は、これを守ることで自身の身を守りましょう、ということです。
安全なパスワード管理（総務省）
http://www.soumu.go.jp/main_sosiki/joho_tsusin/security/business/staff/01.html
STOP! パスワード使い回し!キャンペーン2018（JPCERT/CC）
https://www.jpcert.or.jp/pr/2018/stop-password2018.html
概ね、使いまわしはしない、類推できる文字列（単語等）は使わない、数字や記号をできれば混ぜる、適切な長さにする、定期的な変更は不要といったルールになっています。
長さについては、総務省のページでは明記されてませんが、JPCERT/CCのページでは12文字以上を推奨しています。
これは、漏洩したパスワードハッシュをパスワードクラックツール（john the ripper、hashcatなど）でクラックをされた際に、解析を諦めるのに十分な長さの目安ということです。
なお、いくら長くても、既知の単語などでは辞書攻撃をされてしまう可能性もあるため、それは避けるべきです。
Webサイト側の対応
あとは、パスワードを保管する側の問題ですが。
最悪なのは、DBなどにそのままパスワードを記録しているパターン。
被害に遭ったら、パスワードがそのままリークしてしまうので、当然アウトです。
流石に無いと思うだろう？・・・ダークウェブにリークしているリストだと、ハッシュ値がないのにパスワードがあるリストが何故かあるんですぜ・・・。
なお、稀に「DBを暗号化しているから大丈夫」とおっしゃる方もおられますが、SQLで読み出せば平文となりますので、DBのイメージをクラックされたならともかく、SQLインジェクションやサーバに侵入されてSQLで抽出された場合、その暗号化は意味が無いのであしからず。
また、「BASE64にして保存している」と言ってのけた人も過去にいましたが。
あれは別に鍵無くても普通に元に戻せるからな？
あれは暗号化じゃなく、符号化の類だからな？
また、ハッシュ化するにしても、当然長いハッシュ関数を使うべきです。
パスワード解析時に計算コストがある程度大きくなるほか、将来的に衝突耐性の問題が出てくる可能性があるためです。
また、ハッシュ化されていても、計算済みのハッシュ値とパスワードのペアのリストであるレインボーテーブルを用いた解析をされると、被害が大きくなります。
対策としては、ハッシュ化する際にソルトとなるパラメータを入れることで、レインボーテーブルによる解析を困難にすることができます。
ハッシュ関数については、総務省、経産省が、「CRYPTREC暗号リスト(電子政府推奨暗号リスト)」を平成25年に公開しています。
「CRYPTREC暗号リスト(電子政府推奨暗号リスト)」
https://www.cryptrec.go.jp/list.html
https://www.cryptrec.go.jp/list/cryptrec-ls-0001-2012r4.pdf
6年前の平成25年3月1日（2013年3月1日）に出された文書の段階で、「電子政府推奨暗号リスト」で推奨されているハッシュ関数はSHA-256以上です。
さらに、「実際に解読されるリスクが高まるなど、推奨すべき状態ではなくなったとCRYPTRECにより確認された暗号技術」とされながら、「互換性維持のために」という理由で継続利用を容認された「運用監視暗号リスト」に、2013年3月1日時点でSHA-1が含まれています。
MD5に至っては名前すら出てきません。もちろん、とっくに許容範囲外という意味で。
さて・・・では、現在運用されているパスワードのハッシュ関数で、MD5、SHA-1を使っているところは本当に無いのカナー？という話になります。
別の記事で触れた、今年見つかったCollection#1～#5で、漏えい元と見られるドメイン名から日本のサイトとみられ、かつ2013年3月以降に漏えいしたと見られるデータのうち、パスワードがMD5、SHA-1ハッシュのものが相当あるようですが。
パスワードの暗号化（ハッシュ化）に使われるリストも公開されていますが、きちんと対応しているところがどれだけあるか、という点には疑問があります。
そもそも、こういったリストやガイドを把握してない可能性すらあります。
先ほどの、パスワードの設定レベル自体が下手すると前世紀レベルのサイトで、パスワードの暗号化の基準は満たしているのか？と考えると、ほぼ無理なんじゃないかと思ってしまいます。
最新のガイドラインなどに準拠しているかを見ることにより、バックボーンとなっているシステムもどの程度か予測できちゃうものなのかもしれないですね。
また、見落とされがちなのが、Webシステムなどのログです。
例えば、パスワード変更画面のログで、各アイテムのパラメータを出力していると、IDやパスワードが出力されている場合があります。
これは、httpsで暗号通信でパスワードを送り、サーバ側でハッシュ化して検証している仕組みの場合ですね。
そんな初歩的なミスなんてしないと思うだろう？Twitterさんも去年やらかしてるよ！
Twitter、全3.3億人のユーザーにパスワード変更勧める告知 社内バグ発見で
https://www.itmedia.co.jp/news/articles/1805/04/news015.html
認証に関してあれこれ思うこと
セブンペイの事件で、二要素認証・二段階認証が話題になりました。
もちろん、このまま「いまどき、二要素認証・二段階認証を採用してないなんて有り得ない！」という風潮になるなら、それに越したことはないのですが。
一要素の認証が悪いかというと、そうとも言い切れないと思っています。
現実世界で三文判と実印があるように、セキュリティにも比較的簡易なものと厳密であるものがあって良いと思います。
その差を分けるのは、保持する情報の重要度によって考慮すべきだと思います。
名前、住所、生年月日、電話番号などの詳細な個人情報や、クレジットカードなどお金に関わる情報を扱う場合は、二要素認証・二段階認証を考慮すべきでしょう。
一方、ハンドル名程度（といっても、ハンドル名に実名らしきをつけていらっしゃる方も稀にはいますが）しか登録されないようなサイトや一時的なサイトであれば、パスワードだけでも十分かと思います。
もちろん、それでもパスワードの暗号化等は先に述べた水準を維持し、用済み後は速やかにオフラインに移動、可能であれば破棄が良いでしょう。
事件を起こした場合、特に大手だとニュースになり目立ちます。
しかし・・・。
「予備軍」なサイトは、実はまだあちこちにあったりするんじゃないか？というのが私の懸念です。
冒頭に挙げたようなサイトを見ると、「大丈夫かなぁ・・・ココ・・・」と思ってしまいます。
（あなたなら、ここに個人情報入れたいと思う・・・？）
最新のガイドラインをチェックしつつ、それにいかに準拠しているか？という観点でみることにより、対象のWebサイトやアプリがある程度セキュリティに対応しようとしているのか、無頓着なのかを判断できるかもしれません。
着眼点を得るためにも、ニュースや雑誌のセキュリティ関係の記事はチェックし、重要そうなものは目を通しておくといいかもしれません。