回答編集履歴
3
書式の改善
test
CHANGED
|
@@ -78,7 +78,7 @@
|
|
|
78
78
|
|
|
79
79
|
----
|
|
80
80
|
|
|
81
|
-
# 2016.10.01. 17時過ぎの追記
|
|
81
|
+
# ■ 2016.10.01. 17時過ぎの追記
|
|
82
82
|
|
|
83
83
|
|
|
84
84
|
|
|
@@ -266,7 +266,7 @@
|
|
|
266
266
|
|
|
267
267
|
----
|
|
268
268
|
|
|
269
|
-
# 2016.10.01. 21時過ぎの追記
|
|
269
|
+
# ■ 2016.10.01. 21時過ぎの追記
|
|
270
270
|
|
|
271
271
|
|
|
272
272
|
|
|
@@ -397,25 +397,3 @@
|
|
|
397
397
|
|
|
398
398
|
|
|
399
399
|
|
|
400
|
-
|
|
401
|
-
|
|
402
|
-
|
|
403
|
-
|
|
404
|
-
|
|
405
|
-
|
|
406
|
-
|
|
407
|
-
|
|
408
|
-
|
|
409
|
-
|
|
410
|
-
|
|
411
|
-
|
|
412
|
-
|
|
413
|
-
|
|
414
|
-
|
|
415
|
-
|
|
416
|
-
|
|
417
|
-
|
|
418
|
-
|
|
419
|
-
|
|
420
|
-
|
|
421
|
-
|
2
tuiki
test
CHANGED
|
@@ -261,3 +261,161 @@
|
|
|
261
261
|
SSL/TLSについては以前 [自分のブログ](http://wp.kaz.bz/tech/etc/ssl1) で数ページまとめたことがありますので、よろしければそちらをご覧ください。
|
|
262
262
|
|
|
263
263
|
|
|
264
|
+
|
|
265
|
+
|
|
266
|
+
|
|
267
|
+
----
|
|
268
|
+
|
|
269
|
+
# 2016.10.01. 21時過ぎの追記
|
|
270
|
+
|
|
271
|
+
|
|
272
|
+
|
|
273
|
+
raccy さんの回答のコメント欄からの派生です。
|
|
274
|
+
|
|
275
|
+
|
|
276
|
+
|
|
277
|
+
> > （kazさんが「1つの解になります」とおっしゃっている様ですがこれは保証されるという意味で受け取っていいのでしょうか）
|
|
278
|
+
|
|
279
|
+
>
|
|
280
|
+
|
|
281
|
+
> どこの範囲での保証かにもよるんですが、基本的に「保証」とまではいえません。
|
|
282
|
+
|
|
283
|
+
> 「保証」とまで言えるようなレベルに持ち込むには、元のパスワード文字列を画面上で入力させないところまでやらなければ難しいでしょう。
|
|
284
|
+
|
|
285
|
+
|
|
286
|
+
|
|
287
|
+
この続きです。
|
|
288
|
+
|
|
289
|
+
|
|
290
|
+
|
|
291
|
+
SSL/TLSの経路保護等、別の疑問も生まれてきているようですが、一旦そちらまで考え始めると混乱しかしないと思いますので、「クライアントサイドでハッシュすること」にテーマを絞ります。
|
|
292
|
+
|
|
293
|
+
|
|
294
|
+
|
|
295
|
+
## 画面上でパスワード文字列を入力すること自体で発生するリスク
|
|
296
|
+
|
|
297
|
+
|
|
298
|
+
|
|
299
|
+
Webシステムを前提とした場合、XSSなどの攻撃手法を利用することにより認証のためのサーバへの通信を発生させる前に画面上に入力された文字列を奪取し攻撃者のサイトにそのデータを送り込むことが可能です。
|
|
300
|
+
|
|
301
|
+
|
|
302
|
+
|
|
303
|
+
また、クライアントサイドのPCのセキュリティ状態まで考慮に入れれば、どのような画面設計、通信仕様にしたところで、なんらかの箇所で入力が発生しさえすれば、元の文字列の奪取は可能でしょう。
|
|
304
|
+
|
|
305
|
+
※キーロガー、とかを調べるとわかるかと思います。
|
|
306
|
+
|
|
307
|
+
|
|
308
|
+
|
|
309
|
+
|
|
310
|
+
|
|
311
|
+
というように、保護対象をある程度限定しないとこの議論はその箇所に影響する別の要素を持ち込むことでセキュリティの綻びが発生しうるため、その箇所だけで納得いく回答を得るのはなかなか困難かと思います。
|
|
312
|
+
|
|
313
|
+
|
|
314
|
+
|
|
315
|
+
立場をサービス提供サイドと特定し、ユーザーサイドのPC環境は安全と仮定したうえで、クライアントサイドでハッシュ処理を行うことは、元のパスワード文字列を受け取らないという意味で、保護している、と言えるとまでは言えると思います。
|
|
316
|
+
|
|
317
|
+
|
|
318
|
+
|
|
319
|
+
|
|
320
|
+
|
|
321
|
+
## サービスの認証情報の保護という観点ではリスクが増すともいえるかも
|
|
322
|
+
|
|
323
|
+
|
|
324
|
+
|
|
325
|
+
ここまでは「パスワード文字列の保護」についてでしたが、ここからは「サービスの認証情報の保護」の観点で考えます。
|
|
326
|
+
|
|
327
|
+
|
|
328
|
+
|
|
329
|
+
仮にこのサービスで利用されているパスワードが他サービスで使いまわされているパスワードで、その他サービスで漏洩した場合、そのパスワードを利用してこのサービスのパスワード入力画面に打ち込めばなりすましログインが可能になることを考えると、なりすましに利用できる文字列の可能性が
|
|
330
|
+
|
|
331
|
+
|
|
332
|
+
|
|
333
|
+
- ハッシュ：漏洩の危険度は低い
|
|
334
|
+
|
|
335
|
+
- パスワード：漏洩の危険度は（他サービスも含めることで）高い
|
|
336
|
+
|
|
337
|
+
|
|
338
|
+
|
|
339
|
+
という2種類となることで、トータルでの危険度は増している（ハッシュの漏洩によりなりすませる分）、とも考えられます。
|
|
340
|
+
|
|
341
|
+
|
|
342
|
+
|
|
343
|
+
- 元のパスワードをハッシュするロジックは公開されている（クライアントサイドでやるということはそういうことになります）
|
|
344
|
+
|
|
345
|
+
- サーバに送り込むべき文字列はハッシュ
|
|
346
|
+
|
|
347
|
+
|
|
348
|
+
|
|
349
|
+
ということは、元のパスワード、ハッシュのいずれかがわかればいい、ということになることはご理解いただけますか。
|
|
350
|
+
|
|
351
|
+
|
|
352
|
+
|
|
353
|
+
|
|
354
|
+
|
|
355
|
+
## その他、全体的な整理
|
|
356
|
+
|
|
357
|
+
|
|
358
|
+
|
|
359
|
+
> パスワードをクライアントサイドでハッシュし、サーバサイドにはそのハッシュを送るとした場合、サーバサイドでは「ハッシュ」こそがそのユーザーの「認証情報」として扱われる。
|
|
360
|
+
|
|
361
|
+
|
|
362
|
+
|
|
363
|
+
- つまりこれは、「通常のパスワードよりも長くランダムな文字列をパスワードとして設定した」ことと同義となる。
|
|
364
|
+
|
|
365
|
+
- 同じ前提で、通信経路という観点でみれば、通信経路を流れるハッシュがわかれば認証できる、ということになる。
|
|
366
|
+
|
|
367
|
+
|
|
368
|
+
|
|
369
|
+
### これで「よし」の場合
|
|
370
|
+
|
|
371
|
+
|
|
372
|
+
|
|
373
|
+
- サーバサイドでのそのハッシュ方法などとは関係なく、「通信経路上を元のパスワード文字列を流さないこと」が課題だったことになる。
|
|
374
|
+
|
|
375
|
+
- それであれば、パスワードマネージャなどを利用し、使いまわしたりせずにサイトごとに長いランダムなパスワードを生成したものをパスワードとして設定するのと同義。
|
|
376
|
+
|
|
377
|
+
- ただしこの場合は「ユーザーサイドのパスワード管理の問題」となるため、サービス提供サイドの技術要件としてフォローする箇所は少ない。
|
|
378
|
+
|
|
379
|
+
※なくはない。パスワード要件として充分に長い文字列を設定可能とする、など。
|
|
380
|
+
|
|
381
|
+
|
|
382
|
+
|
|
383
|
+
### そうではなく「認証情報の保護」が課題だった場合
|
|
384
|
+
|
|
385
|
+
|
|
386
|
+
|
|
387
|
+
- クライアントサイドでハッシュすることによって見込める認証情報の保護レベルの向上はほぼない。
|
|
388
|
+
|
|
389
|
+
- サーバサイドでDB等に認証情報を格納する際、受け取ったハッシュをさらにハッシュして保存するなどすることでより安全に保存することはできますが、これは「平文のパスワードをハッシュして保存するとより安全」というのと同義。
|
|
390
|
+
|
|
391
|
+
- 元のパスワード文字列の漏洩を気にするのであれば、使いまわさないなど別のレイヤーでの対応が必要。
|
|
392
|
+
|
|
393
|
+
|
|
394
|
+
|
|
395
|
+
→ おそらく、課題設定とその対策が一致していない。
|
|
396
|
+
|
|
397
|
+
|
|
398
|
+
|
|
399
|
+
|
|
400
|
+
|
|
401
|
+
|
|
402
|
+
|
|
403
|
+
|
|
404
|
+
|
|
405
|
+
|
|
406
|
+
|
|
407
|
+
|
|
408
|
+
|
|
409
|
+
|
|
410
|
+
|
|
411
|
+
|
|
412
|
+
|
|
413
|
+
|
|
414
|
+
|
|
415
|
+
|
|
416
|
+
|
|
417
|
+
|
|
418
|
+
|
|
419
|
+
|
|
420
|
+
|
|
421
|
+
|
1
追記
test
CHANGED
|
@@ -71,3 +71,193 @@
|
|
|
71
71
|
現状の質問をみると、漠然と不安がある、といった状況と大差なくみえます。
|
|
72
72
|
|
|
73
73
|
少し攻撃者側の手法を知ったうえで、それに対してどの部分のどういった安全をどう担保するか、といった視点で検討してみてはいかがでしょうか。
|
|
74
|
+
|
|
75
|
+
|
|
76
|
+
|
|
77
|
+
|
|
78
|
+
|
|
79
|
+
----
|
|
80
|
+
|
|
81
|
+
# 2016.10.01. 17時過ぎの追記
|
|
82
|
+
|
|
83
|
+
|
|
84
|
+
|
|
85
|
+
守る対象を
|
|
86
|
+
|
|
87
|
+
|
|
88
|
+
|
|
89
|
+
- パスワードとした元の文字列
|
|
90
|
+
|
|
91
|
+
- サービスの利用にあたっての本人確認に利用される情報
|
|
92
|
+
|
|
93
|
+
|
|
94
|
+
|
|
95
|
+
どちらと考えるかで、対処は変わってきますね。
|
|
96
|
+
|
|
97
|
+
|
|
98
|
+
|
|
99
|
+
## パスワードとした元の文字列の保護が課題の場合
|
|
100
|
+
|
|
101
|
+
|
|
102
|
+
|
|
103
|
+
質問者さんがおっしゃるように、通信経路上をそのまま流れることを避けることが優先事項となりますね。
|
|
104
|
+
|
|
105
|
+
クライアントサイドでハッシュ（もしくは何らかの対応付けされる文字列でいいわけですが）生成の上で、通信経路をそのハッシュ文字列を流す、というのは1つの解になります。
|
|
106
|
+
|
|
107
|
+
|
|
108
|
+
|
|
109
|
+
この観点でこの手法は、パスワードマネージャ等のソフトウェアを使って各アカウントのパスワードをランダム発行し管理するモデルとそう変わらない手法とも言えます。
|
|
110
|
+
|
|
111
|
+
パスワードマネージャの管理パスワードが「元のパスワード」と考えられます。
|
|
112
|
+
|
|
113
|
+
通信経路上を流れる文字列はそのサービスでしか利用していない、しかも何らかの計算ロジックに基づかないランダムな文字列なので、元のパスワード文字列は保護されます。
|
|
114
|
+
|
|
115
|
+
|
|
116
|
+
|
|
117
|
+
|
|
118
|
+
|
|
119
|
+
しかしこの場合、クライアントサイドでどう入力するかにかかわらず、通信経路上にその「ハッシュ文字列」を流せさえすればそのサービスのアカウントとしてはなりすましができることになります。
|
|
120
|
+
|
|
121
|
+
「本人確認に利用される情報」が「パスワード文字列」から「ハッシュ文字列」に置き換わっただけで、サービス側がその「ハッシュ文字列」を使える人はそのアカウントの利用者と解釈するわけです。
|
|
122
|
+
|
|
123
|
+
|
|
124
|
+
|
|
125
|
+
|
|
126
|
+
|
|
127
|
+
この手法によって安全性が向上する可能性を見込めるのは、
|
|
128
|
+
|
|
129
|
+
|
|
130
|
+
|
|
131
|
+
- 複数のサービスで同一のパスワードを使いまわしている状況
|
|
132
|
+
|
|
133
|
+
|
|
134
|
+
|
|
135
|
+
のみです。
|
|
136
|
+
|
|
137
|
+
つまり、課題が「パスワードに入力した文字列をどこでハッシュするか」ではなく「複数のサービスで同一のパスワードを使うことを避ける」ということに置き換わります。
|
|
138
|
+
|
|
139
|
+
|
|
140
|
+
|
|
141
|
+
|
|
142
|
+
|
|
143
|
+
|
|
144
|
+
|
|
145
|
+
## サービスの利用にあたっての本人確認に利用される情報の場合
|
|
146
|
+
|
|
147
|
+
|
|
148
|
+
|
|
149
|
+
本来サービス提供者が考えるべき保護の対象はこちらになってきます。
|
|
150
|
+
|
|
151
|
+
すると、まず第一に出てくる検討課題は「何をもって認証とするか」になります。
|
|
152
|
+
|
|
153
|
+
|
|
154
|
+
|
|
155
|
+
- パスワード認証
|
|
156
|
+
|
|
157
|
+
- 多元要素認証（ワンタイムパスワード的なものを含む）
|
|
158
|
+
|
|
159
|
+
- コールバック認証
|
|
160
|
+
|
|
161
|
+
- クライアント証明書による認証
|
|
162
|
+
|
|
163
|
+
|
|
164
|
+
|
|
165
|
+
など、様々な認証手法が候補になります。
|
|
166
|
+
|
|
167
|
+
|
|
168
|
+
|
|
169
|
+
これらの中でパスワード認証は、暗号化における共通鍵のように「サーバサイド、クライアントサイドで同一の認証情報を持ち、その一致をもって認証とする」手法です。
|
|
170
|
+
|
|
171
|
+
その時点で、その認証情報（つまりパスワード）とその伝送手段は、サーバサイド、クライアントサイドそれぞれで秘匿すべき情報になります。
|
|
172
|
+
|
|
173
|
+
言い方を変えると、サーバサイド、クライアントサイドそれぞれの認証情報の保護を疑うことを前提にした場合、パスワード認証では認証として充分と言えません。
|
|
174
|
+
|
|
175
|
+
|
|
176
|
+
|
|
177
|
+
そこを疑う場合は認証手法の変更を検討すべきです。
|
|
178
|
+
|
|
179
|
+
|
|
180
|
+
|
|
181
|
+
|
|
182
|
+
|
|
183
|
+
## その他、コメント内へのコメント
|
|
184
|
+
|
|
185
|
+
|
|
186
|
+
|
|
187
|
+
> ただ、少なくともクライアント側でパスワードをハッシュ化していれば「元のパスワード文字列がこのサービスから漏洩することはない」ということは保証できるのではないでしょうか？
|
|
188
|
+
|
|
189
|
+
|
|
190
|
+
|
|
191
|
+
これは上で説明したあたりですね。
|
|
192
|
+
|
|
193
|
+
|
|
194
|
+
|
|
195
|
+
|
|
196
|
+
|
|
197
|
+
> （もしかしたらハッシュから元の文字列を復元する方法などがあるのかもしれませんが、もしそのようなものをご存知でしたら是非教えていただきたいです！）
|
|
198
|
+
|
|
199
|
+
|
|
200
|
+
|
|
201
|
+
これは他の方もどこかで触れていましたが、要するに総当たりで解析することをいかに効率よくやるか、という課題で、レインボーテーブルなどの手法を利用することで効率よく元の文字列を見つけ出すといった手法が作られています。
|
|
202
|
+
|
|
203
|
+
|
|
204
|
+
|
|
205
|
+
また、攻撃者の視点に立つと「特定の人物に成りすましたい」という場合よりも「誰でもいいからのっとれるアカウントを探す」という場合が多いので、ハッシュから元のパスワードを導くよりも、既にわかっているパスワードとハッシュの組み合わせに一致する文字列を使っているユーザーを探し出す、ということになるでしょう。
|
|
206
|
+
|
|
207
|
+
もっともこの場合も、いちいちハッシュからの一致を見つけ出すよりも、特定のよくあるパスワードを入力して、アカウント側をリストに沿って入力していく、というリバースブルートフォースと呼ばれる手法をとる方が現在は主流でしょう。
|
|
208
|
+
|
|
209
|
+
参考） http://securityblog.jp/words/reverse_brute_force_attack.html
|
|
210
|
+
|
|
211
|
+
|
|
212
|
+
|
|
213
|
+
|
|
214
|
+
|
|
215
|
+
このあたり、他の方もおっしゃっていましたが徳丸さんという方が非常に多くの情報をWeb上に残しておられますので検索してみるといいかと思います。
|
|
216
|
+
|
|
217
|
+
また、 [体系的に学ぶ 安全なWebアプリケーションの作り方](https://www.amazon.co.jp/dp/B00E5TJ120/) という本を書かれていますので、こちらはこの件に関わらず必読かと思います。
|
|
218
|
+
|
|
219
|
+
|
|
220
|
+
|
|
221
|
+
|
|
222
|
+
|
|
223
|
+
|
|
224
|
+
|
|
225
|
+
## おまけ
|
|
226
|
+
|
|
227
|
+
|
|
228
|
+
|
|
229
|
+
なんとなく、SSL/TLSについて、どのような手法なのかを理解されていない部分があるのかなと感じます。
|
|
230
|
+
|
|
231
|
+
SSL/TLSで利用している通信経路の暗号化、という部分は、質問者さんがおっしゃっている通信経路上をテキストが流れる際の充分な保護になります。
|
|
232
|
+
|
|
233
|
+
つまり、適正なSSL/TLSサーバ証明書が利用されていれば、入力ポイントからサーバに到着するまでの通信内容は保護されます。
|
|
234
|
+
|
|
235
|
+
つまり、パスワード文字列を入力し、流すことを安全にできます。
|
|
236
|
+
|
|
237
|
+
サーバサイドで受け取ったそのパスワード文字列を、そのままDBに保存するのであればパスワード文字列の漏洩につながりますが、ハッシュを保存するのであればサーバ上に素のパスワード文字列が残ることはありません。
|
|
238
|
+
|
|
239
|
+
|
|
240
|
+
|
|
241
|
+
つまり、
|
|
242
|
+
|
|
243
|
+
|
|
244
|
+
|
|
245
|
+
- パスワードは暗号（ハッシュ）化してDBに保存しています
|
|
246
|
+
|
|
247
|
+
|
|
248
|
+
|
|
249
|
+
というのが
|
|
250
|
+
|
|
251
|
+
|
|
252
|
+
|
|
253
|
+
> 「われわれはこのようなセキュリティ対策を行っているので安心して利用できます」と主張する
|
|
254
|
+
|
|
255
|
+
|
|
256
|
+
|
|
257
|
+
ことそのものになります。
|
|
258
|
+
|
|
259
|
+
|
|
260
|
+
|
|
261
|
+
SSL/TLSについては以前 [自分のブログ](http://wp.kaz.bz/tech/etc/ssl1) で数ページまとめたことがありますので、よろしければそちらをご覧ください。
|
|
262
|
+
|
|
263
|
+
|