Tag Info

New answers tagged

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.


4

UUID of type "v4" are supposed to be generated with 122 random bits: o Set all the other bits to randomly (or pseudo-randomly) chosen values. However, it is not said that the said bits must come from a cryptographically secure PRNG (section 4.5 recommends it but does not mandates it). IF the 122 bits indeed come from a secure PRNG, then they are ...


0

Step 1 to 3 are obsolete as they do not provide any security here just obscurity. Credentials should never be hardcoded (CWE 748). Step 4: good, ensure you perform certificate pinning Step 6: How will you retrieve the password for a given username if you hash it? What algorithm are you using? Step 7: Why use AES, why not generate a random token using a ...


5

From the question: "because the request should not occur twice." No storage means no sense of history which is necessary for your requirement that something shouldn't occur twice. So the answer is no. If you want your server app to remember what happened in the past it has to be able to store that somewhere. You could implement a nonce that was ...



Top 50 recent answers are included