I noticed a few comments specifically referencing FTP (and who can blame them since the HN title as of this moment specifically references it). In the first post of the series, the author refers to the server as a "Secure FTP" server, which can be confusing to read[0]. In later parts (and a little googling of my own), it's clear that the server is actually an SFTP server, not a plain-old FTP server. It's still plenty…
How ACH works: A developer perspective (2014)
171–180 of 226 posts
Re: How ACH works: A developer perspective (2014)
#172Earlier quoted context omitted.
Faster payments was mandated by the European Payment Services Directive. All European countries have it. Up next: Payment Services Directive 2 - API access to bank accounts. This is going to be interesting.
Any idea why the UK is still allowed to charge so much for outgoing Euro payments? It's reduced a lot, but my UK bank still charges £9 + their poor exchange rate.
Re: How ACH works: A developer perspective (2014)
#173Earlier quoted context omitted.
Swish in Sweden?
Swish allows to send using an arbitrary number (phone or arbitrarily assigned) rather than an actual account number. It's also credits the recipient immediately. That's possible since all the participating banks have deposited a number of billions in a mutual fund designed to cover the losses in the case one of the banks runs out of money, and also probably by having an internal account to debit during the day. They…
Re: How ACH works: A developer perspective (2014)
#174Earlier quoted context omitted.
SFTP is the FTP protocol running through a SSL socket where as FTP is the FTP protocol running through a plain old socket. So they do have a lot in common.
You are confusing SFTP and FTPS there.
But before we start to discuss that point lets at least agree SFTP is some sort of FTP protocol over SSL?
Re: How ACH works: A developer perspective (2014)
#175Earlier quoted context omitted.
SFTP is the FTP protocol running through a SSL socket where as FTP is the FTP protocol running through a plain old socket. So they do have a lot in common.
FTPS is a protocol (FTP) running through an SSL socket. SFTP is totally different and based on SSH.
EDIT: I think you will find FTPS is based on TSL not SSL. TSL is an alternative to SSL.
Re: How ACH works: A developer perspective (2014)
#176Earlier quoted context omitted.
It's also a "push" system (and not a "pull" system like ACH) which has serious advantages -- you can send money to anyone given their sort code and account number, and those numbers do not need to be kept private. With ACH if you have someone's routing number and account number you can pull money from their account without them needing to authorise it.
In the UK there is also a 'pull' system (Direct Debit) in which you instruct your bank that a given third party can regularly take money out of your account until further notice. It's commonplace for bill payments, subscription services, etc.
Re: How ACH works: A developer perspective (2014)
#177Earlier quoted context omitted.
FTPS is a protocol (FTP) running through an SSL socket. SFTP is totally different and based on SSH.
If you look at my post I did not say SSH I said SSL. EDIT: I think you will find FTPS is based on TSL not SSL. TSL is an alternative to SSL.
About the SFTP vs FTPS, SFTP is a completely new protocol based on SSH. FTPS is the plain old FTP wrapped in a TLS/SSL socket.
Re: How ACH works: A developer perspective (2014)
#178Earlier quoted context omitted.
"like requiring both a password and the ssh key." That doesn't sound that unreasonable. Both satisfy the "something you know" and "something you have" portions of multi-factor authentication (respectively). Considering that this is money on the line, the idea of banks actually taking security seriously is actually refreshing. Too bad they don't seem to apply those standards to their customers.
If you can duplicate it, then it's something you know, not something you have. Everything you know in sum-total is one meta-passphrase, even if it's a combination of key-files and other data. The 'something you have' would have to be a specific hardware token (E.G. that VPN tunnel device someone else mentioned that is a black box you aren't allowed to open). Tamper resistance and physical security locks to ensure tha…
Re: How ACH works: A developer perspective (2014)
#179I noticed a few comments specifically referencing FTP (and who can blame them since the HN title as of this moment specifically references it). In the first post of the series, the author refers to the server as a "Secure FTP" server, which can be confusing to read[0]. In later parts (and a little googling of my own), it's clear that the server is actually an SFTP server, not a plain-old FTP server. It's still plenty…
Even calling it archaic is too harsh. Granted, the batch-centric nature is not ideal (and it's hard to imagine a system with this kind of latency built in being designed today), but if you're designing a system based on batch processing then shipping files over SFTP is a pretty reasonable way to do it.
It's very easy to get stuck inside the developer bubble, where 'archaic' means 'something that was state-of-the-art four years ago (or in the web/design world, 3.5 minutes ago)'.
SFTP is a nice technology which I make quite frequent use of in my job and at home. The idea that I plug in my Yubikey, provide a passphrase to unlock the key, authenticate to my server which that's got a verifiable certificate installed, and the private key never leaves my Yubikey is about as state-of-the-art as I could ever ask for security-wise.
Granted, precisely how the SFTP site is secured isn't specified and there's plenty of ways to do that wrong, but as a technology, it's always impressed me how seamlessly it works once it's setup.
Re: How ACH works: A developer perspective (2014)
#180I noticed a few comments specifically referencing FTP (and who can blame them since the HN title as of this moment specifically references it). In the first post of the series, the author refers to the server as a "Secure FTP" server, which can be confusing to read[0]. In later parts (and a little googling of my own), it's clear that the server is actually an SFTP server, not a plain-old FTP server. It's still plenty…
Secure FTP is actually a superset of SFTP, because there is also a FTPS protocol that is also a kind of "secure FTP".