Hacker News Reader

Comment by jtmarmon | Hacker News Reader

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.

View on HN

1) 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.

Back 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.

I don't know much about JWTs. Why are they bad?

JWT 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.

> 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.

If 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.

Reply on news.ycombinator.com