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