アカウント名:
パスワード:
アルファベットの大文字と小文字、更に数字と記号を含めた8文字以上のパスワードなら安全、という古からの安全神話。その安全神話によって思考停止しているので、最小8文字以上としながらも最大パスワード長は20文字以下しか認めないサイトのなんと多いことか・・・。20文字以下どころか、12文字以下しか認めない所の方が大半という体たらく。
パスワードは複雑度よりもむしろ長さの方が重要だと、一体何時になったら周知徹底されるのか。10代の若者に「パスワードを複雑化しろ」と要請するよりも、パスワードとして認められる最大長が20文字以下のクソサイトを吊るしあげる方が遥かに効果的だろう。辞書に載ってるような単語の組み合わせでいいから、最小パスワード長を35文字とし、最大パスワード長を100文字以下にするべき。その長さ至った時点で辞書攻撃のリスクなど無視して良し。というより、その程度の計算すらできずに、パスワードを複雑化すれば12文字以下でも大丈夫と考える、思考停止した老害を量産するのはそろそろ止めにして貰いたい。
# 某銀行、テメーのことだよ。# なにが大小英数字と記号を2文字以上混ぜてパスワードを作って下さいだ?# 利用者にそんな余計な手間暇かけさせるよりも先に、最大パスワード長16文字とかいうしょうもない制限をどうにかしろ。
パスワードの文字数制限が厳しいサイトって、いまだに DES ベースのアルゴリズムでハッシュ化しているんじゃないですかね? 「動いているシステムには触るな」を信じ続けて……。大手クレジットカード会社も、MUFGカード(4~8桁) とか NICOSカード (6~8桁) とか、酷い状況です。
前にもスラドで話題になりましたが [srad.jp]、「ランダムな英数記号8文字」 よりも 「ランダムな英単語4個」 の方が安全で覚えやすいのですから、こういったくだらないキャンペーンをやる前に、IPAにはシステム管理者にパスワードの文字数制限を緩和するよう啓蒙していただきたいです。
ランダムな英数記号8文字 : p$9hFh%Eランダムな英単語4個 : copy-item-tokyo-heavy ※後者の方が、安全で覚えやすいパスワード(パスフレーズ)ですが、文字数が21文字なのでスラッシュドットを含む多くのWebサイトで利用できません。
--
ところで、hylom さん、/.J のパスワードの文字数制限を緩和してみては如何ですか?
もし、ハッシュ化して保存しているのであれば、コードの文字数制限の部分を「20」から「255」などに変更するだけで、面倒な手間も無く動作するのでは?
クライアント証明書に…いやなんでもない
SSL v2に…いやなんでもない
> パスワードの最大文字数を増やそうって主張には同意なのですが、/.JにはまずSSL対応して欲しいです。
なんのために?って思ったけど、ログインするときセキュアじゃないのですね。なんで、セキュアじゃないのにログインしようとするのかわからない。
セキュアじゃないのにログインしておいて SSL対応して欲しいとかおかしいです。
…とかですかね。 気分的には「httpな掲示板で再編集用のパスワードを設定」しているような感じです。 全然セキュアでないけどまあ使うかみたいな。 どのみちSSL対応してもらった方が
とかメリットのが確実に多いので気長にSSL対応を待っているのです。
# 某銀行、テメーのことだよ。# なにが大小英数字と記号を2文字以上混ぜてパスワードを作って下さいだ?
かつてのみずほ銀行は強制的に6文字でぶった切ってくれましたがなにか?
かつての大○証券はパスワード=暗証番号と同じ数字4桁でした。メールでやんわりと良くないと教えたのですが、逆ギレされたので解約した思ひ出。つーか今見てみたら、今だにパスワード4桁からじゃんwwww
倉吉の大山証券なら、もう20年近く前に合併で名前が変わってますよ。
SSLの暗号スイートでも輸出強度暗号を有効にしててもろにFREAKに脆弱だったし。ひろみちゅ逆張リストがなんか言ってたけどやっぱりアホなコンサルか何かのたわ言をまに受けただけでしょ。# 日本では少ないようだがBEASTのときにRC4以外を無効にして以来知識を更新できていない銀行やら航空会社やらはマジ絶滅しろ
>パスワードは複雑度よりもむしろ長さの方が重要だと、一体何時になったら周知徹底されるのか。
パスワードの「重要」というのはよくわからないけど、安全面から考えると。
・使い回ししない・適宜変更する・多段階認証
とかは奨励されないんすかね。
銀行ATMやdocomoのいろんなパスワードとかが未だに数字4桁で、容易に変更できないかユーザにそのやりかたを周知できていないみたいだってのがずっと怖いなぁとは思ってる。
大筋に同意するけど現在のトレンドは多要素認証だろ
文字数による安全性もそのうち幻想になるとおもうけどねもうプルートなんて時代じゃないし
もうプルートなんて時代じゃないし
プ(pu)ルート、って、ブ(bu)ルートフォースアタックのブルート?だとしたら、プとブの違いは無視するとしても、その略し方は初めて聞きました。
まぁ、それは置いておいて、確かに、最近よく聞くのは、他のシステムから流出したパスワードを使ってって方法が多いから、パスワードの強度自体ももちろん(だし、他コメでも上がってるん)だけど使いまわししない、ってのが重要になってるよねぇ。
ハッシュ関数にMD5を使っているならどれだけパスワードを長くしてもランダムな英数字約20文字、SHA1なら約25文字、SHA256なら約40文字より安全には絶対にならない。覚えやすくなるだけ(でも十分だしいずれにしても12文字は少なすぎるが)。パスワードに不可逆なハッシュ化をしていないとか暗号学的な検討のなされていないオレオレハッシュを使うのは別の意味で論外だし。辞書に載っている単語だけを組み合わせるならMD5で約11語、SHA1で約13語、SHA256で約21語の組み合わせ程度でいいけど、これは完全にランダムに単語を選んだ場合なのでパスフレーズジェネレーターでも使わない限りもう少し長くとったほうがよさそう。
まず、MD5 や SHA-1 は、そもそも暗号学的ハッシュ関数としての脆弱性が発見されているから、パスワードのハッシュ化に使うべきかどうかとの議論以前に、今では如何なる用途においても優位性がありません。転送中にファイルが破損(改ざんではなく通信中のノイズなどによる偶然の破損)したか調べる為には使えますが、だったら CRC32 などの方がより高速です。
そして、暗号学的ハッシュ関数として安全とされている SHA-2 (SHA-256 など) であっても、暗号学的高速ハッシュ関数はパスワードのハッシュ化に用いるべきではありません。これらは、高速にハッシュ値を求めるための関数であって、パスワードの保存に用いる為に開発されたものではないからです。詳しいことは、安全なパスワードハッシュ [php.net] が分かりやすいです。
もし、専門的知識があるなら、適切なソルトを付けたり、暗号学的高速ハッシュ関数を適切な回数通したり、各ユーザのハッシュをユニークにしたりするなど、自分で安全になるようなコードを書くことができるという考えもあるかもしれません。しかし、独自の暗号アルゴリズムを開発して厳重な秘密管理をするよりも公開されている安全とされるアルゴリズムを使うべきであるのと同様に、HMAC [wikipedia.org]、PBKDF2 [wikipedia.org]、Bcrypt [openwall.com] といったパスワードのハッシュ化に適しているスキームとして十分な検証がなされているものを用いるべきだと思います。
更に良いのは、password_hash [php.net] といったパスワードハッシュ専用の API を用いることです。パスワードのハッシュ化に適しているスキームとして十分な検証がなされているハッシュ関数(現在は bcrypt)が用いられますし、サーバーをベンチマークして適切な強度のストレッチングを行うことが簡単にできます。サーバのスペックが上がったらコード変更無しにストレッチング強度を自動的に高めるとか、負荷が少ない時間帯はストレッチングの強度をあげるといったことも簡単にできます。また、将来的により強力なアルゴリズムが現れれば php のアップデートで自動的にパスワードハッシュアルゴリズムが切り替わる仕様になっているので、古いプログラムコードが使われ続けていたとしても、安全性を維持することができます(データ長が将来的に増えることも想定されており、パスワードハッシュを格納するデータベースのデータ長に余裕を持たせることが推奨されています)。
ソルト導入すべしってのは当然だけど、ストレッチングは微妙だなぁ…攻撃側はGPGPUやFPGAで演算コストを抑えてるのに対して、防衛側は汎用CPUでそこそこの最適化しかしてない。防衛側のほうが支払うコストが高い対策ってのは「急場凌ぎの対処法」であって「解決法」とはならない気がします。
使えるのは余剰の演算コストだけと考えると深いストレッチも出来ないので結構辛い。
防衛側のほうが支払うコストが高い対策ってのは「急場凌ぎの対処法」であって「解決法」とはならない気がします。
確かに、1回のストレッチングにかかるコストという意味では、防御側より攻撃側の方が大幅に低いです。しかしながら、防御側はパスワードの認証・登録・変更が行われた時のみストレッチング処理を所定の回数行えば良いのに対して、攻撃側は総当たり攻撃のパターン数の分行わなければならないため、トータルでは攻撃側が支払うコストが上回っていると言えます。
具体的な例を挙げると、パスワードの認証(ログイン)・新規登録(アカウント追加)・パスワード変更の回数が1日1万回のシステムで、ストレッチングの回数が10万回の場合、防御側が行うストレッチング処理は10億回/日 です。それに対して、8桁のランダムな英数字のパスワードを破ろうとした場合、攻撃側は全通り試すならば 218,340,105,584,896 通り試す必要があるので、ストレッチング処理を 100,000 × 218,340,105,584,896 =21,834,010,558,489,600,000 (回) する必要があります。つまり、この場合(8桁のランダムな英数字のパスワードを全通り試す場合)、攻撃側は防御側の 21,834,010,558倍 (約200億倍) の処理コストがかかると言えます。
ちなみに、以前試算しましたが [srad.jp]、日本の理化学研究所のスパコン「京」のCPUで、まともなアルゴリズムでハッシュ化(HMACハッシュ関数によるストレッチングを含む)されているパスワードの解析を行う場合、1秒間に1万回しか試行できないという結果になりました。この場合、GPU演算は考慮していませんでしたが、攻撃側がNSAなどの巨大組織でない限り、GPGPUやFPGAを使ったとしてもスパコン「京」のCPU演算を超えるだけの能力をはじき出すのはなかなか難しいのではないでしょうか。
1秒間に1万回の試行であれば、ランダムな英数字8桁のパスワードの場合、平均で400年ぐらいの解読時間がかかることになります。従って、ユーザーが8桁のランダムな英数字、もしくはそれを超える安全性のパスワード(ランダムな英単語4個 : copy-item-tokyo-heavy など)を使ってくれるという前提においては、ストレッチングは「急場凌ぎの対処法」ではなく「解決法」と言えると思います。
オフトピ。
MD5, SHA1って。。。。すでに2007年の時点で ありがとうそしてさようなら [google.com]という認識でいたのですが、今でも大事にされているんですか?そうわりきるしかないという現状を憂えているということですね、きっと。
それにしてはSHA-2(SHA-256)への移行がまだゆるゆる進んでいないみたいだし、そもそも今の若い人(a.k.a. 労害労害いう人)が引退するころにはそれも破られているだろうし。。。
探索時間で考えるならハッシュ空間全部使いきらなくても良い気がするとか考えるのはヘタレでしょうか?
>アルファベットの大文字と小文字、更に数字と記号を含めた8文字以上のパスワードなら安全、という古からの安全神話。
ごめん、それ初めて見たもしかして利用可能文字と推奨パスワード例のことじゃないよね
ANAなんて、つい最近まで数字4文字でしたが。三井住友VISAの8文字制限も酷い。
あと、多段階の認証にしたり(新生銀行とか)、用途毎に複数のパスワードを設定させるとか(住信SBIネット銀行とか)もやめてくれ。やめなくてもいいけど、20文字以上のパスワードを設定すれば、一段階認証でもいい、とかにしてください。
3回連続で間違ったら30秒待たせるとかやればいいんじゃね?
それリバースブルートフォースアタックに無力なんで、間違える・間違えないに関わらずパスワード入力後、必ず3秒待たせる、とかの方がいい。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
逆に危険 (スコア:4, すばらしい洞察)
アルファベットの大文字と小文字、更に数字と記号を含めた8文字以上のパスワードなら安全、という古からの安全神話。
その安全神話によって思考停止しているので、最小8文字以上としながらも最大パスワード長は20文字以下しか認めないサイトのなんと多いことか・・・。
20文字以下どころか、12文字以下しか認めない所の方が大半という体たらく。
パスワードは複雑度よりもむしろ長さの方が重要だと、一体何時になったら周知徹底されるのか。
10代の若者に「パスワードを複雑化しろ」と要請するよりも、パスワードとして認められる最大長が20文字以下のクソサイトを吊るしあげる方が遥かに効果的だろう。
辞書に載ってるような単語の組み合わせでいいから、最小パスワード長を35文字とし、最大パスワード長を100文字以下にするべき。
その長さ至った時点で辞書攻撃のリスクなど無視して良し。
というより、その程度の計算すらできずに、パスワードを複雑化すれば12文字以下でも大丈夫と考える、思考停止した老害を量産するのはそろそろ止めにして貰いたい。
# 某銀行、テメーのことだよ。
# なにが大小英数字と記号を2文字以上混ぜてパスワードを作って下さいだ?
# 利用者にそんな余計な手間暇かけさせるよりも先に、最大パスワード長16文字とかいうしょうもない制限をどうにかしろ。
IPAは、パスワードの文字数制限を緩和するよう啓蒙すべき (スコア:5, 参考になる)
パスワードの文字数制限が厳しいサイトって、いまだに DES ベースのアルゴリズムでハッシュ化しているんじゃないですかね? 「動いているシステムには触るな」を信じ続けて……。大手クレジットカード会社も、MUFGカード(4~8桁) とか NICOSカード (6~8桁) とか、酷い状況です。
前にもスラドで話題になりましたが [srad.jp]、「ランダムな英数記号8文字」 よりも 「ランダムな英単語4個」 の方が安全で覚えやすいのですから、こういったくだらないキャンペーンをやる前に、IPAにはシステム管理者にパスワードの文字数制限を緩和するよう啓蒙していただきたいです。
--
ところで、hylom さん、/.J のパスワードの文字数制限を緩和してみては如何ですか?
もし、ハッシュ化して保存しているのであれば、コードの文字数制限の部分を「20」から「255」などに変更するだけで、面倒な手間も無く動作するのでは?
Re:IPAは、パスワードの文字数制限を緩和するよう啓蒙すべき (スコア:1)
Re:IPAは、パスワードの文字数制限を緩和するよう啓蒙すべき (スコア:1)
クライアント証明書に…いやなんでもない
Re: (スコア:0)
SSL v2に…いやなんでもない
Re: (スコア:0)
> パスワードの最大文字数を増やそうって主張には同意なのですが、/.JにはまずSSL対応して欲しいです。
なんのために?って思ったけど、ログインするときセキュアじゃないのですね。
なんで、セキュアじゃないのにログインしようとするのかわからない。
セキュアじゃないのにログインしておいて SSL対応して欲しいとかおかしいです。
Re:IPAは、パスワードの文字数制限を緩和するよう啓蒙すべき (スコア:1)
…とかですかね。
気分的には「httpな掲示板で再編集用のパスワードを設定」しているような感じです。
全然セキュアでないけどまあ使うかみたいな。
どのみちSSL対応してもらった方が
とかメリットのが確実に多いので気長にSSL対応を待っているのです。
Re:逆に危険 (スコア:1)
かつてのみずほ銀行は強制的に6文字でぶった切ってくれましたがなにか?
Re:逆に危険 (スコア:1)
かつての大○証券はパスワード=暗証番号と同じ数字4桁でした。
メールでやんわりと良くないと教えたのですが、逆ギレされたので解約した思ひ出。
つーか今見てみたら、今だにパスワード4桁からじゃんwwww
Re:逆に危険 (スコア:1)
倉吉の大山証券なら、もう20年近く前に合併で名前が変わってますよ。
Re:逆に危険 (スコア:1)
SSLの暗号スイートでも輸出強度暗号を有効にしててもろにFREAKに脆弱だったし。ひろみちゅ逆張リストがなんか言ってたけどやっぱりアホなコンサルか何かのたわ言をまに受けただけでしょ。
# 日本では少ないようだがBEASTのときにRC4以外を無効にして以来知識を更新できていない銀行やら航空会社やらはマジ絶滅しろ
Re:逆に危険 (スコア:1)
>パスワードは複雑度よりもむしろ長さの方が重要だと、一体何時になったら周知徹底されるのか。
パスワードの「重要」というのはよくわからないけど、安全面から考えると。
・使い回ししない
・適宜変更する
・多段階認証
とかは奨励されないんすかね。
銀行ATMやdocomoのいろんなパスワードとかが未だに数字4桁で、容易に変更できないかユーザにそのやりかたを周知できていないみたいだ
ってのがずっと怖いなぁとは思ってる。
Re: (スコア:0)
大筋に同意するけど現在のトレンドは多要素認証だろ
Re: (スコア:0)
文字数による安全性もそのうち幻想になるとおもうけどね
もうプルートなんて時代じゃないし
Re: (スコア:0)
もうプルートなんて時代じゃないし
プ(pu)ルート、って、ブ(bu)ルートフォースアタックのブルート?
だとしたら、プとブの違いは無視するとしても、その略し方は初めて聞きました。
まぁ、それは置いておいて、
確かに、最近よく聞くのは、他のシステムから流出したパスワードを使って
って方法が多いから、パスワードの強度自体ももちろん(だし、他コメでも上がってるん)だけど
使いまわししない、ってのが重要になってるよねぇ。
Re: (スコア:0, オフトピック)
ハッシュ関数にMD5を使っているならどれだけパスワードを長くしてもランダムな英数字約20文字、SHA1なら約25文字、SHA256なら約40文字より安全には絶対にならない。覚えやすくなるだけ(でも十分だしいずれにしても12文字は少なすぎるが)。パスワードに不可逆なハッシュ化をしていないとか暗号学的な検討のなされていないオレオレハッシュを使うのは別の意味で論外だし。
辞書に載っている単語だけを組み合わせるならMD5で約11語、SHA1で約13語、SHA256で約21語の組み合わせ程度でいいけど、これは完全にランダムに単語を選んだ場合なのでパスフレーズジェネレーターでも使わない限りもう少し長くとったほうがよさそう。
パスワードハッシュ専用の API を用いるべき (スコア:5, 興味深い)
まず、MD5 や SHA-1 は、そもそも暗号学的ハッシュ関数としての脆弱性が発見されているから、パスワードのハッシュ化に使うべきかどうかとの議論以前に、今では如何なる用途においても優位性がありません。転送中にファイルが破損(改ざんではなく通信中のノイズなどによる偶然の破損)したか調べる為には使えますが、だったら CRC32 などの方がより高速です。
そして、暗号学的ハッシュ関数として安全とされている SHA-2 (SHA-256 など) であっても、暗号学的高速ハッシュ関数はパスワードのハッシュ化に用いるべきではありません。これらは、高速にハッシュ値を求めるための関数であって、パスワードの保存に用いる為に開発されたものではないからです。詳しいことは、安全なパスワードハッシュ [php.net] が分かりやすいです。
もし、専門的知識があるなら、適切なソルトを付けたり、暗号学的高速ハッシュ関数を適切な回数通したり、各ユーザのハッシュをユニークにしたりするなど、自分で安全になるようなコードを書くことができるという考えもあるかもしれません。しかし、独自の暗号アルゴリズムを開発して厳重な秘密管理をするよりも公開されている安全とされるアルゴリズムを使うべきであるのと同様に、HMAC [wikipedia.org]、PBKDF2 [wikipedia.org]、Bcrypt [openwall.com] といったパスワードのハッシュ化に適しているスキームとして十分な検証がなされているものを用いるべきだと思います。
更に良いのは、password_hash [php.net] といったパスワードハッシュ専用の API を用いることです。パスワードのハッシュ化に適しているスキームとして十分な検証がなされているハッシュ関数(現在は bcrypt)が用いられますし、サーバーをベンチマークして適切な強度のストレッチングを行うことが簡単にできます。サーバのスペックが上がったらコード変更無しにストレッチング強度を自動的に高めるとか、負荷が少ない時間帯はストレッチングの強度をあげるといったことも簡単にできます。また、将来的により強力なアルゴリズムが現れれば php のアップデートで自動的にパスワードハッシュアルゴリズムが切り替わる仕様になっているので、古いプログラムコードが使われ続けていたとしても、安全性を維持することができます(データ長が将来的に増えることも想定されており、パスワードハッシュを格納するデータベースのデータ長に余裕を持たせることが推奨されています)。
Re: (スコア:0)
ソルト導入すべしってのは当然だけど、ストレッチングは微妙だなぁ…
攻撃側はGPGPUやFPGAで演算コストを抑えてるのに対して、防衛側は汎用CPUでそこそこの最適化しかしてない。
防衛側のほうが支払うコストが高い対策ってのは「急場凌ぎの対処法」であって「解決法」とはならない気がします。
使えるのは余剰の演算コストだけと考えると深いストレッチも出来ないので結構辛い。
トータルでは攻撃側の支払うコストの方が大きい (スコア:5, 興味深い)
確かに、1回のストレッチングにかかるコストという意味では、防御側より攻撃側の方が大幅に低いです。しかしながら、防御側はパスワードの認証・登録・変更が行われた時のみストレッチング処理を所定の回数行えば良いのに対して、攻撃側は総当たり攻撃のパターン数の分行わなければならないため、トータルでは攻撃側が支払うコストが上回っていると言えます。
具体的な例を挙げると、パスワードの認証(ログイン)・新規登録(アカウント追加)・パスワード変更の回数が1日1万回のシステムで、ストレッチングの回数が10万回の場合、防御側が行うストレッチング処理は10億回/日 です。それに対して、8桁のランダムな英数字のパスワードを破ろうとした場合、攻撃側は全通り試すならば 218,340,105,584,896 通り試す必要があるので、ストレッチング処理を 100,000 × 218,340,105,584,896 =21,834,010,558,489,600,000 (回) する必要があります。つまり、この場合(8桁のランダムな英数字のパスワードを全通り試す場合)、攻撃側は防御側の 21,834,010,558倍 (約200億倍) の処理コストがかかると言えます。
ちなみに、以前試算しましたが [srad.jp]、日本の理化学研究所のスパコン「京」のCPUで、まともなアルゴリズムでハッシュ化(HMACハッシュ関数によるストレッチングを含む)されているパスワードの解析を行う場合、1秒間に1万回しか試行できないという結果になりました。この場合、GPU演算は考慮していませんでしたが、攻撃側がNSAなどの巨大組織でない限り、GPGPUやFPGAを使ったとしてもスパコン「京」のCPU演算を超えるだけの能力をはじき出すのはなかなか難しいのではないでしょうか。
1秒間に1万回の試行であれば、ランダムな英数字8桁のパスワードの場合、平均で400年ぐらいの解読時間がかかることになります。従って、ユーザーが8桁のランダムな英数字、もしくはそれを超える安全性のパスワード(ランダムな英単語4個 : copy-item-tokyo-heavy など)を使ってくれるという前提においては、ストレッチングは「急場凌ぎの対処法」ではなく「解決法」と言えると思います。
Re:逆に危険 (スコア:1)
オフトピ。
MD5, SHA1って。。。。
すでに2007年の時点で ありがとうそしてさようなら [google.com]
という認識でいたのですが、今でも大事にされているんですか?
そうわりきるしかないという現状を憂えているということですね、きっと。
それにしてはSHA-2(SHA-256)への移行がまだゆるゆる進んでいないみたいだし、
そもそも今の若い人(a.k.a. 労害労害いう人)が引退するころにはそれも破られているだろうし。。。
Re: (スコア:0)
探索時間で考えるならハッシュ空間全部使いきらなくても良い気がするとか考えるのはヘタレでしょうか?
Re: (スコア:0)
>アルファベットの大文字と小文字、更に数字と記号を含めた8文字以上のパスワードなら安全、という古からの安全神話。
ごめん、それ初めて見た
もしかして利用可能文字と推奨パスワード例のことじゃないよね
Re: (スコア:0)
ANAなんて、つい最近まで数字4文字でしたが。
三井住友VISAの8文字制限も酷い。
あと、多段階の認証にしたり(新生銀行とか)、用途毎に複数のパスワードを設定させるとか(住信SBIネット銀行とか)もやめてくれ。
やめなくてもいいけど、20文字以上のパスワードを設定すれば、一段階認証でもいい、とかにしてください。
Re: (スコア:0)
3回連続で間違ったら30秒待たせるとかやればいいんじゃね?
Re: (スコア:0)
それリバースブルートフォースアタックに無力なんで、間違える・間違えないに関わらずパスワード入力後、必ず3秒待たせる、とかの方がいい。