Live data from Hacker News

Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

jvt.me

41–50 of 170 posts

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#42
post #15

For inspecting JWT tokens, I like the step command-line tool: https://smallstep.com/cli/ pbpaste | step crypto jwt inspect --insecure It can be combined further with jq if you need to dig out a specific field. (pbpaste is a macOS cli command that prints the contents of the clipboard)

This is interesting! I've blogged about an OpenSSL-only version in https://www.jvt.me/posts/2019/06/13/pretty-printing-jwt-open... which optionally needs Python, so you can do it with basically 0 new dependencies, if that's what you want :)

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#44

For those criticizing the author for 'fantasy' security problems, it seems relevant to emphasize that they work at a bank---their threat model is probably rather more vigorous than most.

> they work at a bank---their threat model is probably rather more vigorous than most

Until one day when you work with ACH files and start having existential dread about the american payroll system.

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#45

Webapps like jwt.io run locally in your browser and you can monitor traffic, prevent further requests or even run them yourself to make sure of this. This post is misinformed at best.

did you validate that those sites do not batch data input over time and send them out, much later than your direct user input interactions?

If the app runs locally in the browser, you monitor network connections and whatever else for web sockets, etc, to ensure that no information is passed from your browser to the site beyond the initial http request, then, there never would be any information sent to the site to batch, correct?

I think that is correct.

Also I agree with previous posters who pointed out that for the common JWT use-case: user authentication in an SPA or website, the JWT is running in users browsers and so should not contain any sensitive information to begin with.

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#46
If you could sandbox part of the screen to say this thing is standalone and cannot perform any networking abilities and is cut off from everything else on the page that would be great.

The browser could recognise that tag and you get a safe space for people to copy/paste/interact with online web tools.

I'm pretty sure you can do this with WASM right now, but the browser doesn't inform the user that this is a safe space.

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#47

Earlier quoted context omitted.

So I'm not the only one. It's even worse than that though, enter 'myintranetsite' and hit return, and you end up on a Google search page. Instead you have to enter ' http://myintranetsite'

Type myintranetsite/ instead, this is faster than http:// in front.

As you type, the name is still being sent to Google for search suggestions with every keystroke until the final "/".

If you prefix with "http://", no requests are made to Google (except "h", "ht", "htt", "http", and "http:")

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#48
This is an area where github pages shines. Unless my threat model includes github colluding with the website to steal secrets (it usually doesn’t), I can check the source of a tool once and later be able to view only patches, with a guarantee that the source I see is what’s actually running.

(I work at msft)

Re: Why I Actively Discourage Online Tooling like jwt.io and Online JSON Validators

#50
post #12

Earlier quoted context omitted.

Sure, but to be sure you’d have to validate it every time, because the site’s content may have changed since your last visit. Do you?

No, you'd just have to validate it when you're inputting something particularly sensitive (and I really do usually look in the network console when I'm doing something like that)

Presumably you enter dummy data to validate first. What if it doesn’t send that, but does send the real data?
Post reply on HN