I'm always amazed on which content show up on the front page, there is currently a 15 minutes window on /newest and the most upvoted article is about a page which doesn't really bring anything new, humm
With similar web apps (e.g. hashing of passwords) I was thinking it would be great to be able to show to the user that this web page can't send data anywhere once it is loaded
(I understand that this might be tricky or even impossible (?) to ensure in browsers but it would be interesting to be able to give and prove guarantees like that to the user)
> Unlike JSON Web Tokens (JWT), which gives developers more than enough rope with which to hang themselves, Paseto only allows secure operations. JWT gives you "algorithm agility", Paseto gives you "versioned protocols". It's incredibly unlikely that you'll be able to use Paseto in an insecure way.
I have yet to see a criticism of JWT that doesn't devolve into developers not understanding them and/or misusing them.
Like, I know some devs use them for stateless auth, which means you can't revoke a token, so a stolen token is guaranteed valid until expiration, but I'd file that under misuse.
Hmm, I'm not understanding your point. You say you haven't seen a criticism of JWT that's not just "they're very hard to use correctly", as if that invalidates that criticism.
JWTs are very hard to use correctly. That's the entire problem. Don't use them. Use PASETO.
They're easy to use correctly, but just as easy to use incorrectly.
But this applies to a lot of technologies. Some people treat Base64 like encryption. I've seen passwords stored in databases with Base64 encoding. It doesn't mean Base64 is terrible and insecure, it just means it's being used incorrectly.
I mean, if the official base64 website said "base64 is an open, industry standard method for storing passwords securely in databases", I'd agree with you, but it's only JWT.io that makes that claim.
If you're making a security library that's easy to use incorrectly, it's not easy to use correctly, and it's probably more of an insecurity library.
A) v1.local.CuizxAzVIz5bCqAjsZpXXV5mk_WWGHbVxmdF81DORwyYcMLvzoUHUmS_VKvJ1hn5zXyoMkygkEYLM2LM00uBI3G9gXC5VrZCUM-BLZo1q9IDIncAZTxYkE1NUTMz
B) eyJhbGciOiJIUzM4NCIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkhpIEhhY2tlciBOZXdzIiwiaWF0IjoxNTE2MjM5MDIyfQ.IlIR9_imqGCgEVG_QUb4LhDwSeNhYc50t3Ij5x126scVNJFQqCveblmHx__tqjaI
C) ATkJzynwvPlX6PxBU5BO5xa96S6vymIbmIZnk9og7KxhLHqYLoneLK6WTkyyuGFk7uWZZUnQFVTaThmHzFvaf
D) gAAAAABezWTi-jcq7zlfBaR0vGUy-B9WJ_3lL6S48JO7t9LiW4283zOqBAJvJZEAvusn7OKpgyyoPp2p7okVE4TQfYuihDou67vOHH6G0zqdQz0_1NLvSTM=
If you know which one it is straightaway, then it is the worst choice out of all of them, (because it is not encrypted by default). I would chose the least obvious one here.
You can recognize JWTs without decoding by checking the string format:
JSON Web Tokens follow this format → ALGO+TokenType.Payload.Signature
So obviously the only valid JWT in your question is “B”.
B) eyJhbGciOiJIUzM4NCIsInR5cCI6IkpXVCJ9
.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6
IkhpIEhhY2tlciBOZXdzIiwiaWF0IjoxNTE2
MjM5MDIyfQ
.
IlIR9_imqGCgEVG_QUb4LhDwSeNhYc50t3Ij
5x126scVNJFQqCveblmHx__tqjaI
But this does not matter because you are not supposed to decode random strings expecting them to be JSON Web Tokens. That would be as stupid as assuming that any 32-bytes string is MD5 or any 40-bytes string is SHA1, etc. You either know what your input’s format is or you do not in which case you should not even attempt to decode it because it clearly is not a valid input.
Looking into the page inspector shows 165 http requests on the start page. It includes ads, tracker and analystics from multiple sources (google, twitter, linkedin, facebook etc).
Can anyone sugguest an (offline?) alternative?
I used jwt.io a lot for debugging and it's great.
Currently it is decoding the tokens on the client but I am not sure if I should continue using it.
A hacker could take over the site and capture thousands of access tokens and some are valid for multiple days.
Edit: Installing uBlock origin reduces the number of requests down to 67 but I still see the analytics stuff from google and twitter.
I've been running a local copy since last year sometime, when the website went down when I needed it. I've also stripped away all the annoying things from the website to just get the debugger. Very easy to do!
If you want something locally and use the command line, I’ve created and maintain a jwt cli tool to encode and decode jwts. https://github.com/mike-engel/jwt-cli
Side note: the DuckDuckGo Firefox extension kills a lot of those analytics and tracker requests. Contrary to some of the reviews, turning it off is as easy as flipping a switch.
Good to know : You can only paste parts of the token and it will decode it without any problem. I always leave the signature part out of it when I use this tool.
If you have concerns that the page might steal the tokens, leaving out the signature if you're not trying to debug it prevents a valid token from touching the site.
If you want to avoid pasting tokens in online tools (right now it looks like they don't send out / record anything, but as a general practice, pasting sensitive tokens in online tools is probably not the best idea)
Then this one liner in the browser console can be used for most purposes:
I’ve been using this for debugging tokens in my shell. It’s convenient when using curl or httpie to just grab the auth header and pipe it. https://github.com/mike-engel/jwt-cli
42 comments
[ 1.7 ms ] story [ 91.5 ms ] threadhttps://news.ycombinator.com/item?id=21783303 6 month ago 227 comments (first comment by dang referencing all the other posts)
https://news.ycombinator.com/item?id=22354534 3 months ago 166 comments
and a bunch of other discussions: https://hn.algolia.com/?q=jwt
(I understand that this might be tricky or even impossible (?) to ensure in browsers but it would be interesting to be able to give and prove guarantees like that to the user)
I think it might take quite a few changes though. Very interesting idea.
https://github.com/paragonie/paseto
> Unlike JSON Web Tokens (JWT), which gives developers more than enough rope with which to hang themselves, Paseto only allows secure operations. JWT gives you "algorithm agility", Paseto gives you "versioned protocols". It's incredibly unlikely that you'll be able to use Paseto in an insecure way.
Like, I know some devs use them for stateless auth, which means you can't revoke a token, so a stolen token is guaranteed valid until expiration, but I'd file that under misuse.
JWTs are very hard to use correctly. That's the entire problem. Don't use them. Use PASETO.
They're easy to use correctly, but just as easy to use incorrectly.
But this applies to a lot of technologies. Some people treat Base64 like encryption. I've seen passwords stored in databases with Base64 encoding. It doesn't mean Base64 is terrible and insecure, it just means it's being used incorrectly.
If you're making a security library that's easy to use incorrectly, it's not easy to use correctly, and it's probably more of an insecurity library.
JSON Web Tokens follow this format → ALGO+TokenType.Payload.Signature
So obviously the only valid JWT in your question is “B”.
But this does not matter because you are not supposed to decode random strings expecting them to be JSON Web Tokens. That would be as stupid as assuming that any 32-bytes string is MD5 or any 40-bytes string is SHA1, etc. You either know what your input’s format is or you do not in which case you should not even attempt to decode it because it clearly is not a valid input.Can anyone sugguest an (offline?) alternative?
I used jwt.io a lot for debugging and it's great. Currently it is decoding the tokens on the client but I am not sure if I should continue using it.
A hacker could take over the site and capture thousands of access tokens and some are valid for multiple days.
Edit: Installing uBlock origin reduces the number of requests down to 67 but I still see the analytics stuff from google and twitter.
I've been running a local copy since last year sometime, when the website went down when I needed it. I've also stripped away all the annoying things from the website to just get the debugger. Very easy to do!
https://addons.mozilla.org/en-US/firefox/addon/duckduckgo-fo...
[1] https://github.com/smallstep/cli
https://jwtdebugger.app/
Then this one liner in the browser console can be used for most purposes:
Non-code version for mobile users.
My contribution: a bookmarklet I use to copy JWTs from my internal sites to the clipboard. Replace jwt_name with your name
javascript: (function() { var textArea = document.createElement("textarea"); textArea.value = window.sessionStorage.jwt_name; document.body.appendChild(textArea); textArea.select(); document.execCommand('copy'); document.body.removeChild(textArea); })();
# JWT Payload. Provide the JWT as the argument e.g. jwtp "$JWT"
alias jwtp="jq -R 'split(\".\") | .[1] | @base64d | fromjson' <<<"
# JWT Header. Provide the JWT as the argument e.g. jwth "$JWT"
alias jwth="jq -R 'split(\".\") | .[0] | @base64d | fromjson' <<<"
It's considered insecure to store them in local storage for XSS etc
Where / how are you storing them locally for headless apps?