質問編集履歴
14
セキュリティタグを追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
File without changes
|
13
認識まとめ文章を修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -112,7 +112,7 @@
|
|
|
112
112
|
|
|
113
113
|
- Saltはキーではない
|
|
114
114
|
|
|
115
|
-
- Saltは漏洩して
|
|
115
|
+
- 常識的にシステムを構築していればSaltは漏洩は気にしなくて良い
|
|
116
116
|
|
|
117
117
|
- サーバサイドでのパスワードのハッシュ化は必須である
|
|
118
118
|
|
12
1件認識したことを追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -116,4 +116,6 @@
|
|
|
116
116
|
|
|
117
117
|
- サーバサイドでのパスワードのハッシュ化は必須である
|
|
118
118
|
|
|
119
|
+
- クライアントサイドで生成したパスワードハッシュをそのままDBに保存してはならない
|
|
120
|
+
|
|
119
121
|
- パスワードのハッシュが漏洩した場合、元のパスワードを総当たりで突き止めることができる（オフラインの場合？）
|
11
私の認識をまとめました。
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -95,3 +95,25 @@
|
|
|
95
95
|
|
|
96
96
|
|
|
97
97
|
またクライアントサイドでSHA256によるパスワード暗号化を行った場合、ハッシュを生成するために必要なSaltキーが必要になりますが、Saltキー隠蔽することは可能ですか？不可能な場合、Saltキーが漏洩していることでどのような問題が起こりますか？
|
|
98
|
+
|
|
99
|
+
|
|
100
|
+
|
|
101
|
+
追記（2016/10/01 18:06）
|
|
102
|
+
|
|
103
|
+
---
|
|
104
|
+
|
|
105
|
+
ここまでの流れとして、質問者（私）が認識したことをまとめてみます。
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+
- SSL/TLSを利用したhttpsプロトコルの利用は必須
|
|
110
|
+
|
|
111
|
+
- SHA256は暗号化ではなく、ハッシュ生成のアルゴリズム（関数）である。
|
|
112
|
+
|
|
113
|
+
- Saltはキーではない
|
|
114
|
+
|
|
115
|
+
- Saltは漏洩しても問題にはならない
|
|
116
|
+
|
|
117
|
+
- サーバサイドでのパスワードのハッシュ化は必須である
|
|
118
|
+
|
|
119
|
+
- パスワードのハッシュが漏洩した場合、元のパスワードを総当たりで突き止めることができる（オフラインの場合？）
|
10
タイトルを変更
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
|
|
1
|
+
SSLを利用したWebサービスでログインパスワードを安全に保存するには？
|
test
CHANGED
|
@@ -1,3 +1,9 @@
|
|
|
1
|
+
安全なパスワードの保存を行う為に暗号化はどこで行うべきですか？（旧タイトル）
|
|
2
|
+
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
|
|
6
|
+
|
|
1
7
|
Webサービスで安全なパスワードの保存を行いたいとします。
|
|
2
8
|
|
|
3
9
|
|
|
@@ -56,7 +62,7 @@
|
|
|
56
62
|
|
|
57
63
|
|
|
58
64
|
|
|
59
|
-
追記
|
|
65
|
+
追記（2016/09/26 18:30）
|
|
60
66
|
|
|
61
67
|
---
|
|
62
68
|
|
9
追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -85,3 +85,7 @@
|
|
|
85
85
|
|
|
86
86
|
|
|
87
87
|
この考え方は正しいですか？
|
|
88
|
+
|
|
89
|
+
|
|
90
|
+
|
|
91
|
+
またクライアントサイドでSHA256によるパスワード暗号化を行った場合、ハッシュを生成するために必要なSaltキーが必要になりますが、Saltキー隠蔽することは可能ですか？不可能な場合、Saltキーが漏洩していることでどのような問題が起こりますか？
|
8
修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -64,4 +64,24 @@
|
|
|
64
64
|
|
|
65
65
|
|
|
66
66
|
|
|
67
|
-
SSLによる暗号化通信を前提としたWebサービスで入力フォームなどによってユーザが入力するパスワード文字列を
|
|
67
|
+
SSLによる暗号化通信を前提としたWebサービスで入力フォームなどによってユーザが入力するパスワード文字列をサーバサイドで暗号化する場合、そのパスワードの安全性が保障されません。
|
|
68
|
+
|
|
69
|
+
|
|
70
|
+
|
|
71
|
+
なぜなら運営がパスワードを安全な形で管理しているかわからないし、暗号化していたとしても暗号化する前のパスワードをアクセスログに残している可能性なども考えられるためどこからパスワード文字列が漏れるかわからないからです。
|
|
72
|
+
|
|
73
|
+
|
|
74
|
+
|
|
75
|
+
しかし、クライアントサイドでパスワードを暗号化した場合は、アプリケーションサーバにパスワードが届いた地点ですでに暗号化されているため、パスワードの文字列が漏洩する心配は無くなります。
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
漏れたとしても暗号化後のハッシュ文字列だから元のパスワードが漏れるより安心できると考えられます。
|
|
80
|
+
|
|
81
|
+
|
|
82
|
+
|
|
83
|
+
そのため、クライアントサイドでSHA256によるパスワード暗号化を行った上でサーバサイドにパスワードを送る方法をとったほうがユーザにパスワードの安全性を保証することができるのではないですか？
|
|
84
|
+
|
|
85
|
+
|
|
86
|
+
|
|
87
|
+
この考え方は正しいですか？
|
7
質問変更の追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -53,3 +53,15 @@
|
|
|
53
53
|
|
|
54
54
|
|
|
55
55
|
何か考え方がおかしいのかもしれませんが、こんな私に何かアドバイスいただけたらと思います。
|
|
56
|
+
|
|
57
|
+
|
|
58
|
+
|
|
59
|
+
追記
|
|
60
|
+
|
|
61
|
+
---
|
|
62
|
+
|
|
63
|
+
質問がダラダラとした文章になり、分かりにくいようですので質問を変えさせていただきます。
|
|
64
|
+
|
|
65
|
+
|
|
66
|
+
|
|
67
|
+
SSLによる暗号化通信を前提としたWebサービスで入力フォームなどによってユーザが入力するパスワード文字列をクライアントサイドで暗号化する場合、そのパスワードの安全性が保障されません。（なぜなら運営がパスワードを暗号化しているかわからないし、暗号化する前のパスワードをログとして残している可能性などを考えるとどこからパスワードが漏れるかわからないため）しかし、クライアントサイドでパスワードを暗号化した場合は、アプリケーションサーバにパスワードが届いた地点ですでに暗号化されているため、パスワードの文字列が漏洩する心配は無くなります。（漏れたとしてもハッシュだから元のパスワードが漏れるよりマシであると考えられる）そのため、クライアントサイドでSHA256によるパスワード暗号化を行った上でサーバサイドにパスワードを送る方法をとったほうがユーザにパスワードの安全性を保証することができるのではないですか？この考え方は正しいですか？
|
6
誤字の修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -22,7 +22,7 @@
|
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
25
|
-
つまり、サーバサ
|
|
25
|
+
つまり、サーバサイドでSHA256によるパスワード暗号化を行う仕様の場合、暗号化されないままアプリケーションサーバに届くパスワードを運営は安全に管理してくれるだろうと信用する形でサービスを利用することになります。
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
5
文章を修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -30,11 +30,11 @@
|
|
|
30
30
|
|
|
31
31
|
|
|
32
32
|
|
|
33
|
-
これを回避するためJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くな
|
|
33
|
+
これを回避するためJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くなります。
|
|
34
34
|
|
|
35
35
|
|
|
36
36
|
|
|
37
|
-
しかしその場合、SHA256で使用するSaltキーなどはどのように設定すれば良いのでしょうか？そのままjavascriptのソースファイルに記述してしまって良いのでしょうか？
|
|
37
|
+
しかしその場合、SHA256で使用するSaltキーなどはどのように設定すれば良いのでしょうか？そのままjavascriptのソースファイルに暗号化キーであるSaltキーを記述してしまって良いのでしょうか？
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
@@ -42,7 +42,13 @@
|
|
|
42
42
|
|
|
43
43
|
|
|
44
44
|
|
|
45
|
+
だから安全だと言い切れるのでしょうか？
|
|
46
|
+
|
|
47
|
+
何か嫌な感じがします。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
45
|
-
|
|
51
|
+
どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。本当にこのSalt隠蔽問題は気にしなくても良いことなのでしょうか？
|
|
46
52
|
|
|
47
53
|
|
|
48
54
|
|
4
一文を追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -15,6 +15,10 @@
|
|
|
15
15
|
|
|
16
16
|
|
|
17
17
|
我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ！とサービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
|
|
18
|
+
|
|
19
|
+
|
|
20
|
+
|
|
21
|
+
また、アプリケーションサーバがGETやPOSTに対するログを取るように設定されていた場合、送信されたパスワードは暗号化されることなくログファイルに記載されることになります。
|
|
18
22
|
|
|
19
23
|
|
|
20
24
|
|
3
と が抜けていたので追加
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ！サービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
|
|
17
|
+
我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ！とサービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
2
誤字を修正
test
CHANGED
|
@@ -1 +1 @@
|
|
|
1
|
-
安全なパスワードの保存を行う為に
|
|
1
|
+
安全なパスワードの保存を行う為に暗号化はどこで行うべきですか？
|
test
CHANGED
|
@@ -2,7 +2,7 @@
|
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
5
|
-
パスワードをSHA256などによって暗号化することはよくある話だと思います。しかし、このSHA256を利用して暗号化する場合、暗号化は
|
|
5
|
+
パスワードをSHA256などによって暗号化することはよくある話だと思います。しかし、このSHA256を利用して暗号化する場合、暗号化はサーバサイドで行うべきか、クライアントサイドで行うべきか悩んでいます。
|
|
6
6
|
|
|
7
7
|
|
|
8
8
|
|
1
文章を修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -14,11 +14,11 @@
|
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ！
|
|
17
|
+
我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ！サービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
|
-
つまり、サーバサードでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろう
|
|
21
|
+
つまり、サーバサードでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろうと信用する形でサービスを利用することになります。
|
|
22
22
|
|
|
23
23
|
|
|
24
24
|
|
|
@@ -26,7 +26,7 @@
|
|
|
26
26
|
|
|
27
27
|
|
|
28
28
|
|
|
29
|
-
|
|
29
|
+
これを回避するためJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くなる気がします。
|
|
30
30
|
|
|
31
31
|
|
|
32
32
|
|
|
@@ -38,7 +38,7 @@
|
|
|
38
38
|
|
|
39
39
|
|
|
40
40
|
|
|
41
|
-
しかし何か嫌な感じがするので、どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。
|
|
41
|
+
しかし何か嫌な感じがするので、どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。これは気にしなくても良いことなのでしょうか？
|
|
42
42
|
|
|
43
43
|
|
|
44
44
|
|