4 ms·

Even if the trigger was spoofed, how come there is no secure channel that the govt provides to receive the data? Was this one also compromised?

by hrpnk 19d ago

ang_cire 19d ago
If people actually knew how much of a wild west this stuff is, a lot more would be cautious with their personal info.
- hrpnk 19d ago
  If you are forced to ID check with the bank via a 3rd party, the only way is to ask for removal of data after the ID check. Do you see other ways?
edelbitter 19d ago
That may not matter that much, as even if you run a relatively strict policy about where you send the reply, you can still easily get bitten by external mistakes there: Because of the huge number of individually administered departments that might each become authorized recipient of such data, a malicious party only needs to find one suitably dangling DNS delegation to score a "…@attacker-controlled-subdomain.legitimate.example" mailbox. The sender would not be able to prevent this.. unless its regulatory oversight body is very patient about repeatedly delaying legitimate requests for seemingly-minuscule formal defects. (Mentioning just for context. Probably not the mechanism at play here, Revolut would have tried to shift blame in the press release if it was.)
- dns_snek 18d ago
  I think you missed the point - delivery of sensitive data should involve public key encryption of some sort and it should ideally be done through an application or website that's purpose-built for this. It should be made impossible for someone at Revolut (and every other org) to deliver this data into the wrong hands by accident.
  - edelbitter 18d ago
    Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out, you cannot just sprinkle some "encryption of some sort" magic on top of an already encrypted channel (which was inadequate in auth, not in confidentiality) and get a meaningful improvement from that. Instead, it subtracts from the already way too limited budget that people trying to get actual work done can spend on establishing who they are talking to through distinct comms channels. Not sure what the purpose of those apps even is, other than generating some $$ for the provider (in the most egregious case, Cisco).
    - dns_snek 18d ago
      Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust. You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website. In fact this is a solved problem. My doctor is not legally allowed to email me my own medical records, not even the most mundane blood test result. Instead they send them through the government-operated portal which employs suitable authentication and prevents any sort of transport-level hijacking. There is no excuse to be using non-e2ee email for this in 2026. None.
      - edelbitter 18d ago
        What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference. Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no? I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.

Even if the trigger was spoofed, how come there is no secure channel that the govt provides to receive the data? Was this one also compromised?

by hrpnk 19d ago

Even if the trigger was spoofed, how come there is no secure channel that the govt provides to receive the data? Was this one also compromised?

ang_cire 19d ago

If people actually knew how much of a wild west this stuff is, a lot more would be cautious with their personal info.

hrpnk 19d ago
If you are forced to ID check with the bank via a 3rd party, the only way is to ask for removal of data after the ID check. Do you see other ways?

edelbitter 19d ago

That may not matter that much, as even if you run a relatively strict policy about where you send the reply, you can still easily get bitten by external mistakes there: Because of the huge number of individually administered departments that might each become authorized recipient of such data, a malicious party only needs to find one suitably dangling DNS delegation to score a "…@attacker-controlled-subdomain.legitimate.example" mailbox. The sender would not be able to prevent this.. unless its regulatory oversight body is very patient about repeatedly delaying legitimate requests for seemingly-minuscule formal defects. (Mentioning just for context. Probably not the mechanism at play here, Revolut would have tried to shift blame in the press release if it was.)

dns_snek 18d ago
I think you missed the point - delivery of sensitive data should involve public key encryption of some sort and it should ideally be done through an application or website that's purpose-built for this. It should be made impossible for someone at Revolut (and every other org) to deliver this data into the wrong hands by accident.
- edelbitter 18d ago
  Public key encryption as in DANE already achieves what can be achieved given the constraints. I have seen some purpose-built apps that use email for auth and then establish a different channel to exchange the documents. But that just nets the security properties that you already had with email.. just with some added methods of sideloading trojans past those pesky email attachment scanners. Turns out, you cannot just sprinkle some "encryption of some sort" magic on top of an already encrypted channel (which was inadequate in auth, not in confidentiality) and get a meaningful improvement from that. Instead, it subtracts from the already way too limited budget that people trying to get actual work done can spend on establishing who they are talking to through distinct comms channels. Not sure what the purpose of those apps even is, other than generating some $$ for the provider (in the most egregious case, Cisco).
  - dns_snek 18d ago
    Christ, ease off the condescension, I'm very obviously not talking about "sprinkling in" domain name authentication, but encrypting the data for an eligible recipient using a suitable root of trust. You're discussing this as some inachievable science fiction that would require every employee to learn how to use gpg. In reality this could be achieved through a simple to use website. In fact this is a solved problem. My doctor is not legally allowed to email me my own medical records, not even the most mundane blood test result. Instead they send them through the government-operated portal which employs suitable authentication and prevents any sort of transport-level hijacking. There is no excuse to be using non-e2ee email for this in 2026. None.
    - edelbitter 18d ago
      What is the difference between making sure an HTTPs endpoint does not leak and making sure an IMAPs endpoint does not leak? I do not see much of a fundamental difference. Except, it makes the user experience worse: I can certainly make it infinitely more tedious to open the document exchange site of $superimportantcompany on superimportantcompany.co (or was it .com? or .co.uk? or important-company-le.ai?), and spread out "my" inbox across 30 different sites and spend additional time navigating their unique interfaces to not just read, but also add each document into the appropriate local archive. But what have I gained in making it more likely that each correspondence is kept confidential between the only parties that should read it? Nothing beyond what I started with. Could have stayed with email, no? I can see the appeal of mitigating part of the usability problem by pivoting straight to bundling up all thematically related messages into centralized repositories to limit the number of pseudo-mailboxes one has to maintain simultaneously, as done in the recent "everything medical related" cases. But someone would grab a full copy in the inevitable compromise, and that is a risk that should rather stay scoped to smaller groups of senders and/or recipients. It seems like a bad tradeoff to force every blood test of everyone into the danger zone for that, given that one could have instead spent 3% of the budget on.. merely policing away the DNS warts in public authorities (or, in the medical example, insurance companies) while keeping data custody unchanged.