アカウント名:
パスワード:
8文字以上のパスワードしか受け付けないようにしたり、記号を必須にしたりすれば、現実問題としてパスワードの使い回しがより頻繁に行われるようになるだけ。IDがメールアドレスならば、リスト型アカウントハッキングが余計に増えます。
もっと現実的な対策として、私は、次のようなポリシーを提案します。
ランダム（暗号論的擬似乱数生成器もしくは現実的にはそれと類する推測不可能性を持つと思われるものに限る。某ネットバンクやJAL・ANAのような連番の数字は論外）な英数字のID（最低8文字）を管理側が一方的に割り当てる。 そして、ユーザーによる任意の文字列への変更は認めない。ただし、漏えいの可能性があるときにユーザーが変更できるように、新しいランダムの文字列への変更（再発行）はできるようにする。 そして、ユーザーには、IDを紛失しないように、手帳・パソコン内のテキストファイル・モニターのポストイットなど、複数の場所に書き留めておくことを推奨する。 IDは、"1", "I", "2", "Z" など紛らわしい文字は一切使わないようにすることが望ましいです。「"1" は使うけど "I" は使ってません、"I" に見えたら "1" を入力して下さい」とかいう管理者も居ますが、ナンセンスです。ユーザーにとってはそんなローカルルールをサイト毎に覚えてられませんから、紛らわしい文字は両方とも排除して、強度が下がるなら文字数を増やした方がましです。
4文字以上（数字4桁も認める）で、第三者に推測されないもの。ショルダーハック対策として、"1111"や"0101"～"1231"の月日パターンなどは利用不可とする。そして、ユーザーには絶対に書き留めず覚えることを要求する。 そして、入力元のIPアドレスなどに関係なく、連続して4回以上入力したら、ロックする。 ただし、きちんとしたパスワードを設定したいユーザーのためにアルファベット・数字・記号（ASCII印字可能文字は全て）を使えるようにする、文字数の上限を引き上げるといった対策はすべきです。
ポイントの利用や、金銭が絡む取引などでは、これに加えてワンタイムパスワードを入力させる。金額の低いものは、電子メールでの都度送付で構わない。銀行振込などの大きな金額が動くものに関しては、ハードウェアトークンによるトランザクション署名 [ftsafe.co.jp]を必須とする。トランザクション署名は、シンガポール・香港などの銀行では一般的にに使われていますが、日本では、三井住友銀行やゆうちょ銀行が対応トークンを配布したものの、まだサーバ側での対応例は無いようです。
-
JAL や ANA が数字のみ4桁～6桁のパスワード（というより暗証番号）で不正アクセスが多発したのは、IDの強度が不足していた（数字のみ・連番など推測可能）からです。
IDが推測不可能であれば、リバースブルートフォースアタックも成立しません。
ユーザーを信頼せず、IDを強制的に強度の高いランダムなものにしてしまい、パスワードはショルダーハック（IDをメモした手帳やポストイットを見ることができる人による不正アクセス）を防ぐためのものでサービス間での使い回しはやむを得ない（現実的に防げない）ものと考えれば良いのです。
パスワードが使いまわされ、他のサイトから漏えいしたとしても、IDが推測不可能であれば、今流行のリスト型アカウントハッキングも成立しません。
また、この4回連続でパスワードを間違えたらロックすることで、ショルダーハックを防ぐことができます。IDを書き留めた手帳やポストイット・PC内のテキストファイルを見れる立場の人が居たとしても、せいぜいアカウントをロックさせて一時的に利用不可能とする嫌がらせがせいぜいです。（そもそも、それができる立場なら、物理的にパソコンを壊す、手帳を破り捨てるといった方法もとれるので、現実的にそこまでは心配ないでしょう。身内や同僚の嫌がらせによってアカウントをロックさせられるのが心配な特殊な方は、IDを暗号化してパソコンに保存すれば良いでしょう。）
このように、ユーザーが設定するパスワードを信頼せずに、任意の文字列への変更不可能で推測不可能で強度を持つIDを強制的に割り当てれば、殆どのオンライン攻撃を防ぐことができると思われます。
推測可能なIDあれば探索範囲を狭くできますが、推測不可能なIDでも文字通り「ブルートフォース」でアタックすることはできますよね? どうしてリバースブルートフォースアタックは成立しないのでしょうか?
さらにパスワードが4文字なら、それこそリバースブルートフォースアタックの恰好の餌食なんでは?
アタックをしかけること自体は当然可能ですが、それにより不正アクセスを成立させることのできる確率は極めて低く現実的ではないので、「リバースブルートフォースアタックも成立しません」と書きました。
推測不可能なIDというのは、例えば、次のようなものです。これは、ランダムな文字種50文字（英数記号から視認した際に紛らわしい文字を排除）の10桁です。
ユーザーID: K9eJP@N4Ae
5010 = 97,656,250,000,000,000 通りあります。
Web経由で、毎秒何千回もログインを試みるのは現実的ではありませんので（普通のWebサーバは、同一IPアドレスからの大量のWebアクセスは、DoSと判断してブロックする設定にしてあります。BOTを使って多数のIPアドレスを使い分けたとしても限度があります）、仮に、ユーザーIDだけで認証していたとしても（パスワード無し）、破ることができる確率は天文学的に低くなります。
更に、最低4桁だとしてもパスワードもあれば、リバースブルートフォースアタックが成功する確率は更に低くなり、現実的には不可能と言えます。
「ブルートフォースアタック」については、そもそもユーザーIDを知っていることが前提となりますので（IDを固定してパスワードを変える攻撃のため）、書き留めておいたユーザーIDを見ることのできる立場の人しかできませんし、 #2659341 に書いたように、4回間違えたらロックする仕様ですから、仮に家族や同僚などのIDを知ることができる人が、ブルートフォースアタックをしたとしても、ほぼ失敗します。（もし、物理的にPCに接触できる立場ならば、キーロガーを仕掛けた方が効率的です）
英数字8文字なら比較的現実的な時間でブルートフォースできてしまいますけどねえ。
英数字8文字(62種類)から、紛らわしい文字を排除して50種類としても、8文字なら、39,062,500,000,000 通りもあります。
ローカルでパスワードのハッシュ値（digest value）から元のパスワードを割り出すような攻撃であれば、現実的な時間でできてしまいますが、インターネット経由であれば困難です。
毎秒100回のアクセスを続けたとしても、全通り試すには、約12387年間かかることになります。
同一のIPアドレスから連続してログインを試みるような攻撃を続けていてはブロックされますから、IPアドレス（BOTなどの踏み台）も多数必要となります。
おまえの言っているIDな、それみんながパスワードと呼んでるやつだから
> IDは、"1", "I", "2", "Z" など紛らわしい文字は一切使わないようにすることが望ましいです。
目で見て紛らわしい組み合わせだけでなくて、"9"と"q""Q"も排除していただきたいです。先日、Windows8.1のProduct keyを入力する時に、子供に読み上げさせてタイプしたら、"9"と"q"を間違えて、キーが正しくないってメッセージが出ました。
老眼が入ってきて、あの小さな文字列を見るのは辛かったのですよ。
私は逆に、パスワードを作る時にはわざとこういう紛らわしい文字列を入れ換えて作ったりしてますけどね。
1(イチ)、I(アイ)
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
弘法筆を選ばず、アレゲはキーボードを選ぶ -- アレゲ研究家
ランダムなID（変更不可）を割り当てれば解決。パスワードは数字4桁で十分。 (スコア:1)
8文字以上のパスワードしか受け付けないようにしたり、記号を必須にしたりすれば、現実問題としてパスワードの使い回しがより頻繁に行われるようになるだけ。IDがメールアドレスならば、リスト型アカウントハッキングが余計に増えます。
もっと現実的な対策として、私は、次のようなポリシーを提案します。
ランダム（暗号論的擬似乱数生成器もしくは現実的にはそれと類する推測不可能性を持つと思われるものに限る。某ネットバンクやJAL・ANAのような連番の数字は論外）な英数字のID（最低8文字）を管理側が一方的に割り当てる。
そして、ユーザーによる任意の文字列への変更は認めない。ただし、漏えいの可能性があるときにユーザーが変更できるように、新しいランダムの文字列への変更（再発行）はできるようにする。
そして、ユーザーには、IDを紛失しないように、手帳・パソコン内のテキストファイル・モニターのポストイットなど、複数の場所に書き留めておくことを推奨する。
IDは、"1", "I", "2", "Z" など紛らわしい文字は一切使わないようにすることが望ましいです。「"1" は使うけど "I" は使ってません、"I" に見えたら "1" を入力して下さい」とかいう管理者も居ますが、ナンセンスです。ユーザーにとってはそんなローカルルールをサイト毎に覚えてられませんから、紛らわしい文字は両方とも排除して、強度が下がるなら文字数を増やした方がましです。
4文字以上（数字4桁も認める）で、第三者に推測されないもの。ショルダーハック対策として、"1111"や"0101"～"1231"の月日パターンなどは利用不可とする。そして、ユーザーには絶対に書き留めず覚えることを要求する。
そして、入力元のIPアドレスなどに関係なく、連続して4回以上入力したら、ロックする。 ただし、きちんとしたパスワードを設定したいユーザーのためにアルファベット・数字・記号（ASCII印字可能文字は全て）を使えるようにする、文字数の上限を引き上げるといった対策はすべきです。
ポイントの利用や、金銭が絡む取引などでは、これに加えてワンタイムパスワードを入力させる。金額の低いものは、電子メールでの都度送付で構わない。銀行振込などの大きな金額が動くものに関しては、ハードウェアトークンによるトランザクション署名 [ftsafe.co.jp]を必須とする。トランザクション署名は、シンガポール・香港などの銀行では一般的にに使われていますが、日本では、三井住友銀行やゆうちょ銀行が対応トークンを配布したものの、まだサーバ側での対応例は無いようです。
-
JAL や ANA が数字のみ4桁～6桁のパスワード（というより暗証番号）で不正アクセスが多発したのは、IDの強度が不足していた（数字のみ・連番など推測可能）からです。
IDが推測不可能であれば、リバースブルートフォースアタックも成立しません。
ユーザーを信頼せず、IDを強制的に強度の高いランダムなものにしてしまい、パスワードはショルダーハック（IDをメモした手帳やポストイットを見ることができる人による不正アクセス）を防ぐためのものでサービス間での使い回しはやむを得ない（現実的に防げない）ものと考えれば良いのです。
パスワードが使いまわされ、他のサイトから漏えいしたとしても、IDが推測不可能であれば、今流行のリスト型アカウントハッキングも成立しません。
また、この4回連続でパスワードを間違えたらロックすることで、ショルダーハックを防ぐことができます。IDを書き留めた手帳やポストイット・PC内のテキストファイルを見れる立場の人が居たとしても、せいぜいアカウントをロックさせて一時的に利用不可能とする嫌がらせがせいぜいです。（そもそも、それができる立場なら、物理的にパソコンを壊す、手帳を破り捨てるといった方法もとれるので、現実的にそこまでは心配ないでしょう。身内や同僚の嫌がらせによってアカウントをロックさせられるのが心配な特殊な方は、IDを暗号化してパソコンに保存すれば良いでしょう。）
このように、ユーザーが設定するパスワードを信頼せずに、任意の文字列への変更不可能で推測不可能で強度を持つIDを強制的に割り当てれば、殆どのオンライン攻撃を防ぐことができると思われます。
ワンタイムパスワードは異なる運営会社のものを使って欲しい (スコア:2)
ベネッセやNTTデータの派遣社員のように、サーバ側のデータを根こそぎ持っていかれるとアウトです。
せめて異なる運営会社のOTPを使用して欲しいですね。
金融機関が相互乗り入れしてくれると、ユーザ側のキーホルダーのサイズも減って助かります。
Re: (スコア:0)
IDが推測不可能であれば、リバースブルートフォースアタックも成立しません。
推測可能なIDあれば探索範囲を狭くできますが、推測不可能なIDでも文字通り「ブルートフォース」でアタックすることはできますよね?
どうしてリバースブルートフォースアタックは成立しないのでしょうか?
さらにパスワードが4文字なら、それこそリバースブルートフォースアタックの恰好の餌食なんでは?
Re:ランダムなID（変更不可）を割り当てれば解決。パスワードは数字4桁で十分。 (スコア:1)
アタックをしかけること自体は当然可能ですが、それにより不正アクセスを成立させることのできる確率は極めて低く現実的ではないので、「リバースブルートフォースアタックも成立しません」と書きました。
推測不可能なIDというのは、例えば、次のようなものです。これは、ランダムな文字種50文字（英数記号から視認した際に紛らわしい文字を排除）の10桁です。
ユーザーID: K9eJP@N4Ae
5010 = 97,656,250,000,000,000 通りあります。
Web経由で、毎秒何千回もログインを試みるのは現実的ではありませんので（普通のWebサーバは、同一IPアドレスからの大量のWebアクセスは、DoSと判断してブロックする設定にしてあります。BOTを使って多数のIPアドレスを使い分けたとしても限度があります）、仮に、ユーザーIDだけで認証していたとしても（パスワード無し）、破ることができる確率は天文学的に低くなります。
更に、最低4桁だとしてもパスワードもあれば、リバースブルートフォースアタックが成功する確率は更に低くなり、現実的には不可能と言えます。
「ブルートフォースアタック」については、そもそもユーザーIDを知っていることが前提となりますので（IDを固定してパスワードを変える攻撃のため）、書き留めておいたユーザーIDを見ることのできる立場の人しかできませんし、 #2659341 に書いたように、4回間違えたらロックする仕様ですから、仮に家族や同僚などのIDを知ることができる人が、ブルートフォースアタックをしたとしても、ほぼ失敗します。（もし、物理的にPCに接触できる立場ならば、キーロガーを仕掛けた方が効率的です）
Re: (スコア:0)
（10桁・JALの2700万人の場合）
実際にはもっと高い使用率の暗証番号があるし、逆に毎秒4回でもこれだけ長期に昼夜関係なく回してたら気付かれる可能性もあると思うが。
金融みたいなクリティカルなもの以外で、大量流出は難しいと考えればそれなりに十分な強度かな？
まあ再発行とかでどんどんID食い潰す気もするが。
Re: (スコア:0)
英数字8文字なら比較的現実的な時間でブルートフォースできてしまいますけどねえ。
Re:ランダムなID（変更不可）を割り当てれば解決。パスワードは数字4桁で十分。 (スコア:1)
英数字8文字(62種類)から、紛らわしい文字を排除して50種類としても、8文字なら、39,062,500,000,000 通りもあります。
ローカルでパスワードのハッシュ値（digest value）から元のパスワードを割り出すような攻撃であれば、現実的な時間でできてしまいますが、インターネット経由であれば困難です。
毎秒100回のアクセスを続けたとしても、全通り試すには、約12387年間かかることになります。
同一のIPアドレスから連続してログインを試みるような攻撃を続けていてはブロックされますから、IPアドレス（BOTなどの踏み台）も多数必要となります。
Re: (スコア:0)
http://blog.tokumaru.org/2013/11/github.html [tokumaru.org]
あと全数じゃなくて「使える」アカウントを見つけ出すだけであれば数ヶ月単位で時間かければ結構引っかかるでしょう。
Re: (スコア:0)
おまえの言っているIDな、それみんながパスワードと呼んでるやつだから
Re: (スコア:0)
> IDは、"1", "I", "2", "Z" など紛らわしい文字は一切使わないようにすることが望ましいです。
目で見て紛らわしい組み合わせだけでなくて、"9"と"q""Q"も排除していただきたいです。
先日、Windows8.1のProduct keyを入力する時に、子供に読み上げさせてタイプしたら、"9"と"q"を間違えて、キーが正しくないってメッセージが出ました。
老眼が入ってきて、あの小さな文字列を見るのは辛かったのですよ。
私は逆に、パスワードを作る時にはわざとこういう紛らわしい文字列を入れ換えて作ったりしてますけどね。
1(イチ)、I(アイ)