Live data from Hacker News

If you didn't cancel the credit card you used for linode.com, now is the time

news.ycombinator.com

71–80 of 138 posts

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#71

Signing up for on-line services is a good use for "virtual account numbers". This is a feature offered on some Citibank and Discover credit cards (maybe others) that allows you to generate a separate credit card number that's billed to your original account. The nice thing about them is that once a virtual account number has been billed by a vendor, it does not accept any charges in the future except from the same ve…

I've got an account with Bank of America and they have that feature as well.

Downside, none of their service reps even know it exists, even worse they are slowly phasing it out (making it more and more difficult to find) even-though it is a feature I absolutely love.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#72
post #37

Please provide a little more evidence than starting a flame war. Although it could in theory be true, it's a fairly baseless claim until you present a little more evidence. For my online transactions I use prepaid cards that are easy to dispose of, and this card was used solely for linode. Couldn't the online card issuer be to blame? How do we know you haven't mistakenly used it for anything else? The fact that you u…

I'm with you.

This post strikes me as nothing more than fear groundless fear mongering.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#73

Earlier quoted context omitted.

"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;…

You must be kidding. This is encryption 101. The private key is supposed to be moved to a secure location after key generation.

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.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#74
post #69
post #64

Earlier quoted context omitted.

Your balance is irrelevant - your available credit line is debt, as at any moment you can be liable for up to that amount.

If I have a $10,000 credit limit and $0 balance, my debt is $10,000? At any moment I can be liable for up to $10,000? How does that work?

How does that work?

It doesn't. The GP comment is FUD.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#75
Do you use Windows? If so, you are infected with Malware that stole your card number and it finally got used.

I don't know why this is getting downvoted. This is a perfectly valid explanation for why your card got charged that contradicts your reasoning that Linode's encrypted card database got cracked.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#77

Earlier quoted context omitted.

"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;…

You must be kidding. This is encryption 101. The private key is supposed to be moved to a secure location after key generation.

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.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#78

Earlier quoted context omitted.

You must be kidding. This is encryption 101. The private key is supposed to be moved to a secure location after key generation.

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.

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.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#79

Earlier quoted context omitted.

"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;…

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 passphr…

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.

Re: If you didn't cancel the credit card you used for linode.com, now is the time

#80

Earlier quoted context omitted.

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 passphr…

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 mean…

  > 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.
Post reply on HN