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 archaic, but takes the headline's shock value down a small peg[1].
[0] It adds a mental pause -- a Secure ... FTP server. It hints that, possibly, it's a reference to a different aspect of the server's security (a non-technical person might refer to a server as being a "secure" server simply because it's protected by an ID and password, for instance).
[1] Based on my personal interaction with banks and software, as well as several friends who had previously been members of a few banks' IT departments, my first -- very sarcastic thought -- was "of course it works that way!"
My first job in 2005 was to take over an ACH processing system that was written for our company. It was all in Perl. :-P
ACH format is super weird .. tons of lines with 99999 on them as separators. And yes, we had to go through a bank to do any ACH transactions. They shipped us a router that setup an IPSec tunnel and it had a backup ISDN connection on it as well.
I wish ACH was more accessible. In many other countries, you give people your Name, Bank and Account number (Australia: BSB + Acct, NZ: it's one big number) and people can just send you money. Appears the next day, even on holidays. In the US we still have to photo checks with a phone app? WTF? I wrote a thing about our banking system here:
As an American expat living in a developing country it seems very weird to me how backwards the US ACH system is. Where I live now it's the same as the countries you mentioned, anyone can send money to your bank account using just the account number. And it appears in minutes. The banks even offer you an SMS alert when founds arrive and the sender can elect to send an SMS to alert the receiver to check their account for the received funds. Everyone uses it, including many (most?) businesses.
From what I understand, the desire for instantaneous transactions is has an inverse relation with how much money you have. Poorer countries are generally way, way ahead in mobile banking, because in a rich country you are supposed to keep around a month's salary in all your accounts, making transfers less urgent.
The way I understand it, it's a coordination issue - the bigger a market is, the longer it takes for a big change to be adopted by everyone.
Plausible stories are easy to make up. Lots of countries - probably most - with higher GDP per capita than the US have lower latency banking. The US has a large proportion of people who are worse off than the equivalents in many poorer countries, too.
Your perspective describes the underlying issue much clearly than those who talk about "leapfrogging".
The newer platforms (like mobile banking) were adopted in those (poorer) markets because they were cheaper to deploy relative to the technology that preceeded them, and perhaps more importantly, they had less inertia to overcome (against entrenched interests).
That, and how much existing infrastructure there is.
Many places leapfrogged directly to mobile phones (featurephones mostly) because there were little to no power and/or landline wiring present (and attempts at getting such infrastructure in place got disrupted by people stealing the wiring and selling it as scrap copper).
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 are tranfering money between the banks at one (or maybe a few) standard clearing runs involving the Riksbank, that works more or less like ACH. I think all of them are scheduled in the morning.
All Swedish banks are working onreplacing the payment infrastructure (the clearing. ) It's supposed to be finished in 2024 or something like that.
The major US banks created clearXchange to solve this problem, which was later sold and now rebranded to Zelle. It's near-instantaneous transfers for supported banks, and only needs a phone number or email address. (I think it's quaint in comparison that you need to give out your bank account number for other systems. Holding of account numbers is exactly the problem that modern mobile wallets worked so hard to solve with tokenization.)
The difference is, however, that you can assign a bank account a number that is unique within a given banking system.
Once you move into the realm of trying to tie an identifier you have no control over (and that has no reliable verification method for) to a place where money will go, you open yourself up to a smorgasbord of potential attack vectors, confusions and edge cases.
Bank account numbers are not unique across banks. Account number schemes aren't even uniform across banks. The only limitation is what fits within the ACH system. You need the combination of routing number (to identify the bank) and account number (to identify the individual within the bank).
Zelle associates the bank account to a email address and / or phone number. Creation of these associations is gated through the member banks. So you have all the controls you have for any other banking task.
You'll note of course that I said "banking system," and I said "you can assign a bank account a unique identifier." i.e. I can create a scheme where I can map a particular account to a globally unique number, with rules about who owns which ranges etc.
So if Alice provides Bob a globally unique identifier to their bank account, then that's where it's going.
If Alice gives Bob a token that is hopefully mapped to the account, then there's an additional layer that can go wrong.
Eve can compromise Alice's e-mail or phone number, and then try and convince their bank that their bank account should now be associated with that identifier. If it's a different bank, then presumably this request must be federated through the third party system. And hopefully the 'true' owner is not identified by sending an e-mail or SMS.
Or maybe Eve just creates a bunch of accounts and tries to associate them with a bunch of telephone numbers and e-mail addresses that she can compromise at will and waits for the money to roll in. This is obviously more likely if some people have more than one account, as it means that the mapping of account -> e-mail/phone no. can no longer be mandatory.
In your example it sounds like they've got some reasonable safeguards in place (like ensuring you have to de-register a mapping before you can register a new one), the only point I was trying to make is that yes, it can be done, but to be done safely it's much harder than just simply having an account number (including routing number/sort code/swift code etc.).
You lose the 1-1 mapping and it gives you yet another thing that you have to actively manage/remember how it's set up/remember to change when you change e-mail provider or your phone number changes.
It's a 1:1 association. When I changed banks and tried to sign up online, it kept giving me an error. I stopped by a branch, and my old bank had registered me at some point. The teller had to call support and remove my previous association before they could create the new one.
Also, the association is to receive, not to send. Sending is initiated by your bank, which obviously already knows your account number. You send from your bank account to an email or phone number, which Zelle then translates to the target bank account.
The weirdness is historical. The '9'*94 padding and the line lengths are basically holdovers from when the ACH format was constrained by the capacity of 9 track tapes.
In most of Europe (UK and IE are one exception still using SWIFT) you just need the IBAN (international bank account number). In a lot of cases the payment is instant, even between countries, and free.
Unlike the US the bank account number shouldn't be guarded with your life, so businesses often have it listed on their website.
its still not impelemnted everywhere, in croatia the exchange between banks is happening twice a day, i believe at 12h and 17h.
alot of people here dont like to buy stuff with CC so they transfer the money with internet banking, and also get a discount because that is treated as cash, and if the webshop is with another bank you have to wait to get a confirmation they received the money, or can try to send them transaction confirmation in PDF.
sometimes its anoying when you are ordering something expenensive and have to wait a bit longer because only after your payment do they order it from the distributor.
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.
I phoned up my bank and asked them how they calculate their fees and the exchange rate on foreign transactions. Needless to say, they couldn't give me an answer.
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.
SFTP tends to be the go-to method of integrating software between organizations, especially ones that aren't used to building actual APIs. It's standardized, everyone knows how to use it, and it essentially boils down to: generate a file and upload it to a server. There's all sorts of problems with it, and it tends to be a pretty short sighted decision.
The biggest problem I've found is that there's no real feedback loop (for this class of integration, not sftp specific). Company A uploads a file -- often in the middle of the night -- and Company B processes that file some time later. Could be a minute, could be a day. Company B fails to process the file, possibly because of a change on their end, possibly because of a change on Company A's end. There's usually a bunch of back and forth, but ultimately the earliest you can determine if a fix works is a full 24 hours after the file was initially dropped. Both companies could create integration environments with shorter feedback loops to help, but ultimately its a problem of not getting an immediate response that the integration is working.
95% of my job involves writing software to integrate systems from different companies, and the integrations that involve SFTP are almost always the biggest pains. I've thought about writing an SFTP server that operated in real time, and either rejected bad files or had some other way of responding to the inputs. Never really found the time to do it, and ultimately it'd be patching a process that should have just been a well designed API from the start.
I was just going to say, working for one of the largest destributors in the world, this is still how many large corps buy stuff: by downloading a catalog through FTP and sending the order with XML. I know, shocking but not everyone is Amazon.
Amazon Vendor Central only has support for EDI (at least in the UK) - as in EDIFACT files sent over FTP.
If you want to do business with them you either need to talk that or be comfortable farming out to a 3rd party (I'm 1 day into a project where I'm finding all this out, and the hell of EDI file formats).
Most payment vendors are on SFTP at this point. Very few still use only FTPS. But then they do silly things with SFTP, like requiring both a password and the ssh key.
In the past I've done the same things, as some have mentioned already, as a form of two-factor authentication.
There were a few reasons for this that made a lot of sense:
(1) Private keys were being stored haphazardly -- people were not protecting them with passwords and occasionally they ended up on network drives. It's possible to enforce password policies for the hosts in question, but not possible to enforce 'how you protect/handle your private key' centrally[0].
(2) The second only applied to an environment I managed in the past, but we had many Linux hosts that were AD domain joined and authentication occurred directly via AD credentials (no local account authentication). The servers were configured to allow password-only login when the user had never connected to the host before. Once the user had connected the first time, the host would receive the public key for that user and future logins would only require the key[0].
[0] ... that latter part they failed to ever get working properly. It always prompted for both. Based on my conversations with the team managing the servers, there was zero priority assigned to fixing that problem -- they were resentful of the fact that the Linux (Debian, incidentally) hosts were domain joined and allowed domain authentication and they had a poor opinion of the security of using AD user accounts for authentication (nobody would make an argument other than Micro == small, soft == not hard or some other snark like that -- we had some BOFH over there).
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 that connections /must/ route through a given location would be enough.
"If you can duplicate it, then it's something you know, not something you have."
By this logic, a typical door key is "something you know" rather than "something you have" (never mind the uselessness of memorizing one's key shape when it comes to actually unlocking a door).
Unless you're memorizing your private SSH keys (in which case I applaud your superior intellect), it's absurd to claim that said keys fall into "something you know".
It's a key pair, for SSH keys, which is what SFTP uses to tunnel the FTP protocol. You cannot derive the private key from the public key. So no, you cannot duplicate someone's private key unless you have access to their machine. In which case you could just install a keylogger.
Hardware tokens are vulnerable too, by your own admission. A 6 digit pin created by a token is still "something you know" even if it's only good for a couple of minutes.
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.
I've written an SFTP server (nodejs) that passes the files to the proper API this summer. No magic there and the user who doesn't have the resources to implement an API client is happy.
I came to ask the same question, I followed the comments link on the tfa and notice it linked back to HN 1200 days ago and that was one of the top questions.
not necessarily SFTP, always FTP in some form in the US. I have seen FTPS, I have also seen banks just use FTP by default without encryption (shocking? not really).
It's still plenty archaic, but takes the headline's shock value down a small peg[1].
[0] It adds a mental pause -- a Secure ... FTP server. It hints that, possibly, it's a reference to a different aspect of the server's security (a non-technical person might refer to a server as being a "secure" server simply because it's protected by an ID and password, for instance).
[1] Based on my personal interaction with banks and software, as well as several friends who had previously been members of a few banks' IT departments, my first -- very sarcastic thought -- was "of course it works that way!"