Live data from Hacker News

How ACH works: A developer perspective (2014)

engineering.gusto.com

171–180 of 226 posts

Re: How ACH works: A developer perspective (2014)

#171
post #45

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…

Secure FTP is actually a superset of SFTP, because there is also a FTPS protocol that is also a kind of "secure FTP".

Re: How ACH works: A developer perspective (2014)

#172

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

Probably because they can. Monzo have said they aren't going to add charges where they don't get charged themselves (such as EU payments currently).

Re: How ACH works: A developer perspective (2014)

#173
post #127
post #109

Earlier 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…

Sounds about right from my experience working at Klarna.

Re: How ACH works: A developer perspective (2014)

#174
post #138
post #125

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

So please tell me what is the difference between FTP and SFTP.

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)

#175
post #125

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

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.

Re: How ACH works: A developer perspective (2014)

#176
post #116

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

And should be noted that not anyone can receive direct debits so there still isn't a large need for secrecy of routing numbers.

Re: How ACH works: A developer perspective (2014)

#177
post #175

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

Well regarding "TSL" I'm sure you mean TLS, and it's not just an alternative to SSL, it's an evolution to SSL. SSL nowadays is considered insecure and everything is using TLS.

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)

#178

Earlier 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…

It's possible to keep an SSH key on a hardware smartcard and achieve this, no?

Re: How ACH works: A developer perspective (2014)

#179
post #50
post #45

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…

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.

That's a fair point.

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)

#180
post #45

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…

Secure FTP is actually a superset of SFTP, because there is also a FTPS protocol that is also a kind of "secure FTP".

Correct, you are. The later parts in the article, though, specifically call out SFTP by name. Based on the other comments and some searches I did before hitting that second part, I'm fairly certain they're actually using SFTP rather than FTPS, but having never actually touched the ACH system, I can't speak first-hand on that.
Post reply on HN