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.
Security is all about habits, using such tools make you train bad habits.
Sure jwt.io should be fine, but what about the dependencies they use to build it how through are they checked. What about domain hijacking, https downgrade attacks and similar. Etc.
It's probably still all fine for jwt.io they probably use certificate pinning and similar.
If you want to know how tricky attacks can become just look into the etherum dark forest article. Which had been posted here a few days ago.
It's not a question if such attacks (based on undermining widely used web tools) happen it's just about when and how big the fallout will be.
Until one day when you work with ACH files and start having existential dread about the american payroll system.
The file format is archaic, but not objectively worse than any alternative (modern or contemporary). It helps to think of an ACH file as an expression of a line protocol, with field framing and offsets and some internal checksumming.
ACH files are mostly human-readable in their raw form (some simple vim highlighting goes a long way), and that was surely a design goal. It is terse (important for 1960's era data transfer/storage costs) which makes it information-dense, which remains a feature today.
As a system, the ACH Network is incredibly reliable and secure. The security is built into the system, not into the file format. Only trusted players are invited to participate, and the threat of removal is much greater than any enticement to deceive. Furthermore, it is a full-recourse system. Errors can be backed out after the fact.
File delivery is secured in the usual way. Preshared keys, SSH/SSL, etc. ACH is more secure than your bank/broker website, or any ecommerce transactions.
I would like to see encrypted (or at least cryptographically-signed) ACH files, and I wish ACH was used in support of something quicker than a 2x/day (business days only) batch settlement cycle...but that's an interbank/Fed issue.
The ACH network is orders of magnitude more secure than credit cards. And ACH transfers have simple recourse, when errors or fraud occur.
it's a natural worry
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 with your data. FOSS or not, the code we serve can only be trusted as far as you and I we can be. And you don't know us. And you will make mistakes.
Now I'm guilty of it too, I share passwords with 0bin sometimes. But at least it's my service, I can assess the level of threat.
How do you see what people post? Do you see people talking about it, or do you have other means of determining what kind of content gets posted?
Just curious; I'm sure your encryption is on point.
This allowed us to discover we were pretty popular on the crypto community and in specific fan fic subreddits. Which lead us to implement btc tipping and reader mode.
We also got reports, tickets, dmca, etc.
We cannot brute force our thousands of paste encrypted payloads, but for a sample, it's easy to follow the bread crumbs. And if we do it, others do it too.
>The goal of 0bin is not to protect the user and their data (including, obviously, their secrets).
>Instead, it aims to protect the host from being sued for the content users pasted on the pastebin. The idea is that you cannot require somebody to moderate something they cannot read - as such, the host is granted plausible deniability.
Honestly, the forwardness is refreshing.
As they say in the FAQ, the encryption is there to provide plausible deniability for the operator of the site, not to protect the users' data.
Which is why we implemented the delete feature (creating a paste gives you a cookie that allows deletion) recently because we don't want to spend time on customer service for a free site.
https://github.com/eranchetz/sup3rS3cretMes5age
Super easy to set up with Vault, it just hooks into the cubbyhole engine. The one-time-token is also the decryption key for the data store. I find it great for myself and the occasional email but also wouldn't really want to have others use it too much.
Now a zero knowledge pastebin is kind of a category, thanks to the french blogger sebsauvage that started the trend.
Assessing said legitimity is tricky. Not because people lie, up to now they have been pretty decent, but because you really don't want to be tracked while following potentially child pron links, so it may take time.
Scaling moderation could become a problem if 0bin becomes more mainstream, but with so few reports, it's not a problem right now.
So yeah they have to be careful because people are trying to tip them over regularly.
That said I naively plugged my phone on day 2 and their setup gladly accepted my device as a mtp mount (even loaded some drivers on the way).
I had access to stuff I shouldn't..
you get a weird feeling of paranoia yet nothing that solid. It's a big mass with official titles of people trying to be serious.
I have seen idiotic implementations of JWT which effectively leak session details that should only be kept server-side because "it was just easy to validate it on the client-end of things"... this specific example is an extreme one from my career history, and was caught long before it ever made it to prod.
But.
In this engineer's "hello world"-level implementation of JWT they effectively overloaded the session with incredibly sensitive data that should have been server-side-only (later to back-pedal and say this was a "dev only" implementation!). They did use JWT.io to debug their "implementation", and having done that did leak non-trivial details to a third party about how our authentication system was built.
This guy was a "junior engineer" who was hired because of nepotism - making this an even more extreme case... but really it's not. I've worked with incredibly ignorant, careless, not trustworthy, desperate, etc. people through my entire career (admittedly being those things myself sometimes).
Anywho - not leaking implementation details, and potential software/infrastructure secrets is not security through obscurity.
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.)