2

情報がエンコードされてデータベースに入れられる php/js サイトがあります。情報の暗号化キーはランダムに生成され、ユーザーがフォームから投稿を送信した後に返されます。暗号化キーはデータベースにまったく保存されません。個別のランダムに生成された ID が形成されてデータベースに保存され、解読する前にアイテム自体を検索するために使用されます。

私の質問は、ログを調べて、キーを明らかにする情報を見つけることはまったく可能ですか? 私は、コードを持っている人 (コードを使ってやりたいことを何でもできる人) またはブルート フォース攻撃 (誰かが私の SQL データベースを取得した場合は避けられない) なしに、SQL データを読み取れないようにしようとしています。

私の手順を繰り返すだけです:

  1. ユーザーが POST で情報を送信する
  2. php ファイルはランダムな ID とアクセス キーを生成します。データはアクセス キーで暗号化され、ID を PRIMARY KEY として php データベースに格納されます。
  3. php ファイルは、ランダム ID とアクセス キーのみをエコーし​​ます。
  4. ウェブサイトは jQuery を使用してキーとmysite.com?i=cYFogD3Se8RkLSE1CA [9 桁の A-Ba-b09 = ID][9 桁の A-Ba-b09 = キー]からリンクを作成します。

誰かが私のサーバーにアクセスして情報を読み取ることができた場合、可能性はありますか? メッセージを自分で読むための情報にしたい。情報はデコード可能である必要があり、一方向のエンコードはできません。

4

4 に答える 4

2

復号化キーを含むURLのシステムが気に入っているので、ユーザーのコンピューターでのみデータを利用できない場合でも、アクセスすることはできません。

これにはまだいくつかの落とし穴があります。

  1. 多くの場合、URLはWebサーバーのログに保存されます。あなたがディスクにログインしていて、彼らがディスクを取得した場合、彼らはキーを取得します。

  2. 攻撃者がデータベースにアクセスできる場合、URLをログに記録するソフトウェアを密かにインストールするのに十分なシステムへのアクセス権を持っている可能性があります。彼は、ログオンをオンに戻すのと同じくらい無作法なことをすることさえできました。

  3. あなたのサイトにアクセスする人は、少なくともURLをブックマークしていて(そうでなければ、彼には役に立たない)、ブラウザの履歴に表示される可能性があります。通常、ブックマークと履歴は安全なデータとは見なされません。したがって、ユーザーのコンピューターに対する攻撃者は(直接座っているか、コンピューターがマルウェアに感染している場合)、データにもアクセスできます。ペイロードが十分に望ましい場合、誰かが静的認証トークンを特にマイニングするウイルスまたはマルウェアを作成し、妥当なヒット率を達成する可能性があります。URLは、ブラウザプラグイン、または「今すぐブックマークをインポートする」という一見合理的な装いで動作する他のアプリケーションでも利用できる可能性があります。

したがって、クライアントがブックマークを持っているだけでなく(情報であるが、誰の頭にも残っていないため、「彼が持っているもの」と見なすことができる)、クライアントにとっても最善のセキュリティであるように思われます。 「彼が知っていること」も提示しなければなりません。したがって、彼のパスワードでも暗号化し、パスワードを保存しないでください。彼がURLを提示するとき、パスワードを要求し、次に両方で​​(シリアルまたは組み合わせて)復号化すると、データは安全になります。

最後に、Googleの2要素認証はサードパーティが使用できることを知っています(たとえば、Dropboxで使用しています)。これは、リソースにアクセスする人に携帯電話を持っているか、何も持っていないことを要求することによって、別の「あなたが持っているもの」を作成します。はい、携帯電話を紛失した場合は頼りになりますが、通常は別の電話番号、または印刷されて財布に隠されているGoogle提供の特別な1回限りの長いパスワードが必要です。

于 2013-01-11T04:06:37.747 に答える
2

いくつかの基本的な定義から始めましょう。

データを別の言語 (通常は私用言語) に翻訳することによるコード保護。スペイン語に翻訳された英語はエンコードされていますが、多くの人がスペイン語を理解しているため、あまり安全ではありません.

暗号鍵を使用してデータを暗号化することでデータを保護します。Julius Caesar によって最初に文書化された文字置換暗号は、この例です。現代の技術には、素数を使用したバイナリ データの数学的操作が含まれます。最良の手法では、非対称キーを使用します。データの暗号化に使用される鍵では解読できないため、別の鍵が必要です。これにより公開鍵が公開され、SSL ブラウザー通信の基礎となります。

暗号化データをエンコードおよび/または暗号化することでデータを保護します。

これらの用語はすべて同じ意味で使用されることがよくありますが、それらは異なり、その違いが重要な場合もあります。あなたがやろうとしているのは、暗号によってデータを保護することです。

データが「クリア」である場合、傍受されると失われます。暗号化されている場合は、データとキーの両方を傍受する必要があります。暗号化およびエンコードされている場合は、データ、キー、およびコードを傍受する必要があります。

データの脆弱性はどこにありますか?

  1. データの最も脆弱な場所は、ストレージ デバイス (USB、CD、紙) または頭の中に誰かの個人的な所有物があることが明らかな場合です。これがウィキリークスの根幹です - 機密情報で信頼されている人々は、その信頼を裏切るように仕向けられています - この倫理については、個人の良心に委ねます。
  2. クライアントとサーバーの間で転送中、またはその逆の場合。国家安全保障上重要なデータを除き、SSL 方式の暗号化で十分です。
  3. プログラムのメモリにあるとき。プログラムのソース コードはキーを保存するのに最適な場所ですが、キー自体は、プログラムを実行するたびに入力する (最適な) パスワードで暗号化して保存する必要があります。コードに埋め込まれます (最悪)。よほどの理由がない限り、1 つのキーで十分です。ユーザーごとに 1 つではありません。また、実際に必要な場合を除き、メモリ内データを暗号化したままにしておく必要があります。また、メモリ内のクリアなデータ構造をすぐに使用し、使い終わったらすぐに破棄する必要があります。キーはどこかに保存する必要があります。そうしないと、データを回復できなくなります。しかし、誰がソース コード (バックアップや置き換えられたバージョンを含む) にアクセスできるのか、バックドアやトロイの木馬をどのようにチェックできるのかを考えてみてください。
  4. プログラムのマシンとデータ ストアの間で転送中の場合。プログラムとデータ ストアの間で暗号化されたデータのみを送信し、キーをデータ ストアに保存しない場合は、これで問題ありません。
  5. データ ストアに格納されている場合。同上。

物理的なセキュリティを見落とさないでください。多くの場合、データを盗む最も簡単な方法は、サーバーに近づいてハード ドライブをコピーすることです。多くの企業 (そして悲しいことに防衛/治安部隊) は、オンラインのデータ セキュリティに何百万ドルも費やし、そのデータを鍵のない部屋に保管しています。また、10 歳の子供が回避できるアクセス プロトコルもあります。

これで素敵な暗号化されたデータができました。あなたのプログラムがそれを求める人に平文で提供するのをどのように止めますか?

これにより、識別、検証、承認が行われます。その他の定義:

識別自分はまあまあであるという人による主張。これは通常、コンピューター プログラムでユーザー名によって処理されます。物理的なセキュリティ アプリケーションでは、自分自身を提示して「私はまあまあです」と言う人によるものです。これは、明示的に口頭で説明するか、パスポートなどの身分証明書を提示するか、またはあなたを認識している知っている警備員によって暗黙的に行うことができます.

検証これは、その人が本人であることを証明するものです。コンピュータでは、これがパスワードの役割です。より正確に言えば、これは、彼らが自分のパスワードを知っていることを証明するものであり、これは全体において大きく、巨大で、巨大で、克服できない問題です。物理的なセキュリティでは、信頼できる文書 (パスポートなど) に記載されている物理的な測定基準 (外見、身長など) をクレームと比較します。ドキュメントを信頼できるようにするには、プロトコルを用意する必要があります。ちなみに、これが悪者を識別する顔認識技術の問題の主な原因です。これは、検証技術を使用して誰かを識別しようとします。「この男は悪い男#1のように見えます」; 何だと思う?70億の人口の多くの人々もそうです。

許可人が識別され、検証されると、特定のことを行い、特定の場所に行く許可が与えられます。このための一時的な身分証明書が与えられる場合があります。訪問者 ID バッジや Cookie を思い浮かべてください。どこに行くかによっては、身元を再確認して再確認する必要がある場合があります。銀行のウェブサイトを考えてみてください。銀行口座を確認するために自分自身を識別して検証し、送金または支払いを行うためにもう一度それを行います。

概して、これはコンピュータ セキュリティ システムの最も弱い部分です。私があなたのデータを盗むのは難しいですが、あなたの身元を盗んでデータを私に渡すのははるかに簡単です.

あなたの場合、これはおそらくあなたの関心事ではありません.ユーザーが通常の商業的な方法でパスワードを設定、変更、および取得できるようにするという通常のことを行う場合、おそらくできる限りのことを行いました.

データ セキュリティは、一方ではセキュリティ、もう一方では信頼と使いやすさの間のトレードオフであることを忘れないでください。物事を難しくしすぎると (価値の低いデータに非常に複雑なパスワードを使用するなど)、システム全体が危険にさらされます (人は人であり、それらを書き留めるため)。

コンピュータのすべてと同様に、ユーザーが問題です!

このデータを保護する理由と、保護するためにいくら費やすつもりですか?

これは古典的なリスク管理の質問です。実際には、このデータを失うことによる悪影響、現在のレベルの保護でこれが発生するリスク、および追加の保護にかかるリスクの削減に見合う価値があるかどうかを考慮する必要があります。

データの損失は、次のいずれかまたはすべてを意味する可能性があります。

  1. 公表してもらう
  2. 間違った人の手に渡った場合
  3. 故意または過失により破壊すること。(バックアップ、みんな!)
  4. 変わったこと。変更されていることがわかっている場合、これはそれを失うことと同じです。そうしないと、誤ったデータに基づいて行動している可能性があるため、これはさらに悪化する可能性があります。

このタイプの考え方は、防衛と政府のデータを最高機密、秘密、制限付き、および制限なし (オーストラリアの分類) に分類することにつながります。ここでも人間の要素が介入します。官僚主義の性質上、ドキュメントに低い分類を与えるインセンティブはなく、多くのインセンティブがありません。そのため、ドキュメントは日常的に過剰に分類されています。これは、制限付き分類の多くのドキュメントを適切なクリアランスを持たない人々に配布する必要があるため、これが起こることを意味します。

これも階層と考えることができます。それについての私の個人的な考え方は次のとおりです。

  1. 領域妥協の防衛は、あなたが考えているレベルに関係なく、私の国/企業/家族の戦略的存続に深刻な悪影響を及ぼします.
  2. 生と死の妥協は、誰かの生命や健康を危険にさらします。
  3. 金銭的妥協により、誰かがお金/車/ボート/スペースシャトルを盗むことができます.
  4. 商業的妥協は、将来の金銭的利益の損失を引き起こします。
  5. 屈辱的な妥協は恥ずかしさを引き起こします。もちろん、あなたが政治家なら、これはおそらくNo 1です。
  6. 個人的なこれらは、あなたが公表したくない詳細ですが、特に地球を揺るがすものではありません. 私はここに私の個人的な病歴を入れますが、プライバシー法に違反することの影響により、屈辱的(人々が発見した場合)または経済的(訴訟または起訴された場合)にまで押し上げられる可能性があります.
  7. プライベートこれは他の誰にも関係のないことですが、彼らに知られても実際にあなたを傷つけることはありません。
  8. パブリック紙に印刷して、誰でも気になるようにします。

レベルに関係なく、このデータが失われたり変更されたりすることは望ましくありませんが、そうである場合は、これが発生したことを知る必要があります。ナチスにとって、エニグマ暗号が破られることは悪いことでした。それが起こったことを知らなかったことは壊滅的でした。

以下のコメントで、ベスト プラクティスについて説明するよう求められました。これは、データのリスク (および組織のリスク許容度) を知らなければ不可能です。データ セキュリティに多額の費用をかけることは、少なすぎることと同じくらい悪いことです。

于 2013-01-11T03:44:06.630 に答える
1

まず、最も重要なことは、本当に優れた完全な法的免責事項が必要であることです。

次に、ユーザーのデータをまったく保存しないでください。

代わりに、ユーザーが (SSL を使用して) データを送信するときに、SessionID とシステムの日時のハッシュを生成します。このハッシュを日時とともにテーブルに保存し、レコード ID を取得します。このハッシュを使用してユーザーのデータを暗号化し、レコード ID とその中のデータを含む URL を生成して、これを (再び SSL を使用して) ユーザーに送り返します。この URL のセキュリティはユーザーの問題であり、ユーザーが送信した内容の記録はもうありません (ログに記録されていないことを確認してください)。

定期的に、古い (4 時間、24 時間?) レコードをデータベースから削除します。

取得要求が (SSL を使用して) 入ってきたら、ハッシュを検索し、そこにない場合は、URL が古いことをユーザーに伝えます。そうである場合は、送信されたデータを復号化して (SSL を使用して) 返送し、データベースからレコードを削除します。

于 2013-01-11T05:24:24.123 に答える
0

少し考えてみましょう

  1. SSLを使用-データは暗号化されます
  2. 承認にユーザー名/パスワードを使用する

誰かがそれを破った場合-あなたはセキュリティに問題があります

それを修正するために努力を費やしてください。この場合、災害復旧は労力の無駄です。基本ケースを正しく取得してください。

于 2013-01-11T02:16:18.020 に答える