6 ms·

This made me cringe: > Your [bank] will set you up with a secure FTP server onto which you’ll upload ACH files. Automated financial transactions, with lots of

by bostik 13y ago

This made me cringe: > Your [bank] will set you up with a secure FTP server onto which you’ll upload ACH files. Automated financial transactions, with lots of money involved. Secure. FTP server. Of course I know that FTP is still considered "secure" for some business applications but this is absurd. With all the security (mis)features the banks have put forward with card payments in order to shift liability to account holders, the very core of inter-bank transactions then runs on something as insecure as FTP. The shoemaker's children have no feet.

lisper 13y ago
> This made me cringe As well it should. But it gets worse. Much, much worse: http://blog.rongarret.info/2010/11/personal-banking-nightmare.html http://blog.rongarret.info/2010/11/personal-banking-nightmar... It often amazes me that the U.S. financial system works at all.
- pjg 13y ago
  Maybe. Here's a slightly different perspective. First take the case of ftp'ing/sftp'ing files to a bank. There are multiple layers of security in sftp - not just the username and password. Source IP is checkec in a stateful way so spoofing is hard even if one somehow manages to get the credentials. Furthermore the files will not be processed unless there is an out-of-band message (typically an email, could be a phone call too ) with certain info also required in very specific format which must match the contents of the file. So there you go. 3 layers of security with one layer being completely out-of-band with the other two is reasonable enough for the risk involved. (There are other measures hard coded e.g. a dollar limit which basically "cap" any fraud but I won't go into those) Now for the missing (or atleast MIA) transaction you allude to on your blog: Just because you were not told how the money ended up where it did doesn't mean people didn't know. Bankers are steeped in "social engineering" and trained from day one to only give out information required by law and really nothing else. Whether you use Fedwire or Swift (or really any other RTGS = real-time gross settlement network ) there is always a trail. Always. In your case it was probably Fedwire - and the bank I'm guessing was BofA or maybe Chase. Regardless if the sender's account is an individual account (not business) they are still protected by Reg E (as well as FDIC insurance). Reg E as you may know basically puts the onus of returning the funds to the sender's account on the bank. The problem is the timelines or the lack of it. Since banks are generally allowed upto 30 days (I don't know if 30 days is hardcoded ) in law they take their sweet time in tracing. And when they find out - they almost always do - they deliberately will not share details with you to protect themselves from liability. The bottom line is ACH/FedWire moves trillions of dollars - hundreds of billions a day - and barring a very small percentage they all work.
  - lisper 13y ago
    > Just because you were not told how the money ended up where it did doesn't mean people didn't know. That's true, but there was a lot of additional evidence that they really didn't know: 1. They said they didn't know. 2. Two weeks passed during which they could not find the money. 3. The money was only found after the person in whose account it ended up contact me (not the bank!) And, BTW, I actually found out later how the mistake had been made: the original wire form had been filled out wrong. It was supposed to be a for-benefit-of wire, but the form was filled out as if for an intermediate-institution wire. And the bank employee who entered the data was apparently completely clueless because they entered an account number as an ABA number (or maybe it was the other way around, it was a long time ago). But it was without a doubt a total clusterfuck from beginning to end. > barring a very small percentage they all work Yes. As I said, this never ceases to amaze me.
- mey 13y ago
  It works primarily not because of technology but because of inter company agreements, contracts and regulations.
- Stratoscope 13y ago
  That's a fascinating post, especially the comment from Don Geddis: > ...I eventually reached the conclusion that "check clearing" doesn't mean anything at all. What there really is, is a web of trust among large financial institutions. They take actions which work 99% of the time, and then they have correction procedures for the 1% that fail... > ...their primary concern is that I'm not a con man who is going to take money out of the system. As long as the cash is EITHER at their bank, OR at the original bank, they can afford to not be completely sure just where it is, and to work that accounting out over time. > This system is totally unlike how computer scientists would design it. They would want guarantees that the money really was only in one place, and there would be a thing which is a "transaction", where the money reliably went from one place to another. A wire transfer is something like that, but it's really bootstrapped on old-time banking, which is a trust relationship with repair procedures, not a guarantee of freedom from error.
awda 13y ago
I don't know anything about ACH, but the author could be referring to FTP-over-TLS ("FTPS") or SFTP (unrelated protocol over SSH), both of which use the initials FTP but aren't as wholly insecure as vanilla FTP.
- wiredfool 13y ago
  I've seen https and scp as well. I'm not sure I've seen plain vanilla ftp in years, and certainly not without pgp encrypting the files first.
- edawerd 13y ago
  Our bank uses SFTP, which is really just SSH (nothing to do with FTP).
deleted 13y ago
[deleted]
feralmoan 13y ago
yerp, fixed width nacha files exchanged periodically over sftp. Built for/by cobol based banking systems back in the day and continues to live on.
jesusmichael 13y ago
Its actually quite secure, just a folder where a job picks up a file for processing... It doesn't have access to the ACH or banking network. The transaction still needs approval which will come from an another method, usually with strong encryption. The author probably had it this way because they did want to spend the money for a 3rd party integrator which would process the transaction via a web service. Hey I can't believe EDI is still alive but it is....
- opendais 13y ago
  ...not to count all of EDI's bastard children that are 'easier' [generally by taking out some/most of EDI's redeeming qualities]. shudders I had to implement one of those in 2014. :|
- jrochkind1 13y ago
  So the third party integrator which processed the transaction as a web service... would then turn around and drop files on an FTP server at a bank, to _actually_ make the ACH happen? I think maybe OP is essentially a third party integrator?
  - jesusmichael 13y ago
    No... 3rd parties like cybersource act just like banks from the perspective of the network and can initiate transactions. They pay big money to the financial institutions for this level of access... But from a dev perspective they provide a defacto standard for transactions across many institutions and networks
logicalmind 13y ago
I happen to work with ACH/NACHA files and send them to/from various locations. The file spec outlines that there are "control" records with various values that are supposed to be used to validate the batches in the file and the file itself to prove the file is internally consistent. I have often found that when receiving the file, these control records are hard-coded and invalid. And when sending files, some vendors don't even bother to look at the control records. It's a whole different world.
- segmondy 13y ago
  Depends on who you are working with, I worked with a Bank once that gave me crappy fails and it failed because I had a validator. The new bank I work with follows the specs strictly. So if you are getting invalid files, demand that the originator of that file fix it.
patio11 13y ago
Let me just observe that "I am not sure I need to have access to the $GUESS-test-results directory." "Yeah, of course, your stuff is in the directory next to it." "I am aware of that, but just wanted to observe, for HIPAA compliance and basic privacy reasons, you probably want to restrict access to it a bit." "Oh yeah, but that vendor's software is really wonky, so we just 777ed it to get it working." has actually happened. I was pleasantly surprised. This conversation implied that 777ing it was a considered choice, as opposed to having just happened because YOLO. This puts them much higher up the healthcare IT totem pole than you would hope.
- deleted 13y ago
  [deleted]
pjg 13y ago
No cringing. Secure-ftp is not the only security measure used in transmitting ACH files. There other measures too - including but not limited to: Checking source IP in a stateful way, Out of band confirmation by email/fax/phone, hardcoded limits and out-of-pattern detection mechanisms. I won't mentioned the specifics of some of these since this is a public forum but defrauding the ACH system by hacking into sftp is neither trivial nor scalable. Again no system is full proof but ACH fraud is typically 1/3rd of the fraud in Credit Card networks and has been the same percentage for decades.
segmondy 13y ago
Please, stop cringing. I work in this field. It's secure, I upload file to the banks SFTP, yes, Secure FTP. And the NACHA file is PGP encrypted with the bank's public key. Firewalls are in place, the bank only opens up to a specific host within our network and denies everyone access. We open up a port for only the transfering host to the banks SFTP. Their SFTP is not a regular SFTP that you can just browse. They have a folder with -wx permission. You can cd into it, place file but you can't read it. Stop cringing. Banks are not that incompetent.
- thomasmmc 13y ago
  I used to work for an ACH organization in security, as the guy who set up the credentials, submitted the firewall changes, configured the FTP server, created the PGP keys, troubleshoot connectivity, you name it, all this. I know too much about the subject and I would say "its been 5 years I'm sure they have made it better" but after spending those years there, I know that statement is false. To say it's secure is a stretch, so say it's completely unsecure is also inaccurate. There were multiple improvements I recommended to the service, but I think I only got 1 or 2 approved. Lets just say this, the front door is secure, but the once you're inside, its not so great. It's not incompetency, its just we (the security guys) are always fighting an uphill battle against change. Also, I could tell you worst stories about other services all the banks use that would make anyone cringe worst than this, some simple cross bank privilege escalation, oh yeah and the developers said thats not really going to happen... I resigned within a month of that.
  - dedward 13y ago
    I have no doubt this is true of many organisations. As the client, though - we uploaded via SFTP, the connections were IP restricted and the files were PGP encrypted. I know that doesn't address what happens after we send the bank the file - but that's not our concern, right?
    - thomasmmc 13y ago
      Access to the FTP servers are IP restricted and everything is encrypted in transit and at rest on the server via PGP. In my organization the transfers where via FTPS not SFTP, big distinction, the FTPS implementations can be not as secure by default as SFTP. But yes, once it's on the ACH processors servers it's their responsibility and not your compliance issue. They will pass an audit, but from a security point of view, they could do it better in a few areas.
PeterisP 13y ago
As the data transfer is usually implemented, sftp is okay; and actually the files might as well be sent over common email, if they're properly formed (encrypted;signed;format that doesn't allow replay attacks) - breaking that ftp server could only delay service, as you'd know that the transactions didn't go through as intended and would use a backup channel to send them.
lbarrow 13y ago
Virtually all banks run on batched FTP processes. This isn't unique to ACH at all.
dedward 13y ago
Not FTP - Secure FTP - SFTP. When I was involved with this it was SFTP for the transfer, to a write-only folder (you couldn't list contents) and the file uploaded had to be PGP encrypted with a key the bank gave us and we verified over the phone before starting the process. Even if it had been email, or plain FTP, the file was encrypted and only the bank had the key... even we couldn't decrypt it, due to the nature of Public Key encryption. Plain old FTP is not considered secure by any means, and is largely disappearing - SFTP is standard now.
- kelnos 13y ago
  Likely it's not SFTP as in the secure file transfer protocol related to SSH, but is actually http://en.wikipedia.org/wiki/FTPS http://en.wikipedia.org/wiki/FTPS
  - yanowitz 13y ago
    It's sftp in my experience. And all keys have two year expiration, which is stressful because ssh keys don't have a real expiration do they just send you an email saying "give us new keys" and you have to hope the cutover goes smoothly.
    - runlevel1 13y ago
      Slightly OT, but OpenSSH now supports the use of signed certificates, giving you the ability to expire and re-sign credentials. The feature was added recently, so I'm confident they're not using it yet.
- bostik 13y ago
  > Plain old FTP is not considered secure by any means, and is largely disappearing - SFTP is standard now. Thank $deity for that.
chirau 13y ago
> The shoemaker's children have no feet. What does this mean?
- bostik 13y ago
  It was actually a direct translation from a play's title. One I never managed to find time to see, to be honest, but wanted to. Slightly more easily recognizable version might be "the shoemaker's children have no shoes".

by bostik 13y ago

lisper 13y ago

> This made me cringe As well it should. But it gets worse. Much, much worse: http://blog.rongarret.info/2010/11/personal-banking-nightmare.html http://blog.rongarret.info/2010/11/personal-banking-nightmar... It often amazes me that the U.S. financial system works at all.

pjg 13y ago
Maybe. Here's a slightly different perspective. First take the case of ftp'ing/sftp'ing files to a bank. There are multiple layers of security in sftp - not just the username and password. Source IP is checkec in a stateful way so spoofing is hard even if one somehow manages to get the credentials. Furthermore the files will not be processed unless there is an out-of-band message (typically an email, could be a phone call too ) with certain info also required in very specific format which must match the contents of the file. So there you go. 3 layers of security with one layer being completely out-of-band with the other two is reasonable enough for the risk involved. (There are other measures hard coded e.g. a dollar limit which basically "cap" any fraud but I won't go into those) Now for the missing (or atleast MIA) transaction you allude to on your blog: Just because you were not told how the money ended up where it did doesn't mean people didn't know. Bankers are steeped in "social engineering" and trained from day one to only give out information required by law and really nothing else. Whether you use Fedwire or Swift (or really any other RTGS = real-time gross settlement network ) there is always a trail. Always. In your case it was probably Fedwire - and the bank I'm guessing was BofA or maybe Chase. Regardless if the sender's account is an individual account (not business) they are still protected by Reg E (as well as FDIC insurance). Reg E as you may know basically puts the onus of returning the funds to the sender's account on the bank. The problem is the timelines or the lack of it. Since banks are generally allowed upto 30 days (I don't know if 30 days is hardcoded ) in law they take their sweet time in tracing. And when they find out - they almost always do - they deliberately will not share details with you to protect themselves from liability. The bottom line is ACH/FedWire moves trillions of dollars - hundreds of billions a day - and barring a very small percentage they all work.
- lisper 13y ago
  > Just because you were not told how the money ended up where it did doesn't mean people didn't know. That's true, but there was a lot of additional evidence that they really didn't know: 1. They said they didn't know. 2. Two weeks passed during which they could not find the money. 3. The money was only found after the person in whose account it ended up contact me (not the bank!) And, BTW, I actually found out later how the mistake had been made: the original wire form had been filled out wrong. It was supposed to be a for-benefit-of wire, but the form was filled out as if for an intermediate-institution wire. And the bank employee who entered the data was apparently completely clueless because they entered an account number as an ABA number (or maybe it was the other way around, it was a long time ago). But it was without a doubt a total clusterfuck from beginning to end. > barring a very small percentage they all work Yes. As I said, this never ceases to amaze me.
mey 13y ago
It works primarily not because of technology but because of inter company agreements, contracts and regulations.
Stratoscope 13y ago
That's a fascinating post, especially the comment from Don Geddis: > ...I eventually reached the conclusion that "check clearing" doesn't mean anything at all. What there really is, is a web of trust among large financial institutions. They take actions which work 99% of the time, and then they have correction procedures for the 1% that fail... > ...their primary concern is that I'm not a con man who is going to take money out of the system. As long as the cash is EITHER at their bank, OR at the original bank, they can afford to not be completely sure just where it is, and to work that accounting out over time. > This system is totally unlike how computer scientists would design it. They would want guarantees that the money really was only in one place, and there would be a thing which is a "transaction", where the money reliably went from one place to another. A wire transfer is something like that, but it's really bootstrapped on old-time banking, which is a trust relationship with repair procedures, not a guarantee of freedom from error.

awda 13y ago

I don't know anything about ACH, but the author could be referring to FTP-over-TLS ("FTPS") or SFTP (unrelated protocol over SSH), both of which use the initials FTP but aren't as wholly insecure as vanilla FTP.

wiredfool 13y ago
I've seen https and scp as well. I'm not sure I've seen plain vanilla ftp in years, and certainly not without pgp encrypting the files first.
edawerd 13y ago
Our bank uses SFTP, which is really just SSH (nothing to do with FTP).

deleted 13y ago

[deleted]

feralmoan 13y ago

yerp, fixed width nacha files exchanged periodically over sftp. Built for/by cobol based banking systems back in the day and continues to live on.

jesusmichael 13y ago

Its actually quite secure, just a folder where a job picks up a file for processing... It doesn't have access to the ACH or banking network. The transaction still needs approval which will come from an another method, usually with strong encryption. The author probably had it this way because they did want to spend the money for a 3rd party integrator which would process the transaction via a web service. Hey I can't believe EDI is still alive but it is....

opendais 13y ago
...not to count all of EDI's bastard children that are 'easier' [generally by taking out some/most of EDI's redeeming qualities]. shudders I had to implement one of those in 2014. :|
jrochkind1 13y ago
So the third party integrator which processed the transaction as a web service... would then turn around and drop files on an FTP server at a bank, to _actually_ make the ACH happen? I think maybe OP is essentially a third party integrator?
- jesusmichael 13y ago
  No... 3rd parties like cybersource act just like banks from the perspective of the network and can initiate transactions. They pay big money to the financial institutions for this level of access... But from a dev perspective they provide a defacto standard for transactions across many institutions and networks

logicalmind 13y ago

I happen to work with ACH/NACHA files and send them to/from various locations. The file spec outlines that there are "control" records with various values that are supposed to be used to validate the batches in the file and the file itself to prove the file is internally consistent. I have often found that when receiving the file, these control records are hard-coded and invalid. And when sending files, some vendors don't even bother to look at the control records. It's a whole different world.

segmondy 13y ago
Depends on who you are working with, I worked with a Bank once that gave me crappy fails and it failed because I had a validator. The new bank I work with follows the specs strictly. So if you are getting invalid files, demand that the originator of that file fix it.

patio11 13y ago

Let me just observe that "I am not sure I need to have access to the $GUESS-test-results directory." "Yeah, of course, your stuff is in the directory next to it." "I am aware of that, but just wanted to observe, for HIPAA compliance and basic privacy reasons, you probably want to restrict access to it a bit." "Oh yeah, but that vendor's software is really wonky, so we just 777ed it to get it working." has actually happened. I was pleasantly surprised. This conversation implied that 777ing it was a considered choice, as opposed to having just happened because YOLO. This puts them much higher up the healthcare IT totem pole than you would hope.

deleted 13y ago
[deleted]

pjg 13y ago

No cringing. Secure-ftp is not the only security measure used in transmitting ACH files. There other measures too - including but not limited to: Checking source IP in a stateful way, Out of band confirmation by email/fax/phone, hardcoded limits and out-of-pattern detection mechanisms. I won't mentioned the specifics of some of these since this is a public forum but defrauding the ACH system by hacking into sftp is neither trivial nor scalable. Again no system is full proof but ACH fraud is typically 1/3rd of the fraud in Credit Card networks and has been the same percentage for decades.

segmondy 13y ago

Please, stop cringing. I work in this field. It's secure, I upload file to the banks SFTP, yes, Secure FTP. And the NACHA file is PGP encrypted with the bank's public key. Firewalls are in place, the bank only opens up to a specific host within our network and denies everyone access. We open up a port for only the transfering host to the banks SFTP. Their SFTP is not a regular SFTP that you can just browse. They have a folder with -wx permission. You can cd into it, place file but you can't read it. Stop cringing. Banks are not that incompetent.

thomasmmc 13y ago
I used to work for an ACH organization in security, as the guy who set up the credentials, submitted the firewall changes, configured the FTP server, created the PGP keys, troubleshoot connectivity, you name it, all this. I know too much about the subject and I would say "its been 5 years I'm sure they have made it better" but after spending those years there, I know that statement is false. To say it's secure is a stretch, so say it's completely unsecure is also inaccurate. There were multiple improvements I recommended to the service, but I think I only got 1 or 2 approved. Lets just say this, the front door is secure, but the once you're inside, its not so great. It's not incompetency, its just we (the security guys) are always fighting an uphill battle against change. Also, I could tell you worst stories about other services all the banks use that would make anyone cringe worst than this, some simple cross bank privilege escalation, oh yeah and the developers said thats not really going to happen... I resigned within a month of that.
- dedward 13y ago
  I have no doubt this is true of many organisations. As the client, though - we uploaded via SFTP, the connections were IP restricted and the files were PGP encrypted. I know that doesn't address what happens after we send the bank the file - but that's not our concern, right?
  - thomasmmc 13y ago
    Access to the FTP servers are IP restricted and everything is encrypted in transit and at rest on the server via PGP. In my organization the transfers where via FTPS not SFTP, big distinction, the FTPS implementations can be not as secure by default as SFTP. But yes, once it's on the ACH processors servers it's their responsibility and not your compliance issue. They will pass an audit, but from a security point of view, they could do it better in a few areas.

PeterisP 13y ago

As the data transfer is usually implemented, sftp is okay; and actually the files might as well be sent over common email, if they're properly formed (encrypted;signed;format that doesn't allow replay attacks) - breaking that ftp server could only delay service, as you'd know that the transactions didn't go through as intended and would use a backup channel to send them.

lbarrow 13y ago

Virtually all banks run on batched FTP processes. This isn't unique to ACH at all.

dedward 13y ago

Not FTP - Secure FTP - SFTP. When I was involved with this it was SFTP for the transfer, to a write-only folder (you couldn't list contents) and the file uploaded had to be PGP encrypted with a key the bank gave us and we verified over the phone before starting the process. Even if it had been email, or plain FTP, the file was encrypted and only the bank had the key... even we couldn't decrypt it, due to the nature of Public Key encryption. Plain old FTP is not considered secure by any means, and is largely disappearing - SFTP is standard now.

kelnos 13y ago
Likely it's not SFTP as in the secure file transfer protocol related to SSH, but is actually http://en.wikipedia.org/wiki/FTPS http://en.wikipedia.org/wiki/FTPS
- yanowitz 13y ago
  It's sftp in my experience. And all keys have two year expiration, which is stressful because ssh keys don't have a real expiration do they just send you an email saying "give us new keys" and you have to hope the cutover goes smoothly.
  - runlevel1 13y ago
    Slightly OT, but OpenSSH now supports the use of signed certificates, giving you the ability to expire and re-sign credentials. The feature was added recently, so I'm confident they're not using it yet.
bostik 13y ago
> Plain old FTP is not considered secure by any means, and is largely disappearing - SFTP is standard now. Thank $deity for that.

chirau 13y ago

> The shoemaker's children have no feet. What does this mean?

bostik 13y ago
It was actually a direct translation from a play's title. One I never managed to find time to see, to be honest, but wanted to. Slightly more easily recognizable version might be "the shoemaker's children have no shoes".