5 ms·

The fact that Linode stored the public and private keys in the same directory is strong evidence that they do not have any competence in security. Their relucta

The fact that Linode stored the public and private keys in the same directory is strong evidence that they do not have any competence in security. Their reluctance to disclose the compromise of their customer's passwords and financial data is evidence that they are not trustworthy. So on one hand we have someone who is careful enough about their finances to use disposable prepaid cards for renting a VPS. On the other, a company that doesn't understand how encryption works and had to be forced to disclose the attack by the FBI. Which do you believe?

dllthomas 13y ago
"stored the public and private keys in the same directory" People keep harping on that, but as phrased that's not a problem. Wherever you have your private key, there's no reason not to also have your public key. The issue is if the private key was living somewhere inappropriate. Consider that "public and private keys in the same directory" is exactly what happens when you run ssh-keygen on any of the typical setups; failing to then remove the public key is not any kind of a security threat.
- jmillikin 13y ago
  The entire purpose of having separate public and private keys is for the private key to be stored in a secure location. That way, when your data-writer is compromised, none of the previously written data is at risk without an additional compromise of the key bastion. If the private key is stored in the same directory, then there no effectively no additional security over simple symmetric-key encryption with a passphrase.
  - jdbernard 13y ago
    You missed dllthomas's point. The private key should never exist outside a dedicated secure location, the "key bastion" as you say. dllthoms's point was that it doesn't matter if the public key is also present in the secure location. There is no reason the keys have to be stored separately. That is orthogonal to the actual requirement that the private key is private aka. secret. In fact, the public key is public meaning it is assumed that anyone has or could gain access to it. It is purposefully published. So keeping the public key separate is meaningless. Since it is assumed that everyone has access to the public key we must assume that anyone who gains access to the private key has access to both. Ergo there is no reason to not store them both in the secure location.
    - jmillikin 13y ago
      > There is no reason the keys have to be stored > separately. That is orthogonal to the actual requirement > that the private key is private aka. secret. It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. > In fact, the public key is public meaning it is assumed > that anyone has or could gain access to it. It is > purposefully published. So keeping the private key > separate is meaningless. This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key.
      - deleted 13y ago
        [deleted]
      - icebraining 13y ago
        A public key is a file. It can be stored in more than one place. For example, you can generate both inside the key bastion, and then copy the public key to the public servers, while leaving a copy on the bastion.
        jmillikin 13y ago
        But that's not what Linode did. Linode put the private key right next to the public key, where anyone who compromised their web frontend could get at it. If they had kept their private key where it belonged, we wouldn't be having this discussion because their security alert would have said "...and we have verified that no credit card data was accessed".
        dllthomas 13y ago
        And the problem was the private key being on the server running the web front-end, and that's what should be criticized. Presence of a public key does not a webserver make.
      - raylu 13y ago
        How does storing the public key on the key bastion make it useless?
  - dllthomas 13y ago
    A private key must be stored in a secure location. Every participant in this conversation agrees on that (I would guess). The presence of the public key in that location doesn't do anything to harm security - if it did, the attacker could just bring a copy. Putting your private key where your public key belongs is bad. Leaving a copy of your public key with your private key where your private key belongs is meaningless.
    - jmillikin 13y ago
      "You are arguing that storing the public and private key in a vault under the ocean is not less secure than just storing the private key there. While that is technically true, it's also missing the point."
      - dllthomas 13y ago
        Consider someone learning their way around this stuff, but not yet well versed. They've heard people on HN talking about how "storing public key and private key together" is bad. Would you recommend they 1) move .ssh/id_dsa.pub to a different directory, or 2) make sure .ssh isn't world-readable? The issue was insecure storage of the private key - presence or absence of the public key is entirely irrelevant.
        jmillikin 13y ago
        I'd recommend they not store the private key next to the public key; that is, they shouldn't do "scp .ssh/id_dsa* remoteserver:" It doesn't matter whether there's something stored with the private key, both because that location should be secure and because the private key can used to recover the public key.
        dllthomas 13y ago
        Is the issue that you somehow believe "stored with" is not a commutative relationship? Edited to add: "It doesn't matter whether there's something stored with the private key, both because that location should be secure and because the private key can used to recover the public key." Right, it doesn't matter in what should be the overwhelming majority of cases where "the public and private key are stored in the same directory" so it's a piss-poor test for whether things are obviously being done horribly wrong.
- aioprisan 13y ago
  You must be kidding. This is encryption 101. The private key is supposed to be moved to a secure location after key generation.
  - tbrownaw 13y ago
    Er, what? I thought the keypair was supposed to be generated in a secure location (such as your 0700 mode ~/.ssh directory), and then only the public half ever leaves.
  - tailrecursion 13y ago
    twbrownaw is exactly right. If the private key is already in a secure location then there is no need to move it to a secure location. So, any report that the public keys were stored with the private keys means nothing by itself.
    - jmillikin 13y ago
      You are arguing that storing the public and private key in a vault under the ocean is not less secure than just storing the private key there. While that is technically true, it's also missing the point.
      - icebraining 13y ago
        How is it missing the point? It tells us that having "both keys in one directory" is, by itself, no evidence of insecurity by Linode.
      - deleted 13y ago
        [deleted]
  - dllthomas 13y ago
    As others have said: a private key should never be in an insecure location, or it's no longer secure. You have to generate it in a secure location, and since you're generating the key-pair, you'll have both your public and private keys in the same (secure) location until you remove the public key, which I don't see any strong reason to do.
- marshray 13y ago
  Right. The private key file format typically contains everything needed to regenerate the public key (at least the crypto parameters anyway).
- reeses 13y ago
  And if you have the private key, you can generate the public key! You should never store the private key anywhere!
  - dllthomas 13y ago
    Not even the ram of the crypto module doing the work!

dllthomas 13y ago

"stored the public and private keys in the same directory" People keep harping on that, but as phrased that's not a problem. Wherever you have your private key, there's no reason not to also have your public key. The issue is if the private key was living somewhere inappropriate. Consider that "public and private keys in the same directory" is exactly what happens when you run ssh-keygen on any of the typical setups; failing to then remove the public key is not any kind of a security threat.

jmillikin 13y ago
The entire purpose of having separate public and private keys is for the private key to be stored in a secure location. That way, when your data-writer is compromised, none of the previously written data is at risk without an additional compromise of the key bastion. If the private key is stored in the same directory, then there no effectively no additional security over simple symmetric-key encryption with a passphrase.
- jdbernard 13y ago
  You missed dllthomas's point. The private key should never exist outside a dedicated secure location, the "key bastion" as you say. dllthoms's point was that it doesn't matter if the public key is also present in the secure location. There is no reason the keys have to be stored separately. That is orthogonal to the actual requirement that the private key is private aka. secret. In fact, the public key is public meaning it is assumed that anyone has or could gain access to it. It is purposefully published. So keeping the public key separate is meaningless. Since it is assumed that everyone has access to the public key we must assume that anyone who gains access to the private key has access to both. Ergo there is no reason to not store them both in the secure location.
  - jmillikin 13y ago
    > There is no reason the keys have to be stored > separately. That is orthogonal to the actual requirement > that the private key is private aka. secret. It's effectively required to store the keys separately because if you stored the public key on the key bastion, it would be useless. > In fact, the public key is public meaning it is assumed > that anyone has or could gain access to it. It is > purposefully published. So keeping the private key > separate is meaningless. This makes no sense at all. You're saying that since the public key is public, it's safe to distribute the private key with the public key.
    - deleted 13y ago
      [deleted]
    - icebraining 13y ago
      A public key is a file. It can be stored in more than one place. For example, you can generate both inside the key bastion, and then copy the public key to the public servers, while leaving a copy on the bastion.
      - jmillikin 13y ago
        But that's not what Linode did. Linode put the private key right next to the public key, where anyone who compromised their web frontend could get at it. If they had kept their private key where it belonged, we wouldn't be having this discussion because their security alert would have said "...and we have verified that no credit card data was accessed".
        dllthomas 13y ago
        And the problem was the private key being on the server running the web front-end, and that's what should be criticized. Presence of a public key does not a webserver make.
    - raylu 13y ago
      How does storing the public key on the key bastion make it useless?
- dllthomas 13y ago
  A private key must be stored in a secure location. Every participant in this conversation agrees on that (I would guess). The presence of the public key in that location doesn't do anything to harm security - if it did, the attacker could just bring a copy. Putting your private key where your public key belongs is bad. Leaving a copy of your public key with your private key where your private key belongs is meaningless.
  - jmillikin 13y ago
    "You are arguing that storing the public and private key in a vault under the ocean is not less secure than just storing the private key there. While that is technically true, it's also missing the point."
    - dllthomas 13y ago
      Consider someone learning their way around this stuff, but not yet well versed. They've heard people on HN talking about how "storing public key and private key together" is bad. Would you recommend they 1) move .ssh/id_dsa.pub to a different directory, or 2) make sure .ssh isn't world-readable? The issue was insecure storage of the private key - presence or absence of the public key is entirely irrelevant.
      - jmillikin 13y ago
        I'd recommend they not store the private key next to the public key; that is, they shouldn't do "scp .ssh/id_dsa* remoteserver:" It doesn't matter whether there's something stored with the private key, both because that location should be secure and because the private key can used to recover the public key.
        dllthomas 13y ago
        Is the issue that you somehow believe "stored with" is not a commutative relationship? Edited to add: "It doesn't matter whether there's something stored with the private key, both because that location should be secure and because the private key can used to recover the public key." Right, it doesn't matter in what should be the overwhelming majority of cases where "the public and private key are stored in the same directory" so it's a piss-poor test for whether things are obviously being done horribly wrong.
aioprisan 13y ago
You must be kidding. This is encryption 101. The private key is supposed to be moved to a secure location after key generation.
- tbrownaw 13y ago
  Er, what? I thought the keypair was supposed to be generated in a secure location (such as your 0700 mode ~/.ssh directory), and then only the public half ever leaves.
- tailrecursion 13y ago
  twbrownaw is exactly right. If the private key is already in a secure location then there is no need to move it to a secure location. So, any report that the public keys were stored with the private keys means nothing by itself.
  - jmillikin 13y ago
    You are arguing that storing the public and private key in a vault under the ocean is not less secure than just storing the private key there. While that is technically true, it's also missing the point.
    - icebraining 13y ago
      How is it missing the point? It tells us that having "both keys in one directory" is, by itself, no evidence of insecurity by Linode.
    - deleted 13y ago
      [deleted]
- dllthomas 13y ago
  As others have said: a private key should never be in an insecure location, or it's no longer secure. You have to generate it in a secure location, and since you're generating the key-pair, you'll have both your public and private keys in the same (secure) location until you remove the public key, which I don't see any strong reason to do.
marshray 13y ago
Right. The private key file format typically contains everything needed to regenerate the public key (at least the crypto parameters anyway).
reeses 13y ago
And if you have the private key, you can generate the public key! You should never store the private key anywhere!
- dllthomas 13y ago
  Not even the ram of the crypto module doing the work!