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.
If you don't trust your team not to paste privileged production tokens to third party services, security training might be a better course of action than defining vague rules.
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.
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.
The alternative is oftentimes doing nothing and putting people out of work. You shouldn't proactively punish people for the potential actions of other unrelated people who might choose to break the law.
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 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.
People post the full links (including the key) everywhere, so regularly, we google a bit to check what people use us for.
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.
The titles aren't encrypted. Perhaps people are putting personal data in the titles of their posts, or hinting at personal data in the encrypted portion? Which is still a problem since the code served by the site has access to the plaintext, even if it's not normally sent back to the server. It would be trivial to change the code to send the plaintext or encryption key to the server, or just weaken the encryption somehow. Even if you trust the site operators they could be ordered to implement a change like that with an NSL, and prohibited from talking about it.
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.
Titles are rarely used, but I did receive emails of users saying "woops, can you delete this ?" with very personnal content.
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.
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.
Up to now we just delete it. We coded an admin for that. It takes time because we have to read the claim and assess the legitimity of it, not for the deletion.
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.
It’s damn near impossible to even get the government to setup a locked down file sharing folder for an active lawsuit using a platform like Box or OpenText that they already have in place unless someone relatively high up is committed to pushing it through IT. The justice system does not mess around. If you try to send, say, a casual Dropbox link to a DOJ employee, they typically aren’t allowed to even click on it.
I came there believing "who cares" really but anytime there's money involved you step into the piranha bay. I heard even lawyers had to be followed around in the archive rooms.. some would snatch documents, or sniff whatever info they could to help their case.
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 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.
Not leaking tokens/token structure !== security through obscurity.
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.)
