Replies: 3 comments
-
I'm working with some legacy code and share a JWT token with a 3rd-party service. Currently we have no option to change the secret being used to sign the JWTs. I have to generate a token to debug the application and I was always using jwt.io but now it's not possible due to long secret key requirement. Please add the option to override this and allow short keys. |
Beta Was this translation helpful? Give feedback.
-
I've been loving the new UI, but I had to revert to v1 so I could continue to generate tokens with shorter keys for a legacy system. |
Beta Was this translation helpful? Give feedback.
-
+1 on this. In our case, we use short keys for fast and simple debugging. |
Beta Was this translation helpful? Give feedback.
-
I am using jwt.io for security training. Version 2 is really excellent! The revival of alg=none is convenient for conducting security training. Thank you.
I have one request. Currently, weak (short) HMAC keys are allowed on the decode screen, but I would like short HMAC keys to be permitted on the encode screen as well. Of course, I understand that the current specification is for security reasons. However, when demonstrating the risks of using short keys in security exercises, situations arise where we need to use short keys. Currently, I'm using jwt_tool and other tools in combination, but if this could be done with jwt.io alone, it would improve the convenience of training.
Regarding security concerns, perhaps you could implement an option switch that says "Use short keys (dangerous)" or allow short keys but display a warning?
Beta Was this translation helpful? Give feedback.
All reactions