151–160 of 173 posts
Earlier quoted context omitted.
Yes, but this is still a deadend.
How so? It's effectively a micro-optimization that will have no real effect, but you can do a simple "exists" query when searching the revocation list, and the TTL keeps the collection small. Not advocating for JWT as it's a silly mess to do everything correctly, but it is possible.
Earlier quoted context omitted.
Your missing the whole point. If the server was to track password_last_changed it might as well just track user_currently_loggedin.
No, there is a huge difference in write load between those two options.
IIRC tptacek has been beating this drum for a while, but it seems that he got tired of it, so I should pick the drum sticks in his stead: Use less crypto. The less crypto is being used, the fewer mistakes are being made. When it comes to sessions, generated a secure random 256 bit token and use that as a session id. Store it in a database or in-memory store. Sticky sessions + local session token storage will fix your…
You think mistakes can't be made with session ids? Anyways, there are well trusted libraries out there for JWT.
Earlier quoted context omitted.
Tying the token to an IP address will largely ameliorate that issue. As always, there is a tradeoff of security and convenience. I've worked at facilities with no internet access, where hard drives were removed and put in safes at the end of the day, and that had "leper lights" which flashed when unsecure people like me were present. Very secure but hardly convenient. You always need to ask yourself what it is that y…
You should not tie any functionality, user experience, and last but certainly not least, security to an IP address. IP addresses can be spoofed rather easily, using public wifi, hotel/guest networks, and even certain ISPs means the rotating of IP addresses on each user request.
Earlier quoted context omitted.
How so? It's effectively a micro-optimization that will have no real effect, but you can do a simple "exists" query when searching the revocation list, and the TTL keeps the collection small. Not advocating for JWT as it's a silly mess to do everything correctly, but it is possible.
Searching a revocation list misses the point of RESTful authentication.
Earlier quoted context omitted.
You should not tie any functionality, user experience, and last but certainly not least, security to an IP address. IP addresses can be spoofed rather easily, using public wifi, hotel/guest networks, and even certain ISPs means the rotating of IP addresses on each user request.
Adding an IP lock to a token can only increase security - it cannot decrease security. And if you wish to be secure, then you wouldn't use public wifi.
Earlier quoted context omitted.
This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impersonate a user.
The signature is already available - it's literally appended to the output. Verifying the signature is done by hashing the body with a secret (key) and comparing it to the known signature. "Known" === HMACSHA256(payload, secret) You already know the left hand side. How would a constant time comparison protect you from a timing attack in this scenario? It wouldn't. The signature is known, the payload is known, but the…
Earlier quoted context omitted.
This is not about retrieving the key, an attacker can still retrieve the correct opaque signature for specific data. This potentially allows an attacker to impersonate a user.
The signature is already available - it's literally appended to the output. Verifying the signature is done by hashing the body with a secret (key) and comparing it to the known signature. "Known" === HMACSHA256(payload, secret) You already know the left hand side. How would a constant time comparison protect you from a timing attack in this scenario? It wouldn't. The signature is known, the payload is known, but the…
In either case, public or private, an attacker shouldn't be able to create their own tokens at their leisure. Token theft is guarded against using encryption, token creation is guarded against using constant-time compare. Encryption cannot protect timing attacks.
Again, the hash secret is irrelevant in the case of trying to generate a token for a specific user. The signature for a specific user payload is an opaque hash that can be discovered via timing analysis. The secret hash function that was used to produce it is not important if timing information is available.
If you cannot understand this, please I beg you, do NOT design crypto systems. If you'd like to be an even better Good Samaritan, please disclose your identity to the community. This may protect your future employer and their customers from a breach.
Also, worth mentioning this article as an opinion: http://cryto.net/~joepie91/blog/2016/06/13/stop-using-jwt-fo... Edit: Title is Stop using JWT for sessions
Earlier quoted context omitted.
The entire last paragraph of my pevious post describes one way to deal with it, without consulting a central session store.
By previous post, did you the bit about "Federation becomes moderately difficult"? I don't know if you've ever developed microservices, but building this logic into every single microservice would be a lot of work. We have dozens of microservices, written in different languages, so even if we wrote some generic glue as a library, we'd have to write it at least three times (Go, Ruby and Node.js).