Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

jvt.me

Post reply on HN
Print view View original

21–30 of 170 posts

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

#21

Post by johnnyfaehell »

hatch_q wrote: post #6

But using google, slack, skype, gitlab, bitbucket... is fine to send sensitive data?

Well, if you're using slack for example you'll normally find that business use it to send a lot more senstive stuff to each other than just API keys. If your slack gets breached you've pretty much got yourself a data breach that you'll need to report (if you're covered by GDPR. If you're GitHub is breached you've probably got major issues and need to do a code aduit to make sure there are no backdoors. If any part of your infrastructure is comprised, you're in trouble. If you get to the nity gritty you've got to store senstive data somewhere.

Honestly, I find it super annoying when someone is fine with me sending them a link to kibana to which the access details are in slack to see a API key but have an issue with me sending the API key to them via slack. The whole we don't trust slack but we'll send customer data to each other via it, have all of our secret business info on it, but the API key for an internal service that just outputs public info, that's too dangerous.

Oh, and then there are the people who store everything on vault or something and then give out the password willy nilly. Mate, if it's got to be encrypted then we shouldn't be giving it out to everytone. If it's got to be given out to everyone then it's not senstive data, it's just private.

For most businesses, the main thing you need to keep safe is your database.

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

#22

Post by elliekelly »

onion2k wrote: post #9
hatch_q wrote: post #6

But using google, slack, skype, gitlab, bitbucket... is fine to send sensitive data?

No, it definitely isn't. Github (and probably others) will show you big scary warning messages if you commit things like AWS keys.

What about when you commit a file with client data or PII?

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

#23

Post by MaxBarraclough »

jordache wrote: post #17
hatch_q wrote: post #6

But using google, slack, skype, gitlab, bitbucket... is fine to send sensitive data?

i hate how when I'm copying + pasting a url to a test or internal environment, to the browser address bar - I may have a typo in there, or an extra space. Bam! The URL just became a google search

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'

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

#24

Post by jaywalk »

I think the author is over dramatic. Like when he says this:

>I've been burned a number of times by folks putting a Non-Production JWT or an Open Banking Sandbox certificate into jwt.io.

He hasn't been "burned" by that at all. No security breach occured because of that. He does have somewhat of a point, but he goes off into fantasy land trying to justify it.

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

#25

Post by gruez »

shawnz wrote: post #12
ryukafalz wrote: post #7

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)

The network console isnt going to tell you if the site's exfiltrating data via websocket or webrtc.

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

#26

Post by mschuster91 »

MaxBarraclough wrote: post #23
jordache wrote: post #17

Earlier quoted context omitted.

i hate how when I'm copying + pasting a url to a test or internal environment, to the browser address bar - I may have a typo in there, or an extra space. Bam! The URL just became a google search

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.

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

#27

Post by heavenlyblue »

jordache wrote: post #17
hatch_q wrote: post #6

But using google, slack, skype, gitlab, bitbucket... is fine to send sensitive data?

i hate how when I'm copying + pasting a url to a test or internal environment, to the browser address bar - I may have a typo in there, or an extra space. Bam! The URL just became a google search

Doesn’t browser hit suggestions API on every type stroke anyway?

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

#28

Post by tester34 »

shadowgovt wrote: post #18

For JWTs, I agree with this stance, since they are security credentials and therefore basically all of them are sensitive information. I don't discourage online tooling in general. It's a risk/benefit trade-off---No, you shouldn't paste sensitive information into websites run by other people in general, but for non-sensive information where you don't care if the online tool is logging it or not, go for it. There are…

>For JWTs, I agree with this stance, since they are security credentials and therefore basically all of them are sensitive information.

As long as it's prod env and your expiration time is somewhat reasonable, then I don't think it is sensitive at all unless you're storing an actual sensitive informations in them.

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

#30

Post by ljm »

jaywalk wrote: post #24

I think the author is over dramatic. Like when he says this: >I've been burned a number of times by folks putting a Non-Production JWT or an Open Banking Sandbox certificate into jwt.io. He hasn't been "burned" by that at all. No security breach occured because of that. He does have somewhat of a point, but he goes off into fantasy land trying to justify it.

> these are sensitive in of themselves, as they have implementation details for our services, and as mentioned, certain things could be used outside of Capital One.

I imagine these JWTs will find their way into a frontend application in prod (because what else would they be for?), at which point any actual user of theirs could pull the token down and get access to these implementation details. The only thing sensitive about a JWT should be its ability to authenticate a user; encoding actually sensitive data inside that token, such as anything you want kept secret, would be a huge mistake.

Post reply on HN