6 ms·

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 rathe

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.

thieving_magpie 6y ago
> 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.
- dathinab 6y ago
  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.
  - R0b0t1 6y ago
    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.
  - quesera 6y ago
    I don't think this is a good argument. The ACH network is orders of magnitude more secure than credit cards. And ACH transfers have simple recourse, when errors or fraud occur.
- redbeard0x0a 6y ago
  Working with ACH is NACHA a good day, the day you realize all of banking is built on falling dominos.
- quesera 6y ago
  ACH gets a bad rap. 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.
antihero 6y ago
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.
- dathinab 6y ago
  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.)
- folkhack 6y ago
  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.
agumonkey 6y ago
worked at a courtroom, most pastebin clones were banned it's a natural worry
- staticautomatic 6y ago
  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.
  - agumonkey 6y ago
    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.
- BiteCode_dev 6y ago
  And a good one too. I'm currently maintaining https://0bin.net 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.
deleted 6y ago
[deleted]
dathinab 6y ago
It also is sadly not fantasy. 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.
- GrantZvolsky 6y ago
  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.

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.

thieving_magpie 6y ago

> 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.

dathinab 6y ago
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.
- R0b0t1 6y ago
  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.
- quesera 6y ago
  I don't think this is a good argument. The ACH network is orders of magnitude more secure than credit cards. And ACH transfers have simple recourse, when errors or fraud occur.
redbeard0x0a 6y ago
Working with ACH is NACHA a good day, the day you realize all of banking is built on falling dominos.
quesera 6y ago
ACH gets a bad rap. 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.

antihero 6y ago

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.

dathinab 6y ago
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.)
folkhack 6y ago
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.

agumonkey 6y ago

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

staticautomatic 6y ago
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.
- agumonkey 6y ago
  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.
BiteCode_dev 6y ago
And a good one too. I'm currently maintaining https://0bin.net 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.

deleted 6y ago

[deleted]

dathinab 6y ago

It also is sadly not fantasy. 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.

GrantZvolsky 6y ago
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.