3 ms·

> Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. Best practice is to avoid storing secrets in plaintext, or sha

by rdancer 10y ago

> Saying you shouldn't store it in git seems rather like saying you shouldn't store it in btrfs. Best practice is to avoid storing secrets in plaintext, or sharing secrets between users/roles. Yours isn't an argument in favour of git, it is an argument against btrfs. (I don't have any problem with storing passwords in that way, I'm just pointing out why it's not the best practice.)

geofft 10y ago
> Best practice is to avoid storing secrets in plaintext How do you store them, then? If they're encrypted with a password, how do you store that secret? I'm pretty sure best practice is in fact to store things like SSL private keys, cookie HMAC secrets (e.g. Django's SECRET_KEY), and so forth on local disk unencrypted, protected by only filesystem permissions (and the host OS as a whole protected with standard means). In fact I'm not even sure it's possible to store OpenSSH private keys unencrypted. > or sharing secrets between users/roles. There's only one role here: the application that has an API key. There are multiple developers of that application, and possibly multiple instances of that application, but it's a single role.
- nhaehnle 10y ago
  OpenSSH client private keys can be stored encrypted - that's what ssh-agent is for: it allows you to enter the key passphrase only once and then remember it for the rest of your desktop session. OpenSSH server private keys, on the other hand - I don't think that makes a whole lot of sense. Unless you have a threat model that forces you to encrypt the entire server disk, but then adding private key encryption on top of that doesn't make much sense either.
  - geofft 10y ago
    Right, exactly. (I did mean to say "server", thanks.) It sounds like the secrets in question are essentially analogous to OpenSSH private keys: they allow a server / service to prove its own identity to others, and the servers should be able to launch automatically at boot so there's not a reasonable place to enter a passphrase.
- rdancer 10y ago
  TPM. It's just one role, but multiple users.
  - geofft 10y ago
    Do you have any tools you recommend for that? I love TPMs, but this seems wildly impractical for a small project with developers who aren't excited about becoming TPM experts. Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)
    - rdancer 10y ago
      There are dedicated discrete HSMs that can be installed. That's what I would do. Or, rather, wouldn't. I agree with you that it would be very impractical, unless the platform has a first-class API: Chrome OS uses TPM heavily[1], and iOS has the Security Enclave. The standard TPM API is PKCS#11, so any hardware that speaks it can be used with any software that speaks it. Problem with TPM is that the whole hardware and software stack needs to be secure, which in practice means it needs to be designed top-down with awareness of the TPM, and audited. The secrets must not be cached, written to file system, kept in memory, leaked over network. There are implementations such as Trousers[2], but it's more or less just a proof of concept; it may provide additional security, but most likely you're just using a very complex lock, and leaving the key under the mat. [1] https://www.chromium.org/developers/design-documents/tpm-usage#TOC-Protecting-Certain-User-RSA-Keys https://www.chromium.org/developers/design-documents/tpm-usa... [2] http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.html http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.htm...

by rdancer 10y ago

geofft 10y ago

> Best practice is to avoid storing secrets in plaintext How do you store them, then? If they're encrypted with a password, how do you store that secret? I'm pretty sure best practice is in fact to store things like SSL private keys, cookie HMAC secrets (e.g. Django's SECRET_KEY), and so forth on local disk unencrypted, protected by only filesystem permissions (and the host OS as a whole protected with standard means). In fact I'm not even sure it's possible to store OpenSSH private keys unencrypted. > or sharing secrets between users/roles. There's only one role here: the application that has an API key. There are multiple developers of that application, and possibly multiple instances of that application, but it's a single role.

nhaehnle 10y ago
OpenSSH client private keys can be stored encrypted - that's what ssh-agent is for: it allows you to enter the key passphrase only once and then remember it for the rest of your desktop session. OpenSSH server private keys, on the other hand - I don't think that makes a whole lot of sense. Unless you have a threat model that forces you to encrypt the entire server disk, but then adding private key encryption on top of that doesn't make much sense either.
- geofft 10y ago
  Right, exactly. (I did mean to say "server", thanks.) It sounds like the secrets in question are essentially analogous to OpenSSH private keys: they allow a server / service to prove its own identity to others, and the servers should be able to launch automatically at boot so there's not a reasonable place to enter a passphrase.
rdancer 10y ago
TPM. It's just one role, but multiple users.
- geofft 10y ago
  Do you have any tools you recommend for that? I love TPMs, but this seems wildly impractical for a small project with developers who aren't excited about becoming TPM experts. Also, does this rule out hosting on clouds that don't offer vTPM support? (Are there any that do?)
  - rdancer 10y ago
    There are dedicated discrete HSMs that can be installed. That's what I would do. Or, rather, wouldn't. I agree with you that it would be very impractical, unless the platform has a first-class API: Chrome OS uses TPM heavily[1], and iOS has the Security Enclave. The standard TPM API is PKCS#11, so any hardware that speaks it can be used with any software that speaks it. Problem with TPM is that the whole hardware and software stack needs to be secure, which in practice means it needs to be designed top-down with awareness of the TPM, and audited. The secrets must not be cached, written to file system, kept in memory, leaked over network. There are implementations such as Trousers[2], but it's more or less just a proof of concept; it may provide additional security, but most likely you're just using a very complex lock, and leaving the key under the mat. [1] https://www.chromium.org/developers/design-documents/tpm-usage#TOC-Protecting-Certain-User-RSA-Keys https://www.chromium.org/developers/design-documents/tpm-usa... [2] http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.html http://trousers.sourceforge.net/man/tpmtoken_setpasswd.1.htm...