Live data from Hacker News

How ACH works: A developer perspective (2014)

engineering.gusto.com

181–190 of 226 posts

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

#181

Earlier quoted context omitted.

why use a huge codebase like node for such a simple security critical task

How else do you suggest you standup a sftp that cannot leak data even if the password is compromised? I'm all ears. Node is a runtime by the way and huge in what regard? The Linux codebase is also large.

It is a system administration problem, not write a new software problem.

You:

a) think about the scope of the problem and what you are trying to achive - you are blocking reads of the files by the uid/gid of the server. It is a known and solved problem. The tool is called chmod

b) think about the surface area of the attack - it should only be the SFTP server. We have ones that are very well known. I recommend the one that comes with OpenSSH but there are others.

c) think about business requirements - user's provisioning etc. That has been a solved problem for years - for the super-complex cases LDAP is used. For the simpler ones you can use PAM.

After thinking about that you just write the needed glue.

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

#182

Going from the UK to the US was like stepping back in time when it came to banking. I remember complaining about some aspects of UK banking - it's going to take a day for my transfer to complete!?! Now we have faster payments in the UK which complete in hours at most. Meanwhile in the US I still had to pay my rent with a physical check because that was easier than figuring out the weird 'pay anyone' implementation my…

Your property management doesn't provide a way to pay online?

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

#183
post #174
post #138

Earlier quoted context omitted.

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?

It's not, SFTP is a binary protocol using SSH as transport layer. FTPS is plain old FTP over SSL/TLS. They're completely different protocols that have nothing in common except being used to transfer files.

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

#184
post #75
post #57

Earlier quoted context omitted.

Is it sftp or ftps? They're very different things and I am fairly certain it's the latter.

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

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

#185
post #175

Earlier quoted context omitted.

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.

> Well regarding "TSL" I'm sure you mean TLS

that is correct. That was my typo :(

> SFTP is a completely new protocol based on SSH.

If that is the case please explain the following scenario.

I wrote an editor that had FTP capabilities but it was based on the FTP RFC 913 specification using nothing but plain old sockets.

As a result, many user loved the FTP feature, but they asked for a version that would work over the SFTP protocol.

So I implemented an SFTP version of that editor by using OpenSLL to create a SSL socket. The editor just created a secure socket, but used the exact same FTP RFC 913 specification to talk to the server using that socket.

Ever user who asked for this change reported that it now worked perfectly with their SFTP (not TLS) server.

So how is that possible that my editor could implement the SFTP protocol with just a change to the way the socket was opened?

PS: If you don't believe me, you can trial that exact same SFTP (OpenSSL) editor from the link below and I'm pretty sure you'll find it still works with an SFTP server: http://www.zeusedit.com/download.html

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

#186
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…

For confirmation, SFTP is mentioned directly (at least once) in the second article of the series.

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

#188

Earlier quoted context omitted.

Seconding what kalleboo said, setting directory permissions has been a staple of file-sharing for decades. Setting up a node server to block read-access seems incredibly byzantine.

Good point but we also have to load balance this / have failover and provision users on the fly. I could have used messaging queues to provision PAM users on the whole cluster and this guy would have still complained because I used a non standard port. Not sure why that was a problem either but again we can't press back or question him. he would cancel the whole integration. Bottom line is our end user wanted real ti…

> we can't press back or question him. he would cancel the whole integration

This attitude will not serve you well. There's saying no, and then there's getting more information (requirements!?!) to then guide people to better decisions.

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

#189
post #174

Earlier quoted context omitted.

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?

It's not, SFTP is a binary protocol using SSH as transport layer. FTPS is plain old FTP over SSL/TLS. They're completely different protocols that have nothing in common except being used to transfer files.

Who knows if this link is accurate:

https://en.wikipedia.org/wiki/File_Transfer_Protocol

But it says:

SSH File Transfer Protocol

The SSH file transfer protocol (chronologically the second of the two protocols abbreviated SFTP) transfers files and has a similar command set for users, but uses the Secure Shell protocol (SSH) to transfer files. Unlike FTP, it encrypts both commands and data, preventing passwords and sensitive information from being transmitted openly over the network. It cannot interoperate with FTP software.

This suggestion this term chronologically the second of the two protocols abbreviated SFTP is duplicitous.

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

#190
post #185

Earlier quoted context omitted.

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.

> Well regarding "TSL" I'm sure you mean TLS that is correct. That was my typo :( > SFTP is a completely new protocol based on SSH. If that is the case please explain the following scenario. I wrote an editor that had FTP capabilities but it was based on the FTP RFC 913 specification using nothing but plain old sockets. As a result, many user loved the FTP feature, but they asked for a version that would work over th…

Maybe your customer mistook their SFTP server for an FTPS server? I'm afraid I don't have a Windows machine to test your software on, but if you're curious I encourage you to set up an SSH server like OpenSSH (which provides SFTP as well) and try with that. I'd be really surprised if your FTPS implementation managed to work with it (unless OpenSSH's SFTP implements an FTPS fallback).
Post reply on HN