決められたレギュレーションの中で指定されたWebサービス（API）の高速化を
競い合うのがチューニングバトルがISUCONで、
ある意味、プログラミングでのＦ１と言えるのかもしれません。
LINEやさくらインターネット、メルカリなど、そうそうたる企業が運営実行委員会に名を連ね、
２０１３年の開始以来、２０１９年で７年目を迎えることになったものの、
パスワードに関するレギュレーション〈ルール）で平文NGでrot13がOKというのが物議を醸しだしています。
※ISUCONで「rot13」を使用したチーム（人）がいたのかどうかは、現段階では憶測でしかありません。
ISUCONのルールではパスワードの平文NGだけどrot13がOK？？
2019年のISUCON9予選では「椅子を売りたい人／買いたい人をつなげる」
フリマアプリ「ISUCARI」がお題のwebサービスとなっていました。
いったんは9月8日の時点でISUCON9予選2日目の結果が発表され、
本選出場者が決定を発表されたものの、9月11日になって、
レギュレーション（ルール）違反があったとして本選出場が決まっていたチームが失格となり、
予選敗退チームが繰り上がりになったと発表されました。
失格となった理由は「パスワードを平文で保存すること禁止する」という
マニュアルの制約事項に抵触したことが理由とされています。
このマニュアルがISUCON参加者のみの限定公開で、
どうやら一般公開されていなかったもの、
一歩踏み込んだ指摘をしている方のツイートがあります。
パスワードを安全にサーバーに保管するためには、
確かにパスワードに何の暗号化もせずに平文で保存するのは極めて危険で、
パスワードの平文保存ＮＧというISUCONのマニュアル規定は合理的です。
ただパスワードに暗号化処理をしようとするとその分、
処理が遅くなってしまうため、失格となったチームは
平文のパスワードにただ「＃」を加えるという斜め上の方法を選択。
パスワードの一部を加工しているとはいえ、
平文のまま保存しているとみなされてもおかしくはないと思われます。
その一方でパスワードの暗号化の中でも
「rot13」を採用していた人（チーム？）もいるらしく、
その人は失格とはならずに本選出場を果たしています。
rot13の暗号化処理はアルファベットを単純に
「１３文字後ろのアルファベットと置き換える」というモノなので、
様々な暗号化の中でも処理スピードが早いと言えます。
パスワードの平文NGでrot13がOKのISUCONのルールはパスワード強度無視？
そもそも「rot13」の処理が暗号化と言えるのかというと、
極めて疑問を感じざるを得ません。
rot13とは、言い方を変えるとアルファベットの並びを変えるだけにすぎず、
もし悪意のあるユーザーがrot13を使用しているのを見破ると、
簡単に元のパスワードにたどりつくことができるからです。
ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz
↓
NOPQRSTUVWXYZABCDEFGHIJKLMnopqrstuvwxyzabcdefghijklm
パスワードの安全性という点から考えると
（言い方は変ですが）暗号化処理を解読するのに時間がかかる（計算量が必要になる）
というのも重要な点となってきます。
今回のISUCONのルールでパスワードの平文NGで失格者を出したにも関わらず、
簡単に見破られてしまうrot13に関しては実質的に平文にあたらないと解釈できてしまうわけですが、
そうすると、ISUCONではパスワード強度に関しては評価の対象外、
という方針であると推測することもできます。
paypayや7payなど大規模なシステムセキュリティの事故が立て続けに起きていた手前、
ISUCONの今回の措置が妥当だったのかどうか？今後も議論を呼びそうです。
※繰り返しになりますが、ISUCONで「rot13」を使用したチーム（人）がいたのかどうかは、現段階では憶測でしかありません。
