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

91–100 of 170 posts

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

#91

Post by dathinab »

thieving_magpie wrote: post #44
paultopia wrote: post #41

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.

Yes it's sometimes rediculus with what regulated businesses can get away with as long as it's either historical or had been certified to be secure at some point in time.

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

#92

Post by djsumdog »

What's a good open source JSON viewer GUI (or TUI) with Linux support (with collapsing trees, searching, filtering, diff, etc)?

I had these exact same concerns last time I was trying to look for one. I found some online JSON tools and could use them for simple things. But I hated putting the JSON I was working on into some 3rd party website, even if it didn't contain anything sensitiveness.

I try to use jq whenever I can on the command line, but having good, local, visual tools (that aren't plugins to web browser or filled with electron cancer) would be nice.

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

#93

Post by agumonkey »

BiteCode_dev wrote: post #88
agumonkey wrote: post #66

Earlier quoted context omitted.

worked at a courtroom, most pastebin clones were banned it's a natural worry

And a good one too. I'm currently maintaining https://0bin.net , and because we encrypt everything client side, people feel like they can post anything they want. We get some pretty personnal stuff. They really should not. It's a can of worms. We can get compromised. Bought. Receive a court order (we comply with dmca). Or they could be on the wrong URL (typo squatting, phishing...). Don't trust random online services…

how large the amount of daily requests on your service ? just curious

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

#94

Post by redbeard0x0a »

thieving_magpie wrote: post #44
paultopia wrote: post #41

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.

Working with ACH is NACHA a good day, the day you realize all of banking is built on falling dominos.

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

#95

Post by dathinab »

antihero wrote: post #57
paultopia wrote: post #41

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.

I dunno, I worked at a bank that was about to be a Capital One direct competitor and I we weren't really worried about "leaking implementation details" via the structure of our tokens. Sounds like some security through obscurity.

It's still a concern.

Attackers but knowing details can make attacks much harder especially if they attack things where they don't have any direct feedback it also increases the lightly hood of attacks been identified as such by monitoring before they succeed.

Sure you MUST NEVER rely on obscurity for security and any form of obscurity for security which increases complexity is increasing the potential error/bug surface and as such a bad idea. But not freely giving out how exactly your bank works internally is still a very sane/usefull idea.

(It's not the same as e.g. not giving out how a tool a lot of external people use directly works, it's about internal only workings which you don't give out.)

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

#96

Post by dec0dedab0de »

seaerkin wrote: post #32

I agree with the author. Is it highly unlikely, sure, but it's important to create awareness of the risks associated. At the end of the day, you are sending potentially sensitive data to a third party. Good security posture is all about building habits and I personally don't want myself or my team being comfortable with the idea of pasting code or JSON config files into a third party system. If any of these online to…

* Is it highly unlikely, sure, but it's important to create awareness of the risks associated. At the end of the day, you are sending potentially sensitive data to a third party.*

I don't think it is highly unlikely. I think it is highly likely that if you make a habit of using these tools one of them will eventually be compromised. Either through a technical hack, financial pressure, purchase by an immoral entity, or a disgruntled employee somewhere along the path.

Then again if it's just for testing/learning, and the data isn't really sensitive who cares, use what's easiest. Most of the time the easiest for me is jupyter so I can test how it actually works, and when I'm finished I have working code.

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

#97

Post by dathinab »

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.

Security tokens comparable to passwords got leaked to third parties

==> Protocol required replacing all potentially compromised tokens

==> A lot of additional work if this isn't yet automated because it's a WIP project

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

#99

Post by BiteCode_dev »

agumonkey wrote: post #93
BiteCode_dev wrote: post #88

Earlier quoted context omitted.

And a good one too. I'm currently maintaining https://0bin.net , and because we encrypt everything client side, people feel like they can post anything they want. We get some pretty personnal stuff. They really should not. It's a can of worms. We can get compromised. Bought. Receive a court order (we comply with dmca). Or they could be on the wrong URL (typo squatting, phishing...). Don't trust random online services…

how large the amount of daily requests on your service ? just curious

We have about 20k hits a day. Or do you talk about dmca ?

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

#100

Post by dathinab »

ljm wrote: post #30
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 sensitiv…

He spoke not just about JWTs , but also thinks like e.g. certificates. He also mentioned data format displaying tools (e.g. inspect msgpack/json)

Internal only certificates might very well point out some internal only details by what fields extension they used with which value.

Post reply on HN