Frankly I'm more concerned with their words about changing credit cards if you've made a purchase through PSN. This seems to be an admission that they were storing CC#'s in plain text.
PCI requires that CC#'s are stored encrypted in the database. A service this big has had a full PCI compliance overview, and they wouldn't miss a basic requirement like that (I hope).
> How do you use stored credit card info if the cc# is not stored?
Simplifying just a bit -- The one time you pass the # along to the bank, they give you back a transaction ID you can use to do future things with that card. The bank knows the number, looks it up by that ID.
You could at least have them encrypted on disk with a key only stored in memory, i.e.: when the system is turned on. Alternatively a dedicated crypo device where you feed it cipher text and it gives you plain text would also help as the attack wouldn't be able to get the key (even if they have the physical box (for good crypto devices))
While only marginally better depending on the type of attack and permissions gained by the attacker, if all they got was static data on disk, then it would be secure.
And what if that server needs to be rebooted some day? What if there's a hardware failure and it has to be powered off?
Something as big as PSN has multiple servers reading the same DB and must be able to tolerate failures without forcing everyone to re-enter their CC #. The keys must be stored persistently somewhere.
What we do where I work is take the newly generated key whenever we key or rekey the system, split it into multiple pieces using Shamir's secret sharing algorithm, and those pieces are distributed to several people.
Whenever the server needs to be started, two of those people must enter their key shares. That enables the server to reconstruct the key, which is then stored in memory.
That wouldn't work over SSL, as there is no plain text in the HTTP Verb. And I recall a "paper" coming up some months ago that was mentioning the protocols the PS3 goes through, which does confirm that the data is transmitted over SSL.[0]
If the attacker "0wned" the servers the fact there was encryption between you and the server doesn't really help a whole lot, they can just insert them selves in the stack post encryption (or even use the private key to decrypt the encrypted traffic if they wanted to minimize the number of points they touched).
The SSL gets decrypted inside the web server process memory, at the latest. Sometimes it's stripped off by an SSL offload accelerator device before even entering the web server.
The numbers probably also cross the wire in plain text between the web server and the database too.
I don't know much about online credit card transactions, but how are you supposed to do it? Don't you need the number to transfer to Visa or whoever in order to get money out of someone's account?
Having access to a few of my passwords online has effects that range from my current to future employment, relationships with friends, partners, s.o's, future employers, all of my bank accounts, etc.
And I have better password practices than most. Credit cards might be an immediate thought, but how many other physical and intangible assets does your password give a hacker access to?
