Skip to main content

Home/ Akademik Güvenlik/ Group items tagged key

Rss Feed Group items tagged

Seçkin Anıl Ünlü

Hueniverse: Beginner's Guide to OAuth - Part III : Security Architecture - 0 views

  • OAuth's stated objective is to create an 'authorization delegation protocol'. Allowing one party to access someone else's resources on their behalf is the core of the OAuth protocol and the void it seeks to fill. In this delegated access scenario, also known as the 3-legged scenario, the three parties (legs) involved are the Service Provider, Consumer, and User. Since requests are only made by the Consumer, it needs a way to authenticate itself with the Service Provider, but also to authenticate its authorization to access User data. This requires OAuth to support an HTTP request with two sets of credentials.
  • OAuth can do an equally good job at addressing the direct access scenario, also known as the 2-legged scenario.
  • The Consumer is accessing the resources on behalf of itself, making the Consumer and User the same entity. This can be a bit confusing when a Consumer is making separate requests, both 2-legged requests on behalf of itself, and 3-legged requests on behalf of a User.
  • ...19 more annotations...
  • In everyday web transactions, the most common credential used is the username-password combination. OAuth's primary goal is to allow delegated access to private resources. This is done using two sets of credentials: the Consumer identifies itself using its Consumer Key and Consumer Secret, while the User is identified by a Token and Token Secret.
  • But while the Consumer credentials work much like a username and password, the User is represented by a Token which is different than their actual username and password. This allows the Service Provider and User greater control and flexibility in granting Consumer access.
  • OAuth includes two kind of Tokens: Request Token and Access Token. Each Token has a very specific role in the OAuth delegation workflow.
  • While mostly an artifact of how the OAuth specification evolved, the two-Token design offers some usability and security features which made it worthwhile to stay in the specification. OAuth operates on two channels: a front-channel which is used to engage the User and request authorization, and a back-channel used by the Consumer to directly interact with the Service Provider. By limiting the Access Token to the back-channel, the Token itself remains concealed from the User. This allows the Access Token to carry special meanings and to have a larger size than the front-channel Request Token which is exposed to the User when requesting authorization, and in some cases needs to be manually entered
  • The request signing workflow treats all Tokens the same and the workflow is identical. The two Tokens are specific to the authorization workflow, not the signature workflow which uses the Tokens equally. This does not mean the two Token types are interchangeable, just that they provide the same security function when signing requests.
  • OAuth uses digital signatures instead of sending the full credentials (specifically, passwords) with each request. Similar to the way people sign documents to indicate their agreement with a specific text, digital signatures allow the recipient to verify that the content of the request hasn't changed in transit.
  • In turn, the recipient performs the same workflow to calculate the signature of the request and compares it to the signature value provided. If the two match, the recipient can be confident that the request has not been modified in transit.
  • By itself, hashing does not verify the identity of the sender, only data integrity. In order to allow the recipient to verify that the request came from the claimed sender, the hash algorithm is combined with a shared secret. If both sides agree on some shared secret known only to them, they can add it to the content being hashed. This can be done by simply appending the secret to the content, or using a more sophisticated algorithm with a built-in mechanism for secrets such as HMAC.
  • The benefit of this approach compared to the HTTP 'Basic' authorization scheme is that the actual secret is never sent with the request. The secret is used to sign the request but it is not part of it, nor can it be extracted (when implemented correctly).
  • In OAuth, the shared secret depends on the signature method used. In the PLAINTEXT and HMAC-SHA1 methods, the shared secret is the combination of the Consumer Secret and Token Secret. In the RSA-SHA1 method, the Consumer Private Key is used exclusively to sign requests and serves as the asymmetric shared secret. The way asymmetric key-pairs work, is that each side — the Consumer and Service Provider — use a one key to sign the request and another key to verify the request. The keys — Private Key for Consumer and Public Key for the Service Provider — must match, and only the right pair can successful sign and verify the request. The advantage of using asymmetric shared secrets is that even the Service Provider does not have access to the Consumer's Private Key which reduces the likelihood of the secret being leaked.
  • When implementing OAuth, it is critical to understand the limitations of shared secrets, symmetric or asymmetric. The Consumer Secret (or Private Key) is used to verify the identity of the Consumer by the Service Provider. In case of a web-based Consumer such as web server, it is relatively easy to keep the Consumer Secret (or Private Key) safe.
  • This does not prevent using OAuth within such application, but it does limit the amount of trust Service Provider can have in such public secrets. Since the secrets cannot be trusted, Service Provider must treat such application as unknown entities and use the Consumer identity only for activities that do not require any level of trust, such as collecting statistics about applications.
  • Using OAuth for simple sign-in has the same user experience as HTTP 'Basic', but when used over an insecure channel OAuth provides much greater security.
  • The signature and shared secret provide some level of security but are still vulnerable to attacks. The signature protects the content of the request from changing while the shared secret ensures that requests can only be made (and signed) by an authorized Consumer. What is missing is something to prevent requests intercepted by an unauthorized party, usually by sniffing the network, from being reused. This is known as a replay attack. As long as the shared secrets remains protected, anyone listening in on the network will not be able to forge new requests as that will require using the shared secret. They will however, be able to make the same sign request over and over again.
  • To prevent compromised requests from being used again (replayed), OAuth uses a nonce and timestamp. The term nonce means 'number used once' and is a unique and usually random string that is meant to uniquely identify each signed request. By having a unique identifier for each request, the Service Provider is able to prevent requests from being used more than once.
  • Using nonces can be very costly for Service Providers as they demand persistent storage of all nonce values received, ever. To make implementations easier, OAuth adds a timestamp value to each request which allows the Service Provider to only keep nonce values for a limited time.
  • OAuth defines 3 signature methods used to sign and verify requests: PLAINTEXT, HMAC-SHA1, and RSA-SHA1.. PLAINTEXT is intended to work over HTTPS and in a similar fashion to how HTTP 'Basic' transmits the credentials unencrypted. Unlike 'Basic', PLAINTEXT supports delegation. The other two methods use the HMAC and RSA signature algorithm combined with the SHA1 hash method.
  • HMAC-SHA1 offers a simple and common algorithm that is available on most platforms but not on all legacy devices and uses a symmetric shared secret. RSA-SHA1 provides enhanced security using key-pairs but is more complex and requires key generation and a longer learning curve.
  • Not only must they both use the same algorithm and share secret, but they must sign the same content. This requires a consistent method for converting HTTP requests into a single string which is used as the signed content — the Signature Base String
Ibrahim Ethem Bagci

Technology Review: Who's Typing Your Password? - 0 views

  •  
    Okuma grubundaki "Typing Patterns: A Key to User Identification" adlı makaledeki çalışmaya benzr, daha da iyi gibi görünüyor.
Seçkin Anıl Ünlü

uTorrent Web - Privacy - 1 views

  • The µTorrent Web servers do not see the details of your torrent activity. If you add a torrent, for example, we know that a torrent was added, but not the torrent URL or infohash.
  • µTorrent Web uses a cryptographic protocol called SRP, the Secure Remote Password protocol.
  • your web browser serves as the client and your uTorrent client as the server. The µTorrent Web servers act only as a channel between the two.
  • ...4 more annotations...
  • uses JavaScript to authenticate to your client
  • SRP allows each side (browser and uTorrent client) to independently arrive at the same value for a cryptographically-strong secret. This secret is then used as a session key to encrypt the body of the request (which contains the infohashes, URLS, etc.) using the AES encryption standard. This occurs entirely in your web browser, before the request is sent to µTorrent Web for proxying to your uTorrent client.
  • An attacker or intermediary who has access to the entire SRP negotiation should gain no information which would enable him to recover the password. It is effectively a zero knowledge proof (http://en.wikipedia.org/wiki/Zero-knowledge_proof) to the server that the client has the password.
  • SRP provides perfect forward secrecy: even if an adversary is able to somehow compromise your password, it will not allow the decryption of past sessions.
Ibrahim Ethem Bagci

Center for Information Technology Policy » Lest We Remember: Cold Boot Attack... - 2 views

  •  
    anıl senin şifreni de böyle ele geçirecez, kodları da koymuşlar siteye, sonra öğrenecez senin de kime suikast düzenlemeye çalıştığını :) (harun olabilir mi?)
  •  
    Ha ha izlemiştim ben bunu..
1 - 6 of 6
Showing 20 items per page