パスワードを送信する一般的に例外的な方法は、実際に送信しないことです。これは、非常に安全でないと考えられるためです。代わりにあなたが言及したように、ハッシュされたパスワードなどの別のフォームを送信しますが、これはまだ虹の表などいくつかのドローバックを持っています。
したがって、最良の方法は、一度だけ使用されます)、すなわちランダムな文字列とタイムスタンプを送信してください。その後、ハッシュされた文字列、ノンス、タイムスタンプをxml形式でdbサーバーに送信し、ユーザーに保存したパスワードを使用してハッシュされたパスワードを試してみることができます。
これは、W3CのusernameToken仕様がどのように機能するかです。 - http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf
<UsernameToken xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd">
<Username>jon</wsse:Username>
<Password Type="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-username-token-profile-1.0#PasswordDigest">9JSGeXj+zpvEp42I20K/1bg8rCE=</Password>
<Nonce>TaF3g5F37wSHtSdY</Nonce>
<Created>2009-07-25T10:29:34Z</:Created>
</UsernameToken>
しかし、これは望ましくない複雑さをもたらすかもしれません。
パスワードをハッシュしてサーバーに送信すれば、そのバージョンのパスワードをハッシュし、それがあなたのものと一致した場合にのみハッシュできます。とにかく元のログインを飛び越して、それらを逆コンパイルすることができるので、一日の終わりに、実際の.swfファイルがどれくらい安全であるかあなた自身に尋ねなければなりません。しかし、これは大部分のために十分です。
私は通常、as3crypto(code.google.com/p/as3crypto/)を使用しますが、abodeのutilsパッケージにはmd5とsha-1の実装があります。
xmlソケットについては、アクションスクリプトアプリでそのドメインと話すことを許可するクロスサイトポリシーファイルと、フラッシュと話すことを許可するドメイン上のサイトポリシーファイルがある限り、これは問題ありません。そうしないと、セキュリティエラーが発生する可能性があります。
これが役に立ちます。
Jon
出典
2009-07-25 09:36:45
Jon
これらのアプローチのいずれかを実装するには、パスワードをプレーンテキストで保存する必要はありませんか? – MADgood
あなたはdbハッシュにパスワードを保存し、上記の方法、つまりnonce + timestampでパスワードを再ハッシュする前に単純にパスワードをハッシュすることができます。同じサーバー側で同じ結果が得られます。 – Jon
注:上記のxmlの例はハッシュされていますが、base64形式で暗号化されていないので、そのことを明確にすると思っただけです。 – Jon