teratail header banner
teratail header banner
質問するログイン新規登録

質問編集履歴

14

セキュリティタグを追加

2016/10/06 02:16

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
File without changes

13

認識まとめ文章を修正

2016/10/06 02:16

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -55,7 +55,7 @@
55
55
  - SSL/TLSを利用したhttpsプロトコルの利用は必須
56
56
  - SHA256は暗号化ではなく、ハッシュ生成のアルゴリズム(関数)である。
57
57
  - Saltはキーではない
58
- - Saltは漏洩しても問題にはならな
58
+ - 常識的にシステムを構築していればSaltは漏洩は気にしくて良
59
59
  - サーバサイドでのパスワードのハッシュ化は必須である
60
60
  - クライアントサイドで生成したパスワードハッシュをそのままDBに保存してはならない
61
61
  - パスワードのハッシュが漏洩した場合、元のパスワードを総当たりで突き止めることができる(オフラインの場合?)

12

1件認識したことを追加

2016/10/01 09:50

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -57,4 +57,5 @@
57
57
  - Saltはキーではない
58
58
  - Saltは漏洩しても問題にはならない
59
59
  - サーバサイドでのパスワードのハッシュ化は必須である
60
+ - クライアントサイドで生成したパスワードハッシュをそのままDBに保存してはならない
60
61
  - パスワードのハッシュが漏洩した場合、元のパスワードを総当たりで突き止めることができる(オフラインの場合?)

11

私の認識をまとめました。

2016/10/01 09:49

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -46,4 +46,15 @@
46
46
 
47
47
  この考え方は正しいですか?
48
48
 
49
- またクライアントサイドでSHA256によるパスワード暗号化を行った場合、ハッシュを生成するために必要なSaltキーが必要になりますが、Saltキー隠蔽することは可能ですか?不可能な場合、Saltキーが漏洩していることでどのような問題が起こりますか?
49
+ またクライアントサイドでSHA256によるパスワード暗号化を行った場合、ハッシュを生成するために必要なSaltキーが必要になりますが、Saltキー隠蔽することは可能ですか?不可能な場合、Saltキーが漏洩していることでどのような問題が起こりますか?
50
+
51
+ 追記(2016/10/01 18:06)
52
+ ---
53
+ ここまでの流れとして、質問者(私)が認識したことをまとめてみます。
54
+
55
+ - SSL/TLSを利用したhttpsプロトコルの利用は必須
56
+ - SHA256は暗号化ではなく、ハッシュ生成のアルゴリズム(関数)である。
57
+ - Saltはキーではない
58
+ - Saltは漏洩しても問題にはならない
59
+ - サーバサイドでのパスワードのハッシュ化は必須である
60
+ - パスワードのハッシュが漏洩した場合、元のパスワードを総当たりで突き止めることができる(オフラインの場合?)

10

タイトルを変更

2016/10/01 09:29

投稿

hojo
hojo

スコア195

title CHANGED
@@ -1,1 +1,1 @@
1
- 安全なパスワード保存を行う為暗号化どこで行うべきですか
1
+ SSLを利用したWebサービスでログインパスワードを安全に保存するには?
body CHANGED
@@ -1,3 +1,6 @@
1
+ 安全なパスワードの保存を行う為に暗号化はどこで行うべきですか?(旧タイトル)
2
+ ---
3
+
1
4
  Webサービスで安全なパスワードの保存を行いたいとします。
2
5
 
3
6
  パスワードをSHA256などによって暗号化することはよくある話だと思います。しかし、このSHA256を利用して暗号化する場合、暗号化はサーバサイドで行うべきか、クライアントサイドで行うべきか悩んでいます。
@@ -27,7 +30,7 @@
27
30
 
28
31
  何か考え方がおかしいのかもしれませんが、こんな私に何かアドバイスいただけたらと思います。
29
32
 
30
- 追記
33
+ 追記(2016/09/26 18:30)
31
34
  ---
32
35
  質問がダラダラとした文章になり、分かりにくいようですので質問を変えさせていただきます。
33
36
 

9

追記

2016/10/01 09:03

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -41,4 +41,6 @@
41
41
 
42
42
  そのため、クライアントサイドでSHA256によるパスワード暗号化を行った上でサーバサイドにパスワードを送る方法をとったほうがユーザにパスワードの安全性を保証することができるのではないですか?
43
43
 
44
- この考え方は正しいですか?
44
+ この考え方は正しいですか?
45
+
46
+ またクライアントサイドでSHA256によるパスワード暗号化を行った場合、ハッシュを生成するために必要なSaltキーが必要になりますが、Saltキー隠蔽することは可能ですか?不可能な場合、Saltキーが漏洩していることでどのような問題が起こりますか?

8

修正

2016/09/26 09:30

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -31,4 +31,14 @@
31
31
  ---
32
32
  質問がダラダラとした文章になり、分かりにくいようですので質問を変えさせていただきます。
33
33
 
34
- SSLによる暗号化通信を前提としたWebサービスで入力フォームなどによってユーザが入力するパスワード文字列をクライアントサイドで暗号化する場合、そのパスワードの安全性が保障されません。(なぜなら運営がパスワードを暗号化しているかわからないし、暗号化する前のパスワードをログとして残している可能性などを考えるとどこからパスワードが漏れるかわからないため)しかし、クライアントサイドでパスワードを暗号化した場合は、アプリケーションサーバにパスワードが届いた地点ですでに暗号化されているため、パスワードの文字列が漏洩する心配は無くなります。(漏れたとしてもハッシュだから元のパスワードが漏れるよりマシであると考えられる)そのため、クライアントサイドでSHA256によるパスワード暗号化を行った上でサーバサイドにパスワードを送る方法をとったほうがユーザにパスワードの安全性を保証することができるのではないですか?この考え方は正しいですか?
34
+ SSLによる暗号化通信を前提としたWebサービスで入力フォームなどによってユーザが入力するパスワード文字列をサーバサイドで暗号化する場合、そのパスワードの安全性が保障されません。
35
+
36
+ なぜなら運営がパスワードを安全な形で管理しているかわからないし、暗号化していたとしても暗号化する前のパスワードをアクセスログに残している可能性なども考えられるためどこからパスワード文字列が漏れるかわからないからです。
37
+
38
+ しかし、クライアントサイドでパスワードを暗号化した場合は、アプリケーションサーバにパスワードが届いた地点ですでに暗号化されているため、パスワードの文字列が漏洩する心配は無くなります。
39
+
40
+ 漏れたとしても暗号化後のハッシュ文字列だから元のパスワードが漏れるより安心できると考えられます。
41
+
42
+ そのため、クライアントサイドでSHA256によるパスワード暗号化を行った上でサーバサイドにパスワードを送る方法をとったほうがユーザにパスワードの安全性を保証することができるのではないですか?
43
+
44
+ この考え方は正しいですか?

7

質問変更の追記

2016/09/26 09:26

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -25,4 +25,10 @@
25
25
 
26
26
  どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。本当にこのSalt隠蔽問題は気にしなくても良いことなのでしょうか?
27
27
 
28
- 何か考え方がおかしいのかもしれませんが、こんな私に何かアドバイスいただけたらと思います。
28
+ 何か考え方がおかしいのかもしれませんが、こんな私に何かアドバイスいただけたらと思います。
29
+
30
+ 追記
31
+ ---
32
+ 質問がダラダラとした文章になり、分かりにくいようですので質問を変えさせていただきます。
33
+
34
+ SSLによる暗号化通信を前提としたWebサービスで入力フォームなどによってユーザが入力するパスワード文字列をクライアントサイドで暗号化する場合、そのパスワードの安全性が保障されません。(なぜなら運営がパスワードを暗号化しているかわからないし、暗号化する前のパスワードをログとして残している可能性などを考えるとどこからパスワードが漏れるかわからないため)しかし、クライアントサイドでパスワードを暗号化した場合は、アプリケーションサーバにパスワードが届いた地点ですでに暗号化されているため、パスワードの文字列が漏洩する心配は無くなります。(漏れたとしてもハッシュだから元のパスワードが漏れるよりマシであると考えられる)そのため、クライアントサイドでSHA256によるパスワード暗号化を行った上でサーバサイドにパスワードを送る方法をとったほうがユーザにパスワードの安全性を保証することができるのではないですか?この考え方は正しいですか?

6

誤字の修正

2016/09/26 09:24

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -10,7 +10,7 @@
10
10
 
11
11
  また、アプリケーションサーバがGETやPOSTに対するログを取るように設定されていた場合、送信されたパスワードは暗号化されることなくログファイルに記載されることになります。
12
12
 
13
- つまり、サーバサドでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろうと信用する形でサービスを利用することになります。
13
+ つまり、サーバサドでSHA256によるパスワード暗号化を行う仕様の場合、暗号化されないままアプリケーションサーバに届くパスワードを運営は安全に管理してくれるだろうと信用する形でサービスを利用することになります。
14
14
 
15
15
  これはなんかダメなんじゃないかなっていう気がするんです。
16
16
 

5

文章を修正

2016/09/26 08:32

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -14,12 +14,15 @@
14
14
 
15
15
  これはなんかダメなんじゃないかなっていう気がするんです。
16
16
 
17
- これを回避するためJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くなる気がします。
17
+ これを回避するためJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くなます。
18
18
 
19
- しかしその場合、SHA256で使用するSaltキーなどはどのように設定すれば良いのでしょうか?そのままjavascriptのソースファイルに記述してしまって良いのでしょうか?
19
+ しかしその場合、SHA256で使用するSaltキーなどはどのように設定すれば良いのでしょうか?そのままjavascriptのソースファイルに暗号化キーであるSaltキーを記述してしまって良いのでしょうか?
20
20
 
21
21
  なんとなくSaltキーの情報が漏れていることはあまり良くないことのような気がしています。しかし、SHA256は復号化が不可能な暗号化なので、一度暗号化されてしまったものを復号化することは不可能だと思います(そうですよね?)
22
22
 
23
- し何か嫌な感じがするので、どうにかSaltキーの情報を隠蔽したい思ってますが、クライアントサイドで暗号化を行う以上、隠蔽すことは不可能なのではないかと思っています。これは気になくても良いことなのでしょうか?
23
+ ら安全だ切れるのでしょうか?
24
+ 何か嫌な感じがします。
24
25
 
26
+ どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。本当にこのSalt隠蔽問題は気にしなくても良いことなのでしょうか?
27
+
25
28
  何か考え方がおかしいのかもしれませんが、こんな私に何かアドバイスいただけたらと思います。

4

一文を追加

2016/09/26 08:30

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -8,6 +8,8 @@
8
8
 
9
9
  我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ!とサービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
10
10
 
11
+ また、アプリケーションサーバがGETやPOSTに対するログを取るように設定されていた場合、送信されたパスワードは暗号化されることなくログファイルに記載されることになります。
12
+
11
13
  つまり、サーバサードでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろうと信用する形でサービスを利用することになります。
12
14
 
13
15
  これはなんかダメなんじゃないかなっていう気がするんです。

3

と が抜けていたので追加

2016/09/26 08:27

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -6,7 +6,7 @@
6
6
 
7
7
  その後、アプリケーションサーバの手によってデータベースにパスワードを保存する際にはSHA256によるパスワード暗号化を行った上で保存することになるわけですが、アプリケーションサーバにはパスワードがそのままの形で届いてしまっていることに変わりありません。
8
8
 
9
- 我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ!サービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
9
+ 我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ!サービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
10
10
 
11
11
  つまり、サーバサードでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろうと信用する形でサービスを利用することになります。
12
12
 

2

誤字を修正

2016/09/26 08:25

投稿

hojo
hojo

スコア195

title CHANGED
@@ -1,1 +1,1 @@
1
- 安全なパスワードの保存を行う為に暗号化はどこで行うべきですか?
1
+ 安全なパスワードの保存を行う為に暗号化はどこで行うべきですか?
body CHANGED
@@ -1,6 +1,6 @@
1
1
  Webサービスで安全なパスワードの保存を行いたいとします。
2
2
 
3
- パスワードをSHA256などによって暗号化することはよくある話だと思います。しかし、このSHA256を利用して暗号化する場合、暗号化はクライアントサイドで行うべきか、ローカルサイドで行うべきか悩んでいます。
3
+ パスワードをSHA256などによって暗号化することはよくある話だと思います。しかし、このSHA256を利用して暗号化する場合、暗号化はサーバサイドで行うべきか、クライアントサイドで行うべきか悩んでいます。
4
4
 
5
5
  サーバサイドで暗号化を行う場合、入力されたパスワードが暗号化されないままサーバに届くことになります。(SSLの話ではありません)
6
6
 

1

文章を修正

2016/09/26 08:24

投稿

hojo
hojo

スコア195

title CHANGED
File without changes
body CHANGED
@@ -6,18 +6,18 @@
6
6
 
7
7
  その後、アプリケーションサーバの手によってデータベースにパスワードを保存する際にはSHA256によるパスワード暗号化を行った上で保存することになるわけですが、アプリケーションサーバにはパスワードがそのままの形で届いてしまっていることに変わりありません。
8
8
 
9
- 我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ!主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
9
+ 我々が利用しているアプリケーションサーバはセキュリティ的に問題無いから大丈夫だ!サービス運営者が主張したところで、サーバの権限を奪われる可能性はゼロではありませんし、それ以前にアプリケーションサーバの運営者はパスワードが直接届くような環境でアプリケーションを日々保守していたりするわけです。
10
10
 
11
- つまり、サーバサードでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろう信用する形でサービスを利用することになります。
11
+ つまり、サーバサードでSHA256によるパスワード暗号化を行う仕様の場合、ユーザはサーバ運営者を信用し、暗号化されないままアプリケーションサーバに届くパスワードを守ってくれるだろう信用する形でサービスを利用することになります。
12
12
 
13
13
  これはなんかダメなんじゃないかなっていう気がするんです。
14
14
 
15
- しかし逆にJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くなる気がします。
15
+ これを回避するためJavascriptなどを利用してクライアントサイドでパスワードを暗号化してからアプリケーションサーバに暗号化されたパスワードを送る方法をとれば、このような心配事は無くなる気がします。
16
16
 
17
17
  しかしその場合、SHA256で使用するSaltキーなどはどのように設定すれば良いのでしょうか?そのままjavascriptのソースファイルに記述してしまって良いのでしょうか?
18
18
 
19
19
  なんとなくSaltキーの情報が漏れていることはあまり良くないことのような気がしています。しかし、SHA256は復号化が不可能な暗号化なので、一度暗号化されてしまったものを復号化することは不可能だと思います(そうですよね?)
20
20
 
21
- しかし何か嫌な感じがするので、どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。
21
+ しかし何か嫌な感じがするので、どうにかSaltキーの情報を隠蔽したいと思っていますが、クライアントサイドで暗号化を行う以上、隠蔽することは不可能なのではないかと思っています。これは気にしなくても良いことなのでしょうか?
22
22
 
23
23
  何か考え方がおかしいのかもしれませんが、こんな私に何かアドバイスいただけたらと思います。