回答編集履歴
3
追記
answer
CHANGED
|
@@ -7,11 +7,12 @@
|
|
|
7
7
|
1. 暗号化されていないデータはサーバに送信されないようにする（サーバ管理者は通信経路のパケットを確認することが出来るため）
|
|
8
8
|
1. データの暗号化/複合はブラウザ内で完結させる
|
|
9
9
|
1. 暗号化/複合キーを原理的にサーバに送信しない仕組みにする（Cookieにキーを保存するのはNG）
|
|
10
|
+
1. 現実的なリソースでは総当たり突破出来ない暗号強度を持った暗号化データとして格納されること
|
|
10
11
|
|
|
11
|
-
|
|
12
12
|
データ投入時の実装
|
|
13
13
|
---
|
|
14
14
|
1. ブラウザ側のJavaScriptで入力フォームの内容を暗号化し、暗号化キーはその場でエンドユーザに入力させる。
|
|
15
|
+
1. キーとなる文字列が短いと、開発者が総当たりで複合出来てしまうので十分な長さのキーを指定させ、十分に強固な暗号化方式を選択すること。具体的にどれくらいの長さであればどれくらいのリソースが必要かは`暗号 総当たり`等で調べて定義してください。単純にキー入力させると脆弱な長さにしかならないので工夫のしどころだと思います。
|
|
15
16
|
2. PHP側では入力された内容を文字列としてDBに投入
|
|
16
17
|
|
|
17
18
|
データ表示時の実装
|
2
脱字修正
answer
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
1. ブラウザ側のJavaScriptで入力フォームの内容を暗号化し、暗号化キーはその場でエンドユーザに入力させる。
|
|
15
15
|
2. PHP側では入力された内容を文字列としてDBに投入
|
|
16
16
|
|
|
17
|
-
データ表示時
|
|
17
|
+
データ表示時の実装
|
|
18
18
|
---
|
|
19
19
|
1. PHPは暗号化対象のデータ`以外`をキーとしてデータを取得する
|
|
20
20
|
2. ブラウザは暗号化されたデータを受け取った後に、エンドユーザのキー入力 or ブラウザのパスワード管理機能を使って複合キーを使って複合する
|
1
追記
answer
CHANGED
|
@@ -22,4 +22,30 @@
|
|
|
22
22
|
|
|
23
23
|
---
|
|
24
24
|
検索するとしたら
|
|
25
|
-
`JavaScript 文字列 暗号化`あたりでしょうか。
|
|
25
|
+
まずは`JavaScript 文字列 暗号化`あたりでしょうか。
|
|
26
|
+
その後に必要になるのは
|
|
27
|
+
`JavaScript フォーム送信`
|
|
28
|
+
あたり。
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
そういったサイトの開発は控えるべきであるか否か
|
|
32
|
+
---
|
|
33
|
+
|
|
34
|
+
> 仮に、不可能もしくは初学者にとって困難であれば、そういったサイトの開発は控えるべきでしょうか？
|
|
35
|
+
|
|
36
|
+
（不正指令電磁的記録作成罪等に該当する場合を除いては）`開発を控えるべきサイト`というものは存在しないと思います。
|
|
37
|
+
|
|
38
|
+
一方で、サイトの公開/使用については
|
|
39
|
+
|
|
40
|
+
- サイトが法的に微妙/アウト
|
|
41
|
+
- セキュリティに問題がある
|
|
42
|
+
- リソースを過剰に使う場合
|
|
43
|
+
|
|
44
|
+
等々の場合
|
|
45
|
+
|
|
46
|
+
- （自己使用を含めて）使用を控えるべきサイト
|
|
47
|
+
- 公開/販売を控えるべきサイト
|
|
48
|
+
- レンタルサーバー上で動かすべきではないサイト
|
|
49
|
+
- 公開にあたっては専門家のサポートを必要とするサイト
|
|
50
|
+
|
|
51
|
+
に該当するケースはありますが、開発難易度と直接関係するものではありません。
|