On Tue, Jan 8, 2019 at 2:28 PM Jerry Draper <midrangel@xxxxxxxxxxxxx> wrote:
Our partner has specified sFTP with userid/password.
We have it working fine but the password is stored in plain text.
I think it's pretty common for client shops to just leave it like
that. I'm not saying it's best practice or anything, but if the folks
in control of the server were "serious" about not wanting login
credentials out in the open, they would be using keys, not
user/password. I think the understanding is just that you will not be
broadcasting the credentials willy-nilly. If they're sitting inside
some script, and the script isn't somewhere "too public", that might
be good enough.
I'm NOT advocating for "security through obscurity". I'm saying that
you and anyone in your team/organization might collectively be
considered the second party (with the folks controlling the server
being the first party), and the point is just to not make the
credentials available to third parties. Or maybe if the server's
security is strong enough, they might not even care if you share your
login with third parties, because you'll only be hurting yourself if
you let it leak. (What I mean is, some third party could be accessing
*your* sensitive information that you've left on the server, or
posting bad information in *your* name, so to speak.)
It's an interesting problem to think about though. For fun I made a
little home-grown obfuscator that would hide login credentials from
lay people (in other words, you couldn't just read text) but would NOT
be secure against a skilled or well-equipped malicious party. The
obfuscated credentials and de-obfuscation logic both lived in the
Python script that was doing the connecting, and I only distributed
the .pyc file, not the .py file. (You can usually see string literals
in the .pyc file, which is why I added the obfuscation.)
John Y.
midrange.com
