2

I would like some advice on a method of storing passwords to a database on my anonymous FTP server.

Basically I have login details for a few trusted users to a database server stored in a text file encrypted with GnuPG. With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it.

Is there any way that anyone could gain access to the passwords stored in the text file without the permissions I have set in GnuPG? Is there anyway data could be leaked in my setup that would give it to someone without the private key?

I think it should be fine but is there anything I'm not seeing?

Jens Erat
  • 23,446
  • 12
  • 72
  • 96

1 Answers1

1

Risks of Exposing Encrypted Information

With it being encrypted I assume having it publicly accessed wouldn't affect security as the encryption setup would make it pointless for anyone to try and decrypt it.

Your encrypted information will stay private as long as

  • the crypto works (no flaws in the underlying mathematical principles are found),
  • the crypto software (GnuPG) works (no bugs in the implementation of the cryptographic algorithms) and
  • you don't perform any mistakes (for example uploading the unencrypted version by accident, or revealing the passphrase/key otherwise).

Be aware that an attacker archiving the files might be able to decrypt it well in the future if any of those incidents trigger!

In case of exchanging messages through some unsafe channel, you might (have) to accept this risks. I wouldn't accept them by publishing encrypted files if I could mitigate through additional access restrictions.

Is there any way that anyone could gain access to the passwords stored in the text file without the permissions I have set in GnuPG? Is there anyway data could be leaked in my setup that would give it to someone without the private key?

To wrap up on this: while cryptography is safe in principle (and at least no known vulnerabilities exist), things might change in future. Not publishing contents will keep this safe. Accidental disclosure of encrypted content is probably the biggest risk (and everybody including "the best" might make a mistake at some time), while access restrictions would at least add another safety net.

Metadata

Is there anyway data could be leaked in my setup that would give it to someone without the private key?

There is another point to this question: be aware that several metadata is publicly shared, which might be critical or might not be. When you change the files, their size, and if you also store it, even the name. You could mitigate some of those (for example, overprovision file size to hide size changes and not store the file name); but you especially cannot really hide file changes (even if you store faked time stamps, an attacker could simply fetch it in intervals and check for changes), the only option I see is providing "faked" changes every now and then.

Jens Erat
  • 23,446
  • 12
  • 72
  • 96
  • Thanks for the advice, really helpful! Only other thought i had was, would it be possible to remove the encrypted file and replace with an infected file? – Elliott Smelliott May 01 '16 at 12:35
  • Additionally sign the file to verify authenticity. If there is a security vulnerability in GnuPG's signature verification, this obviously would not help, either. Unlikely, but well possibly. – Jens Erat May 01 '16 at 12:37
  • Thanks :) Would this eliminate the possibility of someone replacing the file with an infected file – Elliott Smelliott May 01 '16 at 12:45
  • Obviously not, as everybody can write the file; but you can _detect_ it before doing something else with the file. Also as I already explained, if the "infected file" tries to attack some unknown vulnerability in GnuPG, signatures will not help you. – Jens Erat May 01 '16 at 13:22