3

通信に HTTP を使用して、ブラウザー以外のクライアント サーバー (XULRunner-CherryPy) アプリケーションを構築しています。私が今考えている分野は、ユーザー認証です。私はセキュリティに関する十分な知識を持っていないので、自分で何かを発明したり構築したりするよりも、実証済みのアプローチと既製のライブラリを使用することを好みます。

私は最近たくさんの記事を読んでいますが、私が残したのは多くのフラストレーションだけだと言えます。

私が必要だと思うのは：

  • データベース内のパスワードの安全な保管 (適応ハッシュ?)
  • ユーザー資格情報の安全な送信 (ダイジェスト認証? SSL?)
  • 後続のリクエストに対する安全なトークン認証 (これについては不明)

問題は、これを実装する最新の (できれば頭痛のない) 手法やライブラリは何ですか? (クレジット カード番号などの機密情報は保存されません)。

私は OAuth を見てきましたが、彼らは使用を強く推奨する新しいリビジョンを持っています。問題は、ドキュメントがまだ開発中であり、新しいリビジョン (?) を実装するライブラリがないことです。

4

3 に答える 3

1

かなり安全なAmazonS3デザインに基づいて独自のプロトタイプを作成しようと何度も試みた後、すべての質問に対する回答が記載されたこの優れたWebサイト、Enterprise SecurityAPIToolkitなどを見つけました。詳細：OWASP。

于 2010-03-01T16:58:34.057 に答える
1

アマゾン ウェブ サービス、OpenID、および OAuth には、リクエスト署名の例があります。アマゾン ウェブ サービスは、対話に関するより複雑なプロトコルがないため、従うのが簡単な例です。基本的には、クライアントまたはサーバーがすべてのフィールドを事前に設定されたキー (またはキーペア) でハッシュすることによってリクエストに署名し、反対側でも同じことを行って署名を検証する必要があります。フィールドにノンスまたはタイムスタンプを含めることで、ハッシュの再生が防止されます。

これを許可するキーまたはその他の資格情報の設定は、SSL 経由で行うことができます。OAuth WRAP の動機の 1 つは、実装を容易にするために、この要求署名の一部またはすべてを SSL に置き換えることであることに注意してください。

于 2010-01-06T23:11:34.710 に答える
1

これは完全な答えではないかもしれませんが、レインボー テーブルと Web について心強いニュースを提供したいと思います。次の理由により、Web に関してはレインボー テーブルについてあまり心配する必要はありません。

(1) レインボー テーブル クラックは、ハッシュ化されたパスワードを調べることで機能します。Web では、ハッシュ化されたパスワードがデータベースに保存されるため、レインボー テーブルの使用を検討するためにも、最初にデータベース全体をハッキングする必要があります。

(2)ほとんどのパスワード ストレージ システムのようにソルトを使用すると、レインボー テーブルは急速に実行不可能になります。基本的に、ソルトは特定のパスワードの末尾に一連の余分なビットを追加します。レインボー テーブルを使用するには、各平文パスワードの余分なビットに対応する必要があります。たとえば、あなたが私たちに示した最初のリンクには、パスワードで最大 14 文字をクラックできるレインボー テーブルの実装がありました。したがって、salt が 14 バイトを超えると、そのシステムは役に立たなくなります。

于 2010-01-03T09:14:55.040 に答える