EpisoPassのHTML公開の安全性
from EpisoPass
すでに元記事に書いてますが、EpisoPassのHTMLを公開することは、あなたのパスワードを危険に晒します
「EpisoPassのHTMLを公開することは、あなたのパスワードを危険に晒します」というのは事実ではありません
不具合やバグ報告は歓迎ですが、「良心」みたいな単語に違和感があります
淡々と報告していただけないでしょうか
「EpisoPassのHTML公開は危険ではないか?」みたいなタイトルなら良いのですが
私はEpisoPassのHTMLを何年も公開しているのですが、良心が無いとか馬鹿だとか言われてるみたいで不快です
タイトルから「良心」という言葉を消していただいてありがとうございました
以下議論が続きますが、は誓って増井氏に個人的・社会的攻撃を試みるものではなく、今回のパスワードツールが持つ社会的意義に鑑みての警告でした。
増井氏は長々とした僕の議論と批判に根気強く付き合っていただき、大変ありがたく感じています。
また、今回の議論に関して、増井氏を誹謗中傷したり、名誉が毀損されかねなかったことに関しては僕自身の全く目的とすることではなく、例えそうであったとしたら大変残念であると感じます。
以下は、私の指摘の一部はまだ議論の最中にありますが、増井氏は指摘を歓迎しており、議論に協力的にご参加いただけましたので、その結果、私の不明による多数の誤謬に基づいた、軽率な警告行動であったと大勢が判明いたしました。
その点心から謝罪申し上げます。ご迷惑をおかけいたしました。すみませんでした。
よく理解せずに警告をされているように思えますね
EpisoPassはセキュリティ関連の国内学会/国際学会で何度も発表しており、問題点は指摘されていません
Seedを公開していることは何の問題もありません
そうであれば十分空間は広いと言えることになります
これは通常のパスワードと同程度ですし、Nやkを増やせばいくらでも増やすことができます
Seedが短い場合は危険なので、ここはきちんと説明しておく必要はありそうです
めっちゃ議論が紛糾してますが、
安全な場合
HTMLを公開していない
HTMLを公開していたとしても、以下の条件を満たす
1. シードが長い
2. 生成された文字のうち、英字の部分の長さが長い
英字6字、数字8字だと、「英数字混合パスワード」で8字〜9字程度の強度です。
記号が含まれないので若干不安な気もしますが
英字分の長さ+アルファぐらいの強度と思っていただければいいのではないでしょうか
英字の長さn, 数字の長さmとして、52^n \cdot 10^m > 62^n \iff m > n\log_{10}(62/52) \approx 0.076nなので、ほぼ英字分の強度は保証されます
あくまで英数字のみのパスワードでの換算です
3. 選択肢と問題数が十分に多い
現在は、「そもそもこのツールの安全性の指標って何ですか？（エントロピーの計算おかしくないですか？）」という質問を僕がやっているところです
計算がおかしいとは? 
以下のminimumを含めたエントロピーにすべきでは？ということです
そこがないなら取り下げます
生成パタンは、アルゴリズムが公開されているのだから「固定」になるのでしょうかね
あ、いえ、生成が例えば英字6+数字8みたいなパターンにはなりませんよね？ということです
これは、生成するパターン数を一気に下げているように見えますし、実際に公開されているHTMLはそうなっているように拝見しましたが。。。。
確かに英字/数字のパタンはわかってしまうから私の計算はおかしいかもしれませんね...
ちょww
えーと
。。。どうします？
オフライン攻撃が可能な状況じゃなきゃ困ることはないでしょうね
まぁそれはそうかもしれませんが
僕としては探索数を下げていることが相応に心配なのですが。。。
心配なサービスでは問題を増やすか文字長を増やせばいいでしょうね
いやしかしそれはもちろんそうですが、暗号ツールとしては、、、
以下の試算はかなり良心的なので、実際はもう少し探索空間が下がってると思いますよ
そも利用者側としてきちんと試算は出して欲しくなるのではないでしょうか
Seedの文字長が長ければ問題なくないですかね
いやその「運用の問題」と言ってしまうのは簡単ですが
たとえばSeedが2桁なら駄目なのは明白ですよね
100回試せば当たる
PINの場合、数字であることは明白だから10000回試せばいいことになる
PINが数字なことがわかるからEpisoPassは危険だとか言ってるのと同じじゃないですか?
うーんと、議論を大局的な視点に戻したいんですが、暗号の議論をする場合に必要なのは、暗号の文字数に比しての安全性だとは考えます。
その上で、例えばPINとかであれば試行数の方を大幅に制限する、などの特別な制約をかけているわけですよね。
それはWebサービスでも同じですよね
それで、今回のような「汎用暗号ツール」として利用する場合には、どんな種類の暗号なのかをあまり特定しないほうが
汎用暗号ツールなんて言ってないですよ
実際のWebサービスのパスワードに利用できればいいと思っています
それは確かに、サービスのコンセプトを、「ある程度文字が長く、一定程度（どのくらい？）の探索数の減少を許容して、パスワードを効率的に記憶できるようにする」という形にするならば納得できます。
最初からそういうコンセプトです
利用者にもそうやって伝えている、ということですね。
恥ずかしながら、利用者なんてほぼ皆無です
Seedが短いとマズいというのはそのとおりなので、明記した方がよさそうですね
少なくとも、ここの住人の皆さんは増井さんのプロダクトを心から歓迎していたように拝見しました。
どれほど少なかろうと、きちんと説明を果たされた方が、その方の信頼に応えることになると思います
残念ながら、本当にユーザは少ないです
Seedが極端に短いと駄目だということは言っておいた方がいいでしょうね
また、Seedとかを公開することを推奨してるわけではありませんよ
もちろんそうでしょうが、「利便性」の目的から、そういうユースケースをご自身でお話しし、実践なさっていたはずです。
私は極端なユースケースを人柱してるだけです
そうだとしても、だと思いますよ。
まぁ僕としては、増井さんの制作物を歓迎し、興味を持ち、少なかったとしてもそれを実際に利用している人たちと、増井さん自身への善意を実践したいと思うかぎりです。。。
長所と短所の双方を明確に伝え、どう行動するのか判断の材料を真摯に与える、ということです
「善意を実践」という意味が不明ですね
あまり自分の行動を善意とか真摯とか言わない方がいいんじゃないですかね
どういう意味ですか？
何かを指摘するとき善意があろうがなかろうが関係ないです
いいえ、明確に関係しています。
それは増井さん自身だけに限る問題ではないからでもあります。
もしも増井さんがこの制作物を誰にも公表していない場合、僕の善意とは「増井さんに内々に伝える」ということでした
しかしたとえそれがどんなに反響に乏しかったとしても、公表する必要性は、そこ（すでに公表されているという点）にあります
善意で指摘してあげてるんだ、という意識は鬱陶しいですよ
自分は善意で行動しているんだ、という表明が鬱陶しいんですよ
あなたがどう思うか、だけではなくて、あなたの制作物を歓迎し、そして興味を持ち、利用してみた、あるいは今も利用している、というひとたちに向けての、「増井さんの善意」の問題でもあるんですが、
僕が「私は善意で行動している」ということを、私と増井さんだけの問題でわざわざ出したりはしませんよ
その善意はそもそも全くなく、いわんや私から喚起されることも今後一切ありえないのだ、という話であれば、私と増井さんはその時、「他の人たちに対してどうするか」という点で対立関係に突入することになります。それを戦う意思も、それを嫌だと思う心も、私にはありますよ
ちょっと何を言ってるのかわからないのでまた後で...
どんなシステムでも穴はみつかるものです。それは直せば良いというものではありませんか?
問題の指摘はありがたいですが、問題指摘するだけではあまり嬉しくないですね
解決法はあるわけだし
直すかどうかは説明しつつ、今後どうしていくのかを伝えれば良いと思います
※は完全にEpisoPassを理解したわけではありません。訂正があれば教えてください。
EpisoPassのHTMLにはSeedが直で記載されています。また、数字と英字のパターン、そして文字数が固定されている場合があります。この場合、あなたのパスワードに攻撃を試みるものは、あなたのEpisoPassを入手することで、労力が大体1万分の1とかになったりします。
これは誤解ですね
Seedが充分長ければ問題ありません
「攻撃者がEpisoPassを知る前に、パスワード文字数を知っていた」かつ、「パスワードには英数字しか許されていなかった」という良心的な仮定のもと、実際に公開されているEpisoPass のHTMLが攻撃者に入手される前後での探索数の減少の試算
この場合、攻撃者はあなたのパスワードを、元の10万分の4の労力で手に入れることになります。
52^6+8^10 じゃなくて 26^6 \times 10^8じゃないですか この場合、(26^6 \times 10^8) / 30^{10} = 52.3 になりますね
jsalert((26**6)*(10**8)/(30**10))おおっと
もし間違ってたら謝ります
検算してみますね
そもそも僕の計算ガバガバでした
まず分母の桁数が14(30^{14})で、分子も足し算になっていた
大幅に指標が改善しましたね（1割っちゃいますが）
え、30の14乗？俺どこから出したんやこれ
あ選択肢の数だわ
ん？
分母62の14乗では
あーこれ追加の議論をするために、選択肢の数で割ってたやつですわ。。。。ほんと申し訳ない
生成数/本来のパスワード数 にしないといけないところを、 EpisoPass生成数/EpisoPass総選択肢数 をやってました興奮してたんでボロがいっぱい。。。
ほんと申し訳ないんですが、こちらになると思います
{62}^{14}というのは変でしょう。EpisoPassの選択だと{30}^{10}ですよね
ええ、ですから、EpisoPassの選択は複数の選択のやり方において重複する、ということを意味します
ん？違うね？
{62}^{14}は、「14桁の英数字パスワード」の探索空間であり、30^{10}が、EpisoPass総選択数です。
混同してはいけないのは、30^{10}選択肢数で、52^6 \times 10^8が、実際に出力できるパターンの数です。
あ、どこが数字かわからない場合とわかる場合の比較をしたということですか
だとするとEpisoPassはもう関係ない話ですかね
どこが英字でどこが数字かわかると探索空間が減るというのはそのとおりですが、EpisoPassの運用とはあまり関係なくなりますね
「どこが英字でどこが数字かはもともと攻撃者は知らない」、と前提できたはずで、EpisoPassをしれば、何桁まで英字で、その後数字である、ということがわかってしまうという意味です
それはわかりましたが、それがわかってもSeedが長ければ関係ないということです
なるほど、確かに30^{10} \ll 52^6\times10^8なので、Seedが長ければ、「文字列長さに比した強度」は低いけれども、選択肢分の強度は維持している、というわけですね
なるほど。。。
わかりました。こちらの警告は取り下げさせていただきます。お時間をおとらせし、お騒がせいたしました。
議論蒸し返すみたいなんですけど、これ英字と数字の比率＆生成文字列の長さってどう決まってるんですかね
Adobe_masui@keio.jpだと割りますねw
47選択肢であり、かつ生成文字長がより短いので。。。
ふとした時にサクッと割ってしまう
でも問題数もユーザーに委ねられているから「安全性の担保」が「運用側の責任」になる、なるほど。。。
サーバでいろんな制約があることが多いので文字種をユーザが指定できるようにしています
それ自体は重要だと思います。「順序を混合して欲しい」というただそれだけです
先頭文字は大文字じゃなきゃ駄目、みたいな制約がある可能性もありますから混合はできないですね
え……そんなサービスが存在する……あ、あくまで可能性の話ですね。びっくりした……
先頭一字を、例えば
A に固定しても同じことができます。 A+生成文字列 的なまぁ揚げ足ですけど
そんな面倒臭い仕様は嫌です...
えーでも一気に探索空間ひろがりますよ。。。w
サーバでパスワード文字に制約かけるのは馬鹿そのものだと思いますけどね
思ったんですが、選択肢数がユーザーに委ねられていて、文字数も可変で、発表の際にはどの部分が「安全性」の指標に入ったんですか？
素朴な疑問です
総選択肢数が安全性の根拠にそもそもなっていないように見えます
例えば極端な例として「全て数字」で14桁出してしまうと、どんなに選択肢があっても相当脆弱とみなされうるじゃないですか。
他にも、「選択肢の数」はユーザーが決めるので、事前に計算できる選択肢数がないということもあります
ちょっと意味がわかりません
選択肢の数はユーザーが決める一方で、暗号パスワードツールの安全性は事前に計算して発表するわけですよね？
発表って何ですか?
パスワードの強度の話と暗号の話は全然違いますよ
パスワードの場合はエントロピーの計算をします
エントロピーの計算には選択肢数を用いたのでは？
そうです。何か問題が?
しかし選択肢数はユーザーが決める。。。
なるほど、指数的増加でさえあれば安全である、という根拠なわけですね、なるほど、それでエントロピー
しかし実際に生成されたパターンではそれを割りうるわけですよね。。。
変な問題作ったり、選択肢が少なかったり、Seedが短かかったりすると全部駄目です
そのあたりは常識的に利用してもらうしかないでしょうね
それはそうなんですが、そういう「変な運用」は別にエントロピーの数式（選択肢数に応じて生成するパターンの数が指数的に増大する）には沿っているんじゃないんですか？
ちょっと意味がわかりません
ちょっとわかりやすい説明をお願いします。少し抜けます。
Seedが長ければ大丈夫でしょう
Seedを公開していなければですよね
いいえ、長ければ公開しても大丈夫です
何故でしょう? 充分根拠になると思いますが
僕が言いたいことを数式を用いて改めてまとめますと、以下の通りです
N^kで総選択肢数を計算することができる
しかし実際に生成されたパターンでは、生成パターン数が最大52^{n}\times10^{m}であることを攻撃者に容易に知られてしまう。
n:英字の桁数、m:数字の桁数
同時に、n,m,N,kは攻撃者も知ることができる
また、N^k < 52^{n}\times10^{m}が保証されていない
不等号が反転する場合、複数の選択肢で同じ結果が出る
従って、このツールの本来のエントロピーは\log_2(\min(N^k, 52^{n}\times10^{m}))である。
同時に、N^k > 52^{n}\times10^{m}は一般の利用法でも発生しうる
よって、エントロピーは過大に見積もられており、製作者・利用者はこの点を看過するべきでない
で、N^k > 52^{n}\times10^{m}がかなりやばくね？という話ですね
52^{n}\times10^{m}は本当に心配すべき探索空間の大きさなのか？by
基準として、英字の長さととの比較を考える
Seedが長ければ問題ないということだと思います
分子も分母も滅茶苦茶デカいから、比率はあまり関係ないでしょうね
ちょこちょこrefactoringしています
元の文章から意味は変えていないつもりですが、変わっていたらすみません
もし余計な行動でしたら謝ります。その場合はこれ以上いじりません
A ZA SU
seedと問題データを公開していたとしても、ログイン先サービスがDDos攻撃対策をしていれば、かつそのときに限り安全性は保たれると思います
正確には、回答パターン数よりログイン先サービスのパスワード入力の試行上限が多ければ問題ない
与えられた文字列が正しいパスワードかどうかを何回でも検証できるシステムMが存在しなければ、seedと問題データを公開しても問題ないと考えています
ここから安全性が保たれないケースを導くことが出来ます。例えば
何度でもパスワードを試せるサービス
要はDDos攻撃対策なしのサービス
同一のパスワードを出力できると分かっている別のEpisopass HTML
/EpisoPass/EpisoPassの脆弱性で言及されているやつ
(この辺りはまた整理して説明し直します)
ちなみに安全性の話はさんの論文が詳しいです
EpisoPassの脆弱性はいろいろ考えられます
私が気付いていないものもあるかもしれませんので指摘は歓迎です
今回の指摘「Seedを公開していると危険」というのは大きな問題とは思われません
選択肢を多くして長いSeedを使えば大丈夫だからです
善意とか良心とかいう言葉は消してほしいです
バグとか不具合とか報告するときいちいち善意だの良心だの言うのはウザいからです
善意というのは、脆弱性に僕が懸念して、警告の動機を支えるものが僕の議論に対する真剣さであるということだけを意味するものです。
一般に含意されるような「善意だから受け取れ」という意味ではないです。
残念ながら私にはそういう理解はできませんでした
繰り返しますが、僕はこの警告が他人の今後を考える上で重要であると思っていて、「僕の発言に過誤があれば直すから、はっきりさせて欲しい」という意味で、「善意」だと言っています
うーん、善意ではなく別の言葉(ラベル)を使ったほうがいいですね
強いて言えば善意#61471a4e1280f000000c4e3bと方向性が似ていますが、↑を示すにはさすがに「善意」だと役不足です
また「善意」で「僕の発言に過誤があれば直すから、はっきりさせて欲しい」という意味を表すのはさすがに無茶だと思います
他者のためから解釈できないことはないけど、飛躍がすぎる
それが「善意を実践したい」という発言です
言いたいことはわかりますが、いくつか引っかかります
「誤りがあれば直す」ということを明示するのは問題ないと思いますが、それを「善意」という単語で表すのは語義から考えて無理があると思います
単に「誤りがあれば直すのでご指摘ください」とそのまま書くだけでいいんじゃないかな～っと
↑に同意。「過誤があれば直すから、はっきりさせて欲しい」というのはごく普通のことであり、そんなことを「善意」と表現してほしくないです
善意などの感情を持ち込まずに指摘を行うことは十分可能です
Githubの存在を知っているならば，問題提起・報告としてのGithub issueやそれを解決したものを提示できるPull Requestなどがあります
実際にOSSに貢献する際に"善意"や"良心"などの表現が出る場面は非常に稀(少なくとも私は未見)のように思います
利用者の数と関係なく淡々と報告が行われています
何かのシステムの問題を指摘するとき"善意", "悪意"といった単語は不要
個人的な感情を表明することは(客観的な言葉を使わないことは)ノイズです
「善意」という単語に違和感があるという意見なので、まぁいろいろ考えの違いはあるでしょうね
しかし自分の意見に「善意」という言葉をつけるのは強烈に違和感があります
感覚というか、議論の前提として「この件に関しては、他人への影響を自己利益抜きで考えようと努めます」という宣誓。。。？
これは裏に「議論では論理的な正しさや知的探求ではなく、自分もしくは自分の集団が有利になるような誘導を行うことがある」という暗黙の前提があるのでしょうか？
見当違いな深読みだったらすみません。
自分は利益誘導をするようなものは議論の形をした別の何かだと思っているので、議論
(自分でもなにを言いたいのかわからなくなってきたので一旦revert)
まぁそこに「くどさ」があるというのはそうだと思います
言語感覚が違うと言われればそれまでですが、全く賛同はできないです
「自分は「善意」でこれをやってる」などと表明する人の意見は聞きたくないです
なるほど、「善意」であることを信じて疑わない人間とは話がしたくない、というのは僕もわかります
したくありません
しかし何度も言ってるように、「結果として」善意と呼べるような結論へ向かっていこうという前提でもあります
別の言葉を使ってもらえないですか?
その点についてはいい言葉があれば積極的に使おうと思います
今回の議論の結論が他人に与える影響に対して責任を持ちます、という表明がしたいだけなので
別の言葉でお願いします
でも「真摯」もだめなんですよね？
ダメです
こう、そうするとその責任感そのものへの反感という風にも。。。
もっと客観的な言葉を使ってもらえませんかね
「頑張ります!」みたいなのと変わらないですよ
いやそれですよ
そもそも大前提として責任を持たないなら議論をする意味はないですよね？
適当言ってるだけなんですが警告します〜とか害悪すぎません？
責任って何ですか。どこからそんな話が出てきたんですか?
バグや問題があるなら淡々と報告すればいいんじゃないですか?
まぁやっぱり態度への反感だと思うんですよ
そうですね。不具合報告に善意だの良心だの真摯だの言ってほしくないです
不具合報告ではないからですね。。。
警告だったわけで
だったら私が善意や良心が無いから不具合を放置してたとでも?
不具合報告は元の記事の方でもやってましたが
いいえ、そうではないです
そう読めるから嫌だと言ってるんです
その点は確かにそうだと思いました。その点は謝罪します。すみません。
僕としては、元の警告の根拠があれば追認していただき、そうでなければ取り下げるのが妥当と判断しました
不具合や懸念点について報告いただくのはありがたいことです。しかしそこで良心だの善意だのという言葉を使うことに違和感があると言っているのです
そうですね、今回の件で当方に問題があると思うのは、警告の根拠がだんだん薄れていく中で、懸念点・不具合の報告へと境界なくシフトして行ったことです。
今更ながら、今回の件は警告するほどでないと考えましたので、先ほど表題を変更させていただきました。
不具合・懸念点の報告において「善意」を使用することについては、意見の相違はありません。善意とは僕があくまで周囲への警告の根拠として述べたものにすぎません。
その点ご理解いただければ、違和感なく僕の主張を理解していただけるのではと期待しています
単語の利用をやめていただかない限り違和感は消えないです
他のみなさんも違和感ないなら仕方ありませんが
自分の行動の説明に「善意」という単語を使うのは違和感しかありません
不具合・懸念点の報告と、周囲への警告の趣旨の違いをご理解いただいた上で、それでもなお「善意」に納得していただけないのであれば、僕の方もちょっと
何度も言いますが、「善意」という言葉は違和感しかありません
システムの不具合報告にそんな言葉が使われている例はないと思いますので
すみません、腹痛がやばいので一旦抜けます。。。
不具合の懸念を表明していただくのはありがたいですし、表題を変えていただいてよかったと思いますが、良心だの善意だのという言葉を使うことに関しては慎重になっていただきたいと思います
「善意で言ってるんだが、お前のシステムは糞だ」とか言われたらどうします?
そのとおりだと言えば、糞だということを認めることになる
それは違うと言えば、他人の善意を否定することになる
「根拠が客観的に違う。故に、これ以降継続すればそれは善意ではなく、エゴだ」
という論法をぜひ知っていただきたいです。
ちょっと意味がわかりません
見てる
ざっとまとめるとこんな感じ？
EpisoPassには十分なセキュリティ（十分でかい探索空間）を担保する能力がある
しかし、seedと質問の設定の仕方によっては十分にならないことも
この「利用者によって十分にならないことがある問題」をどうするか、でスタンスが複数
スタンス1
>選択肢を多くして長いSeedを使えば大丈夫だからですEpisoPassのHTML公開の安全性#61472b868ee92a0000e291e6
つまり「十分になるような設定にすればいい」
スタンス2
>以下のminimumを含めたエントロピーにすべきでは？ということです EpisoPassのHTML公開の安全性#614733c9666872000037468d
つまり「評価指標に "十分にならないこともある" という点も加えたい」
特に問題なのは、脆弱なもの、突破可能なものを攻撃者が容易に計算でき、桁数などに対してツールのサポートが不明って点ですね
でもシード長くすれば桁数増えるってことなんかな？
それなら別にいいや
補足ありがとうございます
seedのパターンがある程度わかる問題
>「どこが英字でどこが数字かはもともと攻撃者は知らない」、と前提できたはずで、EpisoPassをしれば、何桁まで英字で、その後数字である、ということがわかってしまうという意味です EpisoPassのHTML公開の安全性#6146ffa7666872000037e7b0
が、これは「seed長くすれば問題ない」で落着
善意の話