Tag Info

New answers tagged

0

The provided example is actually a really bad example for the exact reason you mentioned -- an attacker can just extract the client secret and impersonate the client. The security of this grant relies on how well that client secret can be protected. Further, it relies on how well the channel can be protected, such that an attacker can't create a man in the ...


1

The answer is pretty straightforward: it doesn't. If the token is sent over cleartext then you're hosed. The spec doesn't provide mitigations for security issues that arise from not following the spec's recommendations. Alternatively there is some relief in using the code flow because you're passing a nonce of sorts (the 'code') over cleartext instead. You ...


0

In order to access resources, an app needs to obtain an access token (and eventually an optional refresh token). To obtain the access token a first request including the username and the password has to be sent to the endpoint. Note: the client_id and client_secret are only mandatory for confidential clients or for any client that was issued client ...


2

Say, you're user "bob". You log in with your password on 2014-07-30H12:00:00 and the server, using your scheme, sets your cookie token to: enc("bob", K)+enc("2014-07-30H12:00:00", K) However, bob is malicious. While his boss Alice is away from her desk, he checks her browser cookies and finds out her token: enc("alice", K)+enc("2014-07-30H13:00:00", K) ...


1

SHA(auth-session-cookie) is only useful if the underlying value of auth-session-cookie is itself sufficiently large and random. Also auth-session-cookie should be short lived (eg. 2 minutes), so state isn't valid indefinitely to reduce the risk of replay attacks.



Top 50 recent answers are included