41–50 of 55 posts
Also see: https://news.ycombinator.com/item?id=9111049 Where are the CVEs?! ... OK, I just sent a brief write-up to the oss-security list, we'll see what happens.
From the specificaiton: Even if a JWT can be successfully validated, unless the algorithm(s) used in the JWT are acceptable to the application, it SHOULD reject the JWT.
So what it is saying is that you should have code in your application to make sure to only trust algorithms that you like.
The other issue is that following the specifications rules for validation get you in a hairy spot where this vulnerability exist:
https://tools.ietf.org/html/draft-ietf-oauth-json-web-token-...
Don't use JSON Web Tokens.
Earlier quoted context omitted.
Your "reliability" point I'd question because a session table method is harder to attack. But I'd be willing to agree that their reliability would be on a par with each other (where session tables are weaker, JWT's excel; and visa versa). If you don't mind me asking a few more questions, how are the JSON web tokens typically authenticated if not via a database? Or are they assumed correct? edit: Would the guy who dow…
> how are the JSON web tokens typically authenticated if not via a database? They are signed with a private key (e.g. a secret random 32-bytes kept by the server) when they are issued. Revocation is typically based on an expiration time, hence the timestamp in the header. The JWT libraries in this case failed their basic premise, that is, to verifying the signature. An unsigned token which contains trusted data is ju…
Yeah, in hindsight I can see how some might assume that. I did read the article but was very confused by it. I was having a particularly dim moment and just couldn't fathom JWT's out (I guess we all have days where even the simple things don't seem to mentally "click"?)
Thankfully yourself and others have done a good job explaining things (reiterating where necessary).
Thank you :)
- Ruby, Java, Lua, Scala and .NET are unaffected
- updates are available for Node.js and Python
- there are still no fixed version for JavaScript and PHP libs
Earlier quoted context omitted.
That's a security point, not a reliability point. They will be more reliable, as you don't need to talk to e.g. MySQL that might be down or slow. The disadvantage is that they're difficult to revoke. Cryptography is used to verify them.
> That's a security point, not a reliability point. I appreciate the distinction you're making, but in my opinion security and reliability are one and the same when you're discussing authentication methods. The lack of security would render your system unreliable (as you can't ever be certain the credentials are valid); and an unreliable software stack would be detrimental to the security of the authentication (bugs…
"the database"? Sure, if you've ruled out building systems that split state across multiple databases, filesystems, etc. However, what if you (for instance) want to isolate the user login system from the purchasing system, so that if someone discovers a DoS exploit against your login DB, users who are already logged in can still use your website and make purchases against your orders DB?
I ran into something similar back around 2005-6. My employer had a big problem with credit card thieves buying our inexpensive product in order to filter canceled CCs from usable CCs. All of the recommended open-source CAPTCHAs at the time expected that the code creating the CAPTCHA image and the code verifying the user's answer shared a filesystem and/or a database. For security reasons, our CC-processing machine was a bare minimum machine with bare minimum interface to the outside world.
So, what I did was make a security token that was tok = HMAC( key0, Concat( timestamp | 0x3F, ipv4addr | 0xFF ) ) ] . I then used seed = HMAC( key1, tok ) to seed a 31-bit linear feedback shift register that was used first to generate several base32 characters and then used to generate the positions of those characters and the psudorandom distortions of the CAPTCHA image. The main webserver then just created a form with hidden fields for tok and timestamp (plus all of the payment information) that made an HTTPS POST to the payment webserver. That way, each IP address would only get a new CAPTCHA every 32 seconds (so they couldn't just hammer us until we gave them some easy pseudorandom distortions), we had a verified timestamp for expiry (so we had a bound on how long we needed to keep successful answers in our anti-replay history), and users wouldn't get rejected if their ISP's NAT or DHCP setup changed their external IP within the same /24 between getting the CAPTCHA and submitting the purchase. The only pieces of shared state between the two servers were key0 and key1.
This wasn't JWT, but it illustrates a real world case where there was a strong need to separate state between two systems and have the client transmit the cryptographically authenticated data between the two systems.
As an aside, the system was built incrementally over the course of one evening. First stage deployment used dummy stub code for the anti-replay history database and sat back and waited for a thief to come along and hit us with a batch of several thousand stolen CCs. An IP from Virginia hit us a few times a second for a couple minutes with purchase POSTs missing the token and timestamp fields, all with different names and CCNs. After a pause of a couple of minutes, I started seeing a few successful purchases per second from that IP address, all using the same token and timestamp. I quickly manually banned that IP address and within 30 seconds saw several rejects per second from an IP address in England trying to use the cryptographic token tied to the /24 in Virginia. Then the attacker apparently decided it was easier to verify the stolen CCs somewhere else rather than try and OCR our CAPTCHA.
Don't use JSON Web Tokens.
Don't use JSON Web Tokens.
Can you expand? JWT are a good way to remove state from the service and the HMAC lets you trust it. This looks like an implementation bug, which is unfortunate, but not a reason to avoid the technology.
I don't understand why you need the alg property at all. I mean, you are the one issuing the token so you definitely know what algorithm is used in the back-end. Why is this necessary?
If you change your algorithm, your old tokens are still usable because you know which algorithm was used to create them.
If you're switching off an algorithm, you're probably doing it because it's been broken. And, if it's broken, you won't use it anyway.