OAuth Core 1.0 : Appendix B.10. Entropy of Secrets : 俺約/メモ

 

Appendix B.10.  Entropy of Secrets (シークレットのエントロピー)

Unless a transport-layer security protocol is used, eavesdroppers will have full access to OAuth requests and signatures, and will thus be able to mount offline brute-force attacks to recover the Consumer’s credentials used. Service Providers should be careful to assign Token Secrets and Consumer Secrets which are long enough – and random enough – to resist such attacks for at least the length of time that the secrets are valid. (TLセキュリティが無ければ盗聴者がOAuthリクエストとシグネチャにアクセスして、ブルートフォースを使ってConsumerのクレデンシャルを見つけることができるかもしれません。SPはトークンシークレットを慎重に発行することです。十分に長く、十分にランダムにしてくらださい。)

For example, if Token Secrets are valid for two weeks, Service Providers should ensure that it is not possible to mount a brute force attack that recovers the Token Secret in less than two weeks. Of course, Service Providers are urged to err on the side of caution, and use the longest secrets reasonable. (たとえば、2週間だけTokenシークレットが有効であればブルートフォースアタックが時間的に効かないかもしれません。それでも十分な長さのシークレットにすべきです。)

It is equally important that the pseudo-random number generator (PRNG) used to generate these secrets be of sufficiently high quality. Many PRNG implementations generate number sequences that may appear to be random, but which nevertheless exhibit patterns or other weaknesses which make cryptanalysis or brute force attacks easier. Implementors should be careful to use cryptographically secure PRNGs to avoid these problems. (PRNGを使って十分なクオリティのシークレットを作ることも重要です。PRNG実装の多くはランダムに見えても暗号解読者やブルートフォース攻撃者みれば明示的なパターンやその他の弱さを持っている場合があります。十分に安全なPRNGを使ってください。)




Appendix B.11.  Denial of Service / Resource Exhaustion Attacks(DoS/リソース枯渇攻撃)

The OAuth protocol has a number of features which may make resource exhaustion attacks against Service Providers possible. For example, if a Service Provider includes a nontrivial amount of entropy in Token Secrets as recommended above, then an attacker may be able to exhaust the Service Provider’s entropy pool very quickly by repeatedly obtaining Request Tokens from the Service Provider. (SPに対してリソース枯渇を狙った攻撃ができるような数字を多く使っています。Tokenシークレットに十分な量のエントロピがないと、SPのエントロピプールがすぐになくなってしまうかもしれません)

Similarly, OAuth requires Service Providers to track used nonces. If an attacker is able to use many nonces quickly, the resources required to track them may exhaust available capacity. And again, OAuth can require Service Providers to perform potentially expensive computations in order to verify the signature on incoming requests. An attacker may exploit this to perform a denial of service attack by sending a large number of invalid requests to the Service Provider. (同様に使用済みノンスは管理しましょう。攻撃者は多くのノンスを短期で使った場合、キャパシティオーバーになりえます。SPはシグネチャやリクエストの検証に多くのコンピュータリソースを使います。DoSされるかも。)

Resource Exhaustion attacks are by no means specific to OAuth. However, OAuth implementors should be careful to consider the additional avenues of attack that OAuth exposes, and design their implementations accordingly. For example, entropy starvation typically results in either a complete denial of service while the system waits for new entropy or else in weak (easily guessable) secrets. When implementing OAuth, Service Providers should consider which of these presents a more serious risk for their application and design accordingly. (リソース枯渇攻撃はOAuthに限ったことではありません。が、OAuthを提供することで考慮することが増えるのです。エントロピ枯渇によるエントロピ取得待ちでDoSができてしまったり、簡単に予想できるシークレットが生成されたりします。)




Appendix B.12.  Cryptographic Attacks(暗号解読攻撃)

SHA-1, the hash algorithm used in HMAC-SHA1 signatures, has been shown (De Canniere, C. and C. Rechberger, “Finding SHA-1 Characteristics: General Results and Applications,” .) [SHA1] to have a number of cryptographic weaknesses that significantly reduce its resistance to collision attacks. Practically speaking, these weaknesses are difficult to exploit, and by themselves do not pose a significant risk to users of OAuth. They may, however, make more efficient attacks possible, and NIST has announced (National Institute of Standards and Technolog, NIST., “NIST Brief Comments on Recent Cryptanalytic Attacks on Secure Hashing Functions and the Continued Security Provided by SHA-1,” .) [NIST] that it will phase out use of SHA-1 by 2010. Service Providers should take this into account when considering whether SHA-1 provides an adequate level of security for their applications. (SHA-1はHMAC-SHA1で使われるアルゴリズムですが、暗号的には弱いことがわかっています。SHA-1は2010でNISTからドロップされます。SPはこれを考慮すること)

(うーむ。。。。。。。)




Appendix B.13.  Signature Base String Compatibility(SBS互換性)

The Signature Base String has been designed to support the signature methods defined in this specification. When designing additional signature methods, the Signature Base String should be evaluated to ensure compatibility with the algorithms used.

The Signature Base String cannot guarantee the order in which parameters are sent. If parameter ordering is important and affects the result of a request, the Signature Base String will not protect against request manipulation. (SBSは署名をサポートするためにデザインされています。別途署名法を考えるときにはSBSを評価してしてください。SBSパラメータ順序を保障しません。パラメータ順が重要で、リクエストの結果に影響があるときはSBSではうまくいきません。)

OAuth Core 1.0

カテゴリー: 未分類 パーマリンク

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中