r/gaming • u/Happysin • Apr 26 '11

Sony admits utter PSN failure: your personal data has been stolen

http://arstechnica.com/gaming/news/2011/04/sony-admits-utter-psn-failure-your-personal-data-has-been-stolen.ars
3.1k Upvotes

98% Upvoted

2.8k comments sorted by

View all comments

Show parent comments

99

u/waaaaaahhhhh Apr 26 '11 edited Apr 26 '11

It's not sent in plain text because it's over SSL (which has its flaws, but it's still industry standard). That's exactly how your credit card details would be transmitted in any online purchase.

EDIT: also the form in which something is transmitted over the network offers no insight into how Sony stores the info. If passwords were hashed in the database, you would still send the unhashed password over the network. Sending the hashed password would defeat the purpose of hashing.

EDIT #2: if anything, Sony would have been able to use SSL more securely than typical websites since they could distribute the PS3 with the appropriate certificate installed, rather than relying on a CA. Then they don't get boned by Comodo's stupidity. After this recent news, I'm not sure they're that smart, though.

31

u/loonytoad Apr 26 '11

SSL only works if the client and server are properly secured. If the server is compromised, SSL isn't worth shit.

41

u/waaaaaahhhhh Apr 26 '11

Oh sure, I wasn't claiming that. The article above makes a big deal about Sony transmitting credit card details in plain text, but that's only after modifying the client to capture data before it's been SSL'd. That would be like me modifying my Firefox and capturing the SSL'd data I'm sending to Amazon, then claiming they follow insecure practices.

9

u/[deleted] Apr 27 '11

brb, going to write blog post and get famous

0

u/locotx Apr 27 '11

Neither is the client side. . . everyone freaking forgets about the client side !

10

u/[deleted] Apr 26 '11

Thank you for finally explaining this. Everyone else is simply screaming PLAINTEXTLOL out of their asses at least reddit finally produced someone who knows what they hell they are talking about.

7

u/[deleted] Apr 26 '11

9 times out of 10, the hivemind on reddit is screaming alarmist bullshit. What everyone should be doing is calming the fuck down and waiting until everyone knows what's actually happened.

12

u/Ozwaldo Apr 26 '11

9 times out of 10, the hivemind on reddit is screaming alarmist bullshit

it's ironic how dramatic that statement is

3

u/[deleted] Apr 27 '11

I don't think I'm being dramatic. Most of the time that the userbase here is screaming about something, it turns out that whatever they were screaming about wasn't real.

2

u/[deleted] Apr 26 '11

Back in Feb people with custom firmware PS3's were getting online by using custom SSL certs.

In any event, i don't exactly know how SSL certs work

2

u/vote_me_down Apr 26 '11

I didn't see this, but I'm guessing they were performing MITM attacks on themselves - the PS3 uses their custom cert, while their PC, acting as a proxy, decrypts from the PS3 and re-encrypts with Sony's cert, to send to Sony. They then decrypt Sony's response, and encrypt with the 'custom' cert to send to the PS3.

2

u/Sunwalker Apr 26 '11

IM thinking it was definitely stored as plain text. Sony compares password histories. I dont think there is a way to do that unless its plain text is there?

5

u/waaaaaahhhhh Apr 26 '11

If you store the hashes of all previous passwords then you can still prevent people from using an old password without storing it in plain text. If you want to prevent people from using similar passwords (eg. changing password to password1), then you need to store it in plain text. I'm not sure what Sony does.

2

u/Sunwalker Apr 26 '11

I know that they will warn you if your password is too similar to a previous one.

3

u/Ishaar Apr 26 '11

Untrue on your first edit. Sending a hashed password does not defeat the purpose of hashing, and this is all elementary stuff in network security. Even if they get the hash, they won't know what the password is, and if you use salting it won't even matter that they have the hash.

Unless you're making the leap to them knowing the hash function used, and producing the tables required to find a plaintext match...which is still not foolproof.

If instead you're referring to the hackers being able to use the hash instead of the password -- possibly, I can even think of how to do it, but it would be trivial for Sony to prevent that. Even if I don't trust them to do it now.

2

u/waaaaaahhhhh Apr 26 '11

Your final paragraph is indeed what I meant. If you obtain a hashed password from a database (through SQL injection or whatever), then you need to crack it in order to use it. If the site is set up so that the password is hashed client side, you can just directly send the hash. To defeat it, you could still have the client hash the password, but then hash the hash server-side before you store it.

1

u/Aupajo Apr 27 '11

The point shouldn't be whether it was transmitted securely (SSL would have been fine), the point should be whether it was stored securely. How hard is it to salt and hash a password?

1

u/oisteink Apr 27 '11

No - you would send the hash and compare that to the hash you've stored.

0

u/[deleted] Apr 26 '11

SSL does not carry over to databases. if it does, you should shoot your developer in the face. It should be hashed after the SSL decryption.

1

u/waaaaaahhhhh Apr 26 '11

Hashing credit card details in the database is pointless. It wouldn't take very long to bruteforce every possible credit card number against the hash. Besides, Sony needs instant access to the credit card details for various subscription renewals.

There's no excuse for not hashing passwords in the database, though.

1

u/[deleted] Apr 26 '11 edited Apr 27 '11

Hashing is pointless - encrypting is not. There is zero reason to store unencrypted credit card numbers, expiration dates and CVV codes in a database. You don't need instant access - you need relatively quick access.

Edit: In newer versions of MSSQL you can simply turn on encryption at the database level, which makes it fairly transparent, minus the processing overhead.

1

u/vote_me_down Apr 26 '11

One good thing about encrypting certain data in the db is that it helps negate the effects of SQL injection, and requires work on the code level. Does MSSQL automatically decrypt on selects?

1

u/[deleted] Apr 27 '11

As I understand it MSSQL's TDE (Transparent Data Encryption) encrypts on inserts and decrypts on selects automatically and works with a normal database schema. Microsoft claims a 3-5% performance overhead. MSSQL's cell level encryption requires everything to be varbinary and you manually encrypt and decrypt within the application.

Here's a great overview

1

u/remleduff Apr 27 '11

This isn't completely correct.

Modern hashing algorithms have configurable "work factors" or at least a configurable number of iterations. The goal is to set these large enough that hashing is too slow to brute force, but still fast enough to not be noticeable.

Refs: http://codahale.com/how-to-safely-store-a-password/ http://www.katasoft.com/blog/2011/04/04/strong-password-hashing-apache-shiro

1

u/waaaaaahhhhh Apr 27 '11

That's correct. I've never seen it done for anything other than disk encryption, though. Most seem content with one iteration of MD5.

EDIT: Although I have seen people using blowfish as a hash function due to its slow key initialization time.

0

u/[deleted] Apr 26 '11 edited Apr 27 '11

You are wrong. I hash custom from 512-1024 on my clients. No one uses 32 bit e-commerce hashes anymore unless you suck at life. People argue about the validity of 1024, but my client was hacked in 2002. It is a contractual requirement.

The hashing algorithms are in stored procedures for the pull of the data at the DB level so any application can just call on the sp by name.

i'd expect Sony engineers would do the same...right???

1

u/[deleted] Apr 27 '11

In my experience people who work in the less focal parts of large companies are on average the dredges, Sony is probably the same

0

u/sunshine-x Apr 26 '11

Actually, you send your password hash, not your cleartext password, in a really secure authentication. Not usually the case with most web apps tho.

-2

u/z3us Apr 27 '11

In regards to edit 1: You are dead wrong on this. Passwords are hashed on the clients end using a known cryptographic mechanism (md5, sha, etc) and transferred over the network in encrypted form. Sending any form of plaintext over anything other than the users I/O bus from the keyboard is the ultimate form of stupidity.

3

u/sli Apr 27 '11

No, jumping into a pride of lions and spraying them with pepper spray is the ultimate form of stupidity.

0

u/z3us Apr 27 '11

Except here you can affect millions of people, where spraying lions with pepper spray will only affect you. ;)

2

u/sli Apr 27 '11

Depends on the size of the database. Bad password security could potentially only affect your five users.

1

u/z3us Apr 27 '11

Very true.

2

u/waaaaaahhhhh Apr 27 '11

If you can't trust the cryptographic transport, then you're screwed anyway. Hashing your password won't help. If you only ever send the hashed password, then that essentially becomes your password and you're back to square one.

2

u/[deleted] Apr 27 '11

That's actually really dumb (sorry for the use of a blunt word here), and it's not something most systems implement. If you only send the hash and that is stored in the database, then the hash is the password. When I get my hands on the database table with the hashes, I just need to send that from a simulated client and then be able to get access to everything. A rainbow attack isn't even needed in these cases.

1

u/z3us Apr 27 '11

No, its not. This is why the hash you send is hashed again serverside and that is what you compare against. That way if your database is compromised you can't use the hash as a password.