4 ms·
Wow, the issue with the signed token is very interesting. Found it surprising the authentication method specifically wasn't mentioned in the remediation. Food
by jtmarmon 9y ago
Wow, the issue with the signed token is very interesting. Found it surprising the authentication method specifically wasn't mentioned in the remediation.
Food for thought: the security issue wouldn't have happened if (1) travis used UUIDs instead of sequential IDs as a pkey, or (2) used a secret token for auth instead of a signed (presumably) JWT.
- jonny_eh 9y ago1) They don't need UUIDs as a pkey, but just as another field. I like using auto-incrementing IDs as the primary key, and UUIDs for referencing records over internet-facing APIs. Best of both worlds! 2) Totally, JWTs are evil.
- tehlike 9y agoBack in the day uuid as pk was very inefficient due to sorted nature of pk. Time dependent uuid might be less so. You are right, another uuid field would have solved this.
- testplzignore 9y agoI don't know much about JWTs. Why are they bad?
- zrail 9y agoJWT itself is a nice container for signing a small amount of JSON and being able to easily pass that around. I use it a lot for situations where I want to ensure someone hasn't futzed with the data, and/or I want an auto-expiring token of some sort. JWT, by itself, is not an authentication and authorization system, but people often use it as such.
- bpicolo 9y ago> used a secret token for auth instead of a signed Seems that you'd still have an issue here, as the secret token would still be linked to a user ID somewhere in the system.
- jtmarmon 9y agoIf you use a secret token you would compare the token from the first user 123 to what’s stored in the DB (for the second user ID) see that it doesn’t match and not log them in. Because they used a signed user ID, there was no way to differentiate the user 123 from before the system restore and after.
- deleted 9y ago[deleted]