回答編集履歴
1
コメントへの回答を追記しました
test
CHANGED
|
@@ -35,3 +35,57 @@
|
|
|
35
35
|
従来、IDとパスワードのどちらが間違いかわからない方法が主流だった理由は、その方がパスワード試行が難しくなるからです。しかし、この方法だけが「パスワード試行を難しく対策」ではありません。このため、別の方法でパスワード試行攻撃を対策すれば、「IDとパスワードのどちらが間違いかが分かる」方法を採用することはありえます。
|
|
36
36
|
|
|
37
37
|
ただし、上の引用にもあるように、むやみに真似して良い方法ではありません。
|
|
38
|
+
|
|
39
|
+
|
|
40
|
+
|
|
41
|
+
---
|
|
42
|
+
|
|
43
|
+
|
|
44
|
+
|
|
45
|
+
以下のコメントについて追記として回答します。
|
|
46
|
+
|
|
47
|
+
|
|
48
|
+
|
|
49
|
+
> ということは、僕の考えた仕様であったとしても、「別の方法でパスワード試行攻撃を対策」すれば、脆弱性の問題は回避できるということでしょうか？
|
|
50
|
+
|
|
51
|
+
|
|
52
|
+
|
|
53
|
+
まず、「IDの登録有無がわかってしまう」という問題は、認証システムにおいて脆弱性ではありません。では、従来なぜIDの登録有無が分からないようにしていたかですが、これは難しい言い方をすると「弱いパスワードが登録されている場合のコントロール」としてです。
|
|
54
|
+
|
|
55
|
+
パスワード認証において、もっとも重要なことは、利用者が安全なパスワードをつけることです。しかし、それだと利用者まかせになってしまう（パスワードの本来のあり方はそういうものですが）ので、サイト運営者側でなんとかできないか、ということで、以下のようなコントロールが考案され、実践されています。
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
- パスワードの定期的変更を要求する
|
|
60
|
+
|
|
61
|
+
- パスワードに使う文字種を2種以上、あるいは3種以上を要求する
|
|
62
|
+
|
|
63
|
+
- ログインの際にIDの間違いかパスワードの間違いかを明示しない
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
上の２つは、最近、逆効果として否定されています。3番目が今回のテーマですが、メリットもあるがデメリットもあるということで疑問視されているわけです。
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
たとえば、WordPressという世界でもっとも多用されているCMSの仕様も、「IDの間違いかパスワードの間違いか分かる」仕様になっています。これが脆弱性であるならばとっくに「改善」されているはずですが、一応許容されています（プラグインで挙動を変更することもできますが）。
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
コントロールの意味を説明していませんでしたが、意訳すると「対策」ですね。弱いパスワードをつけてしまう問題は、本当に悪いのは利用者です。ですが、サイト側でできる対策の一つしてこれがあります。
|
|
76
|
+
|
|
77
|
+
でも、例えば、認証の際に二段階認証を要求すれば、こちらの方がはるかに安全性が高まるので、他の対策（コントロール）までは要らないだろう、という判断はできます。
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
|
|
81
|
+
長々と書きましたが、まとめるとこうです。
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
- メールアドレスが登録済みとわからないようにすることは、弱いパスワードをつけてしまう利用者に対するコントロール（対策）である
|
|
86
|
+
|
|
87
|
+
- コントロールの一つが「ないこと」は脆弱性ではない
|
|
88
|
+
|
|
89
|
+
- 認証システムの利用者が限定され、全員が強いパスワードをつけることがわかっていれば、このコントロールはなくてもよい
|
|
90
|
+
|
|
91
|
+
- 他のコントロールで、もっと有効なものを使う場合（例: 二段階認証）も、このコントロールはなくてもよい
|