ISUCON9 レギュレーション違反の対応について [追記あり] : ISUCON公式Blog

9/12 22:00 自己申請による失格について再度検討を行った結果を追記しました 9/12 18:00 平文での格納について一部表現を変更しました 9/11 21:38 本選出場の取り消し無効にする対応を追記しました 9/11 17:30 bcrypt についての一部表現を訂正しました 9/11 17:09 経緯についての追記を行いました ISUCON9 予選においてレギュレーション違反があり、本選出場者の繰り上がり対応を行いました。 経緯としては、マニュアルの制約事項にあった「パスワードを平文で保存すること禁止する」が該当しました。パスワードの保存の規定については、ISUCONの競技の性質上すべてをチェックすることは難しく、参加者の申告に基づき判断をしております。そのため、競技終了後すぐに判断することは出来ずこのタイミングとなりました。 [9/11 17:30 追記] 運営の対応につい

[fukken]

強度と速度はある程度トレードオフの関係にある。「最適化」の対象にすることが間違っている。コンテストでは要件の是非（あるべき強度）を議論できない以上、「いじるな」にしかならない。

[koba789]

競技中の質問に返答がなかったのはシンプルに非があるなと思いつつ、こういう記事が運営からちゃんと出てくるのは心強い。運営も競技者も本気でやっているんで、外野がデタラメで悪評広めるのだけは許せない

[sisya]

「質問に未回答」と「ブログの内容で失格判断」は肯定と読み取れた。と、すると、いくら「ブログを書くと失格になるというのは間違い」と言われても、口を閉ざすことが最適解と思えてしまう。状況が打開できていない

[tenten0213]

軽量なハッシュ関数での代替を想定している対処法として書いてるけど、例えばmd5なんかは"一般的に推奨されない実装方法"な気がする。

[karikari1255]

"ISUCONの競技の性質上すべてをチェックすることは難しく、参加者の申告に基づき判断" これはダメでしょ。後出しじゃんけんだし、参加記を書くのがリスクになる。次回から厳格化するしかないのでは

[stk132]

"平文での格納は一般的に推奨されない実装方法" 強度の低いハッシュ関数に置き換えるのも一般的に推奨されないと思うんですが

[modal_soul]

参加者のブログを楽しみにしているので、ブログを書くと不利になるみたいな事例がでてくるのは残念ですね。質問しても回答がなく、終了後に判定されるなら、防御的にならざる負えないだろうし。難しい

[nkyn]

認証情報管理は昨今の状況から業界標準に倣うべきだと言う一方で、競技としての幅がなくなるのは嫌、というのはよくわからない。その思惑を持つなら認証関係改変不可で他で競技性を保つという案は出なかったのかな。

[thekoruku]

ブログ書くこと推奨しておきながら、その内容に問題あると言って失格にすると、次から二度とブログ書くチームなんて居なくなるでしょ。そしてそれは100%運営の責任ですよ

[eru01]

そもそも平文で保存するなってなんやねん。criteriaがあやふやすぎるやろ。ならシーザー暗号にすりゃええんか？って話になる。MD5は？強度と速度はトレードオフなんやから、コンテストするならその部分は固定しろや

[dekaino]

日本でありがちな 人治 >> 法治 な裁きは曖昧でアンフェアだ

[soratokimitonoaidani]

いろいろ考慮した結果失格を覆したようだ。早めに経緯を説明しているのも良い。

[flont]

運営は素早く対応したと思うけど、異なる定義を採用しているだけの人に悪意を認定したり、頑張ってる運営様に参加者風情がケチつけるなという主張が見られたりしたのは残念だった

[rryu]

出題者側もハッシュ化の強度を落とすチキンレースになることを想定していたのにルールで下限が明示できていなかったのに後付で失格にするのはさすがに運営側に落ち度があると思う。

[deep_one]

中盤まで読んで「二重否定文を書いてはいけません」という自然言語の注意事項に反したのが問題だという事が分かった。

[Kil]

「情報流出などの事件が発生しており、平文での格納は一般的に推奨されない実装方法だという認識を同時に持ち」を根拠としたら、軽量ハッシュに置き換えもしちゃあかんだろ。

[kz78]

運営もボランティと言われると、（外野が）あまりガミガミ言わんでも…とは思う。／まあ「他のチームにパスワード突破されたらペナルティ」とかやりようはあったろうと思うが。

[Ikalga]

「仕様を質問したにも関わらず明瞭な回答を得られなかったため自分の判断で実装しました」がダメだとおっしゃる。世の中の殆どのエンジニアが職を失いますな、はははは

[studymonster]

“ブログを書くと失格になるというのは間違いであり、内容に問題があれば対処を行うというだけですので” 問題があるかどうかの判定基準が「常識的に考えてわかるだろ」な曖昧さならブログ書かないのが最適解では。

[dnsystem]

bcryptは変更しないでねでよかったのでは

[jgoamakf]

「平文での格納は一般的に推奨されない」が、実際のWebアプリでは結構ある。

[macfan-hate7]

ふむ。で、結局運営の考える平文とはなんだったのか、、。

[nobububu]

そんなレギュレーションつけずに、良い子のみんな！パスワードを平文で保存していいのはISUCONの中だけだぞ！、にすりゃいいのに。どうせ実用無視したチューニングするんだから。RPOとかRTOとかそもそも考えてないだろ。

[augsUK]

ブログを書いて不利になるだけというのは、今後に大きな禍根を残しそう。終了後に参加者の指摘で判断という基準はあまりにもテキトーすぎない？平文の定義も、容易に復号できても平文でなけりゃOKとなるとなあ。

[BlueSkyDetector]

次回からは明確かつ現実的な暗号アルゴリズムを要件にするために、規格に則る方が良いのかも。例えばCRYPTREC暗号リストのアルゴリズムを使うこと、とか。平文の定義云々になって皆が消耗するのはもったいない。

[i178inaba]

“これからも楽しく、挑戦しがいのある問題や環境を作っていけるよう、皆様のご協力をいただければ幸いです。” 応援します！

[kemuken]

「本選出場の取り消し無効にする対応」　なんか1行目から「ん？どっちやねん？」て感じ。とは言え自分も「分かりにくい表現は避けるべき」って書こうとしたけど「分かりやすく書くべき」の方が分かりやすくて‥？

[moccos_info]

コンテスト系、何回もやっていると主催も参加者も前例に倣ってなあなあになりがち。たまにはこういうことがあると面白い。ブログで撃墜という最悪の対応だけど。

[shibacow]

昔のISUCON 全てカーネル空間で動くwebサーバ(爆速)とかも出てた。実環境では、カーネル空間で動くwebサーバは実用的でない。そういう方向のハックを許すべきだとは思う。 http://dsas.blog.klab.org/archives/52087898.html

[peketamin]

ちゃんと向き合おうとしている文章になぜか涙出そう

[kadzuya]

shaなんかも高速すぎてストレッチングの意味がないレベルだし、パスワードの暗号化には推奨されないよなあ。

[hachiking]

じゃあXORだけかけておくのが最適解みたいになっても欲しくはないし、きちんとレギュレーションで縛っておくべき場所だったと思う。ISUCONは昔の出題でもそういう穴をつけみたいな設問あったからそういう志向なのかな

[t_yamo]

本題とは別だけど、システム屋さんとして「見落として未回答」なのか「意図的に回答せず」なのかを判断可能にする運用設計は品質管理の観点から重要だと思う。「nullが『不定』なのか『その他』なのか」と同じで。

[jumitaka]

どう実装したかExcel方眼で詳細設計書いてもらえばよかったね

[hazisarashi]

ハッシュ化方式固定してユーザーデーブルのdump提出とかでチェックするのじゃダメだったのかな？

[masahiko_of_joytoy]

ISCON運営を庇いたいからって、今このタイミングで影響力のある人が発言するのはネガテイブだから控えた方がいいと思うよ

[atsushieno]

運営側の設問に瑕疵があって基準が曖昧になってしまった場合、どちらかというと運営側に「失格にする」判断を下す資格が無いと考えるほうが適切だろうから、わたしなら失格を取り消した現判断を支持するな。

[mirai-iro]

"9/11 21:38 本選出場の取り消し無効にする対応" なんかアカン対応パターンに入りつつあるのですがそれは

[dancel]

こういうのって将来身内贔屓するために拡大解釈して対象のチームを落とすとかできそうだよね

[sukoyakacha]

「未回答」が「無視」なのがロック。知り合いならリアクションくらいしたんだろうな