101–110 of 138 posts
Earlier quoted context omitted.
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?
If you're uninsured in the US and break your leg, yes, your debt is now $10,000.
Linode stored the encrypted credit card numbers in our [linode's] database ... we have no evidence decrypted credit card numbers were obtained . [1] To me, this implies that the attackers did indeed get the encrypted data. This would be a mighty juicy target to focus your decryption efforts on! In my mind, it was only a matter of time. Regardless of whether OP's story holds water.. get your card re-issued if this app…
In practice, either the Linode data was properly encrypted and keys properly managed, or it wasn't, rendering the encryption worthless. There's very little middle ground.
If you can break properly encrypted data, you have way bigger opportunities than carding.
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.
Your explanation is certainly possible, but it doesn't contradict the Linode explanation. You might say that the former is much more likely than the latter, but that doesn't rule linode out.
Earlier quoted context omitted.
If you're uninsured in the US and break your leg, yes, your debt is now $10,000.
Or much higher, but this is unrelated to credit cards.
Earlier quoted context omitted.
> 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 publishe…
How does storing the public key on the key bastion make it useless?
Earlier quoted context omitted.
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 publishe…
Thanks, I was thankfully canceled my card. Is there anyone else here that has had their card compromised?
Earlier quoted context omitted.
> 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 publishe…
I think you are not talking about the same thing that the rest of us are talking about. I see three locations or context involved: 1. The public area - meaning anyone has access. 2. The application context (server, etc) -- should be a "secured" location, meaning few people or processes have legitimate access, and measures should be taken to prevent unauthorized access. The private key should never be present in locat…
> The typical assumption in most scenarios is that context
> 2 is secure, and by that I mean secure enough to house
> the private key.
> I am saying that anyone who has access to the private
> key also has access to the public key, so there is no
> reason not to store them together in the secure location
It doesn't matter if someone can derive the public key from the private key. That's not what's being argued here. The problem is that there is a place where the public key was stored, and Linode also stored the private key there, which is insane.
Earlier quoted context omitted.
How does that work? It doesn't. The GP comment is FUD.
It is, however, an element of your credit score.