質問編集履歴
7
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、ユーザーから見た時間的な差異はないと思います。
|
|
21
|
+
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、ユーザーから見た時間的な差異は大きくないと思います。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
@@ -34,7 +34,7 @@
|
|
|
34
34
|
|
|
35
35
|
1, パスワードを入力(変数passとする)
|
|
36
36
|
|
|
37
|
-
2, passをハッシュ化する × 1000(結果をpass_chとする)
|
|
37
|
+
2, passをハッシュ化する × 10,000回 (結果をpass_chとする)
|
|
38
38
|
|
|
39
39
|
3, pass_ch(とuserId)をSSL通信でサーバーに送る
|
|
40
40
|
|
|
@@ -74,7 +74,7 @@
|
|
|
74
74
|
|
|
75
75
|
|
|
76
76
|
|
|
77
|
-
よってストレッチングを、処理の集中するサーバーサイドで行わず、クライアントサイドで各々実行する事について、デメリット等あるのか質問させていただきます。
|
|
77
|
+
よってストレッチングを、処理の集中するサーバーサイドで行わず、クライアントサイドで各々実行する事について、デメリット等あるのか質問させていただきます。またその他自分の認識で間違いがありましたら、御手数ですが教えていただけると嬉しいです。
|
|
78
78
|
|
|
79
79
|
|
|
80
80
|
|
6
test
CHANGED
|
File without changes
|
test
CHANGED
|
File without changes
|
5
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -10,17 +10,19 @@
|
|
|
10
10
|
|
|
11
11
|
|
|
12
12
|
|
|
13
|
-
|
|
13
|
+
Webアプリケーションのセキュリティについて様々なページを読んでいて、ストレッチングというものがあったのですが、これの目的はハッシュ化されたパスワードが漏洩した場合、処理に時間をかけることでパスワードの総当り(または辞書)攻撃を防ぐものだと理解しました。
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
|
|
17
|
+
### 質問の主題
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
21
|
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、ユーザーから見た時間的な差異はないと思います。
|
|
22
22
|
|
|
23
23
|
|
|
24
|
+
|
|
25
|
+
###具体例
|
|
24
26
|
|
|
25
27
|
|
|
26
28
|
|
|
@@ -52,6 +54,8 @@
|
|
|
52
54
|
|
|
53
55
|
|
|
54
56
|
|
|
57
|
+
###思いつくデメリットと解決策
|
|
58
|
+
|
|
55
59
|
|
|
56
60
|
|
|
57
61
|
自分の思いつくデメリットは、
|
|
@@ -66,4 +70,12 @@
|
|
|
66
70
|
|
|
67
71
|
|
|
68
72
|
|
|
73
|
+
###まとめ
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
よってストレッチングを、処理の集中するサーバーサイドで行わず、クライアントサイドで各々実行する事について、デメリット等あるのか質問させていただきます。
|
|
78
|
+
|
|
79
|
+
|
|
80
|
+
|
|
69
81
|
長くなりましたが、有識者様の意見が聞きたく質問させて頂きました。拙い文章で申し訳ありません、よろしくお願いします。
|
4
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -18,7 +18,7 @@
|
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、
|
|
21
|
+
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、ユーザーから見た時間的な差異はないと思います。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
3
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -56,13 +56,13 @@
|
|
|
56
56
|
|
|
57
57
|
自分の思いつくデメリットは、
|
|
58
58
|
|
|
59
|
-
①パスワードが適切なものかの判別(文字数
|
|
59
|
+
①パスワードが適切なものかの判別(文字数が適切か，"aaaa","pass"等をはじく)が必ずしもできない
|
|
60
60
|
|
|
61
61
|
↑必然的にクライアントで判別することになるため、JavaScriptをいじられてしまったらパスワードが"aaaa"でも通ってしまう
|
|
62
62
|
|
|
63
63
|
|
|
64
64
|
|
|
65
|
-
なのですが、①に関してはわざわざJavaScriptをいじってまでパスワードを短くしたい人は少ないですし、saltを付与してハッシュしているのでレインボーテーブルも無効化できると考えています。
|
|
65
|
+
なのですが、①に関してはわざわざJavaScriptをいじってまでパスワードを短くしたい人は少ないですし、そうした場合でもsaltを付与してハッシュしているのでレインボーテーブルもある程度無効化できると考えています。
|
|
66
66
|
|
|
67
67
|
|
|
68
68
|
|
2
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -1,3 +1,7 @@
|
|
|
1
|
+
(初めてで使い方がわからず変な文章を投稿してしまいすみません。編集依頼くださった方々ありがとうございました。)
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
1
5
|
### 前提
|
|
2
6
|
|
|
3
7
|
|
1
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -1,45 +1,65 @@
|
|
|
1
|
-
### 前提
|
|
1
|
+
### 前提
|
|
2
|
+
|
|
3
|
+
|
|
4
|
+
|
|
5
|
+
Webアプリケーションのパスワード送信･保存時におけるパスワードの不可逆暗号化(ハッシュ化)のストレッチングについてです。その他SSL/TSL，salt付与等は行うものとします。
|
|
6
|
+
|
|
7
|
+
|
|
8
|
+
|
|
9
|
+
### 主題
|
|
10
|
+
|
|
11
|
+
|
|
12
|
+
|
|
13
|
+
Webアプリケーションのセキュリティについて様々なページを読んでいて、ストレッチングというものがあったのですが、これの目的はハッシュ化されたパスワードが漏洩した場合、処理に時間をかけることでパスワードの総当り(または辞書)攻撃を防ぐものだと理解しました。
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
ここで質問なのですが、「ストレッチングをする時サーバーの負荷と相談し回数を決定(多いほど良い)」と言われているようですが、これを負荷軽減のためにある程度クライアントで行い、これをパスワードとして認証するのはまずいのでしょうか。実装にもそこまでリスクはないですし、クライアントから見たら変わりはないと思います。
|
|
2
18
|
|
|
3
19
|
|
|
4
20
|
|
|
5
21
|
|
|
6
22
|
|
|
7
|
-
|
|
8
|
-
|
|
9
|
-
|
|
23
|
+
パスワード入力から保存までの具体的な処理としては、
|
|
10
24
|
|
|
11
25
|
|
|
12
26
|
|
|
13
|
-
|
|
27
|
+
クライアント側
|
|
14
28
|
|
|
15
|
-
|
|
29
|
+
1, パスワードを入力(変数passとする)
|
|
16
30
|
|
|
31
|
+
2, passをハッシュ化する × 1000(結果をpass_chとする)
|
|
32
|
+
|
|
17
|
-
|
|
33
|
+
3, pass_ch(とuserId)をSSL通信でサーバーに送る
|
|
18
34
|
|
|
19
35
|
|
|
20
36
|
|
|
37
|
+
サーバー側
|
|
38
|
+
|
|
21
|
-
|
|
39
|
+
4, salt値を決める
|
|
40
|
+
|
|
41
|
+
5, 送られてきたpass_chとsalt値を合わせてハッシュ化する(結果をpass_shとする)
|
|
42
|
+
|
|
43
|
+
6, pass_shとsalt(とuserId)をDBに保存する
|
|
22
44
|
|
|
23
45
|
|
|
24
46
|
|
|
25
|
-
|
|
47
|
+
が、自分の考えた処理です。具体例として提示しました。
|
|
26
|
-
|
|
27
|
-
ソースコード
|
|
28
|
-
|
|
29
|
-
```
|
|
30
48
|
|
|
31
49
|
|
|
32
50
|
|
|
51
|
+
|
|
52
|
+
|
|
33
|
-
|
|
53
|
+
自分の思いつくデメリットは、
|
|
54
|
+
|
|
55
|
+
①パスワードが適切なものかの判別(文字数や"aaaa","pass"等)が必ずしもできない
|
|
56
|
+
|
|
57
|
+
↑必然的にクライアントで判別することになるため、JavaScriptをいじられてしまったらパスワードが"aaaa"でも通ってしまう
|
|
34
58
|
|
|
35
59
|
|
|
36
60
|
|
|
37
|
-
|
|
61
|
+
なのですが、①に関してはわざわざJavaScriptをいじってまでパスワードを短くしたい人は少ないですし、saltを付与してハッシュしているのでレインボーテーブルも無効化できると考えています。
|
|
38
62
|
|
|
39
63
|
|
|
40
64
|
|
|
41
|
-
|
|
65
|
+
長くなりましたが、有識者様の意見が聞きたく質問させて頂きました。拙い文章で申し訳ありません、よろしくお願いします。
|
|
42
|
-
|
|
43
|
-
|
|
44
|
-
|
|
45
|
-
ここにより詳細な情報を記載してください。
|