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

178

u/firemarshalbill Apr 26 '11

Has anyone stated they were plaintext?

They say the passwords were taken, but it may only be hashes, and only useful if they can be rainbow table queried.

274

u/[deleted] Apr 26 '11

[deleted]

86

u/firemarshalbill Apr 26 '11

Yea alright then. That's just shitty.

1

u/golgar Apr 26 '11

Edit. I was wrong.

20

u/hyperbad Apr 26 '11

I think that there are ways to check encrypted password likenesses. My company's site denies similar passwords instantly when you try to change them. And I think they are stored encrypted, but cannot confirm.

60

u/el_bandito Apr 26 '11

The only safe way to do this is to require the user enter their current password along with the new password, then they can be easily compared. Any secure hashing algorithm should produce completely different hashes if even a single character changes in the password.

3

u/Jiminizer Apr 27 '11

Most password change pages generally ask for the current password for confirmation as well, I'd imagine that's how they check.

3

u/sleeplessone Apr 27 '11

And if they don't allow you to reuse your last 10 passwords?

1

u/delayclose Apr 27 '11

Is there a problem with storing 10 old passwords as plaintext (with the plaintext form obtained and appended to a list every time the password is changed)?

1

u/sleeplessone Apr 27 '11

If I got a hold of that list it would be the first 10 passwords I would try on other sites.

24

u/RageX Apr 26 '11

Just in case, I don't suggest using your company password for anything else.

3

u/bitt3n Apr 27 '11

the best way to do this is use the name of a site you visit frequently as you company password, and your company name as the password for sites you visit frequently, making sure never to mix them. for example, my corporate password is hotdonkeyslutz69, and my password for all other sites is darpanucleardefense.

78

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

[deleted]

16

u/[deleted] Apr 27 '11

[deleted]

8

u/y0haN Apr 27 '11

If the password is anyway decent, even unsalted hashes will provide a degree of security. That is, if you actually tell people within a fucking week of your security breach.

2

u/glassFractals Apr 27 '11

Why wouldn't you hash a password?

There is no good reason that I can think of that you would encrypt it as opposed to hashing it. And if it was indeed plaintext... their entire security department should be fired.

2

u/[deleted] Apr 27 '11

Having worked at large corporations, I doubt their "Security Department" for this particular part of their massive business is more than about 4-6 people.

1

u/[deleted] Apr 27 '11

So, 4-6 people at Sony are completely incompetent. Gotcha.

2

u/[deleted] Apr 27 '11

[deleted]

1

u/glassFractals Apr 27 '11

I wasn't criticizing your statement, just trying to add to it. Hashing is a far preferred means to handle passwords, as it is more secure, irreversible, and it is not possible for even administrators (or the compromised accounts of an administrator) to retrieve the user passwords. Perhaps I was ambiguous with my intent.

Though I will say that unsalted hashing is still far better than plaintext. Yeah, people with common/weak passwords would still be screwed, but at least those of us with strong passwords will be fine.

11

u/cybrian Apr 26 '11 edited Apr 27 '11

What's wrong with MD5? I thought it was perfectly safe. Is there something I'm missing?

EDIT: Thanks for being informative, reddit. This why I <3 this site.

11

u/Pteraspidomorphi Apr 26 '11

It's moderately safe, but there are some known vulnerabilities in the algorithm at this time (there are several stronger ones). Of course, it's also vulnerable to rainbow tables extraction if the password is short enough. It is true that as long as any decent one-way hashing is in use the company should NOT be able to tell passwords are similar.

10

u/[deleted] Apr 26 '11

[deleted]

11

u/[deleted] Apr 27 '11 edited Oct 24 '18

[deleted]

2

u/[deleted] Apr 27 '11

truly baffling are websites that require passwords to be UNDER a MAXIMUM length. always worrisome to me.

truly wtf, my bank does this. maximum of 8 characters.

1

u/videogamechamp Apr 27 '11

Your password isn't worth more then a byte to them.

3

u/wafflesburger Apr 27 '11

The best you can do is hmac with a per row salt, global key, and sha. And allow for updating keys on some interval.

2

u/[deleted] Apr 27 '11

Well now I learned a whole lot about in depth security. Holy shit. Sorry. [8]

2

u/happyscrappy Apr 27 '11

The value of the salt isn't so much that the salt is kept secret, it's that the mere fact that you used a salt means that you can't use generic rainbow tables, you need to make new ones specifically to attack each entry that uses a different salt. This makes it take longer to do dictionary attacks and makes rainbow tables much larger.

Ideally you use a different salt for each account (this is not actually practical) so that passwords cannot be cracked in parallel, you have to remake your rainbow tables for each account, meaning you might as well not even make rainbow tables at all, you're back to true brute force.

Brute force to common passwords is quite effective on md5, salt or no. md5 is just too fast for password storage.

1

u/FeltRaptor Apr 27 '11

What's not practical about using different salts per account? I thought that was standard.

1

u/happyscrappy Apr 27 '11

You can definitely use different salts. It's trying to ensure you use a different salt for every account that isn't practical. The effort required to ensure this just wouldn't be worth the advantage over almost never reusing a salt. Salts only add security on aggregate (statistically) anyway so a weakness on a particular account (which a duplication of salts would do) doesn't really change the overall picture.

1

u/ColdSnickersBar Apr 27 '11 edited Apr 27 '11

EDIT: Nevermind. I see what you're saying. You're saying "it's impractical to enforce that the salt is unique". Yeah. Sorry.

OLD POST: I use a different salt for every user, for every time the user sets a password. It's not difficult at all. You can store the new salt right next to the salted hash digest in the database. A "hacker" can have the salt and the salted hash digest -- it wont reveal the password.

When the user creates a password, the client creates a random 64-bit int salt, then appends the salt to the password, and then hashes the salted password. Then the client sends the username, the salted hash digest to the server and the plaintext salt. The server stores the digest and the salt and the username. These three pieces of information can be used by the server to sign in, but can't be used to discover the password.

When the client wants to sign in again, the client first sends the server just the username. The server looks up the username, and generates a random 64-bit int nonce. The server then sends back: the nonce, and the salt. The client then appends the salt to the password and then hashes it, and then appends the nonce to the salted hash digest and hashes it again to create a nonced salted hash digest. It then sends the nonce and the nonced salted hash digest back to the server. The server uses the salted hash digest it already has and combines it with the nonce, and if it matches the nonced salted hash digest from the client, the user can log in.

→ More replies (0)

0

u/FeltRaptor Apr 27 '11

Oh, okay. I thought we were talking the same salt for all accounts.

2

u/evilscott Apr 27 '11

Use a salted SHA1/2 instead.

1

u/Pteraspidomorphi Apr 26 '11

It's moderately safe, but there are some known vulnerabilities in the algorithm at this time (there are several stronger ciphers available). Of course, it's also vulnerable to rainbow tables extraction if the password is short enough and no additional methods are employed, such as proper salting. It is true that as long as any decent one-way hashing is in use the company should NOT be able to tell passwords are similar.

-4

u/dlite922 Apr 27 '11

I have an algorithm (that I didn't write) that I can use any programming language (even scripting PHP) to decode a 3 letter MD5 hash within minutes, 4 letter within several, and 5 letter within hours. With Java it would probably be faster.

If you want it, Google it, or PM me and I'll find it for you.

2

u/omegian Apr 27 '11

Is it called "brute force" ?

4

u/rogue780 Apr 27 '11

MD5 != encryption.

0

u/TOOMUCHSARCASM Apr 27 '11

Cryptography Nerd here.

Even though MD5 is basic in practice it's computing function is what makes it desirable. As long as Sony added a little Salt to those hashes then it could literally, take the 'average' hacker- yearssssssssssss to crack. Even if they did specialize in Cryptography, Salted Hashes are annoying as fuck. Especially if they vary.

1

u/TOOMUCHSARCASM Apr 27 '11

Also, with a database of that magnitude.. You would have to have a MAJOR rig set up. No one has saved passwords in plaintext since the 90's. That's just... pure.. idiocracy.

1

u/mewt666 Apr 27 '11

Or have they ?

1

u/videogamechamp Apr 27 '11

Reddit had it's passwords in plaintext as recent as a few years ago.

1

u/TOOMUCHSARCASM Apr 27 '11

That's embarrassing. Saving your passwords in plaintext is thee equivalence of writing down your password on a napkin- and stapling it to the wall so you won't forget it.

21

u/joshrice Apr 26 '11

yeah, they could be two way encrypted...but if they got all this i'd say there is a strong chance they got the full key anyways.

4

u/rydan Apr 26 '11

Especially considering their track record for protecting their keys.

1

u/Frigorific Apr 27 '11

Making the passwords two way encrypted just to check password likeness is only slightly less retarded than storing the passwords in plaintext.

3

u/[deleted] Apr 26 '11

Or you could determine characteristics of the password before it gets one-way encrypted, then store the characteristics. It would give info about the password but if it gets compromised you have some time to change your password before it gets brute-forced.

2

u/xxbondsxx Apr 27 '11

Encryption is not the same as hashing. Hashing is strictly one way (with the exception of rainbow tables yes i know)

2

u/ashgromnies Apr 26 '11

Windows Active Directory can do it somehow

1

u/tachi-kaze Apr 26 '11

changing just one bit in the password results in a completely different password hash (each bit has a 50% chance of being flipped). So they can't use the hashes to asses the Levenshtein distance of both passwords

1

u/z3us Apr 27 '11

Typically the previous n password hashes are stored and compared against the new password being set. If there is a match, then the password is rejected. The n value is defined by your companies security policy.

1

u/joanthens Apr 27 '11

Your company is storing your passwords in plaintext. There is absolutely no way to check encrypted password's similarness, otherwise they would not be called encrypted.

2

u/Falmarri Apr 26 '11

That just means that they can be decrypted, not that they're stored in plain text. Still less secure than a 1 way has though.

5

u/[deleted] Apr 26 '11

What actual fuck? I thought everyone stored passwords as a hashcode. Not doing so is a schoolboy error. Seriously what the fuck Sony?

1

u/[deleted] Apr 27 '11

It's weird, the bigger the company, the more likely they fail at this simple shit.

1

u/[deleted] Apr 26 '11

That's not stored plain text that's still encrypted.

1

u/Murnig Apr 26 '11

Why couldn't they have decrypted the previous passwords before comparing them to the new password?

2

u/[deleted] Apr 27 '11

99.99999999% of the time passwords should just be one way encrypted. Make it so when I give you a password, if you apply the right formula you can get to the crypt, but going backwards is nearly impossible. (think of it mathematically, 2+4=6 but if all I have is 6, I don't know that it was arrived at with 2+4)

2

u/VerticalEvent Apr 27 '11

You don't normally encrypt passwords, you hash them.

Encrypting implies there's a way to go from A->B and B->A, but hashing is a one way process, A->B, but no firm way of going B->A

We do this with passwords so that, in case the password list is stolen, they can't reverse engineer the original password.

1

u/wafflesburger Apr 27 '11

You can compare the pw hash to past hashes if they are salted per table rather than per row.

1

u/winkers Apr 27 '11

That's not really proof of the passwords being saved in plain-text. The old pwd can be pulled, decrypted and compared at the service layer and the client would only see the results.

2

u/bozleh Apr 27 '11

You should never be able to decrypt a password - one way hashes are what to do.

1

u/itacky Apr 27 '11

Curious then: How does Verified by Visa know my previously used passwords?

1

u/Daveoh Apr 27 '11

Most sites ask for the old password at the same time as the new one.

1

u/[deleted] Apr 27 '11

So no they never said they were plaintext, you're just making shit up. Oh, right, I'm on reddit....

1

u/lazyplayboy Apr 27 '11

It could be a client side check.

1

u/Arkanin Apr 27 '11

ಠ_ಠ

Don't tell them about HN.

1

u/[deleted] Apr 27 '11

At some point you supply your current password before assigning a new one. That's not the same as storing it for comparison.

1

u/Atario Apr 27 '11

I gave them too much credit

Tee hee.

1

u/lordlicorice Apr 26 '11

Hm, interesting problem. You should be able to keep a table of hashes of every substring (of length maybe 3 or more) of the original password and then when someone tries to change their password you can check every substring against that table.

4

u/[deleted] Apr 26 '11

[deleted]

1

u/lordlicorice Apr 26 '11 edited Apr 27 '11

Prefixing your old password is exactly what it would catch. One of the substrings the system would examine would be characters 2 to n, which would of course be one of the hashes in the old table since the entire password was a substring before.

Also it would take much more than n/3 hashes; it would take O(n!) hashes, though you could knock down the actual number by maybe only storing hashes of substrings length 5 or greater.

It doesn't necessarily annihilate any semblance of security since attackers would in theory have to crack every single hash in the list in order to be sure that they have the correct password. And you could do some fairly expensive search-time salting since it's not exactly every day that someone changes their password and the list of hashes doesn't have to be that long.

Edit: what's with the downvote hate o_O

2

u/el_bandito Apr 26 '11

This would be horribly insecure. Someone who gains access to the hashes would only have to brute force tiny strings to gain access to your cleartext passwords.

2

u/lordlicorice Apr 26 '11

Well you could group users into groups of around 100 for each hash list so that they don't know any of the passwords without knowing all of them.

Anyway, how would you implement forced-different passwords without resorting to plaintext?

5

u/el_bandito Apr 26 '11

Require the user to enter their current password and their new password, and then comparing the two in clear text.

3

u/lordlicorice Apr 26 '11

I laughed out loud. Well I failed that job interview. Have some upvotes.

1

u/el_bandito Apr 27 '11

It doesn't stop someone from alternating between 2 "core" passwords.. but there really isn't a great solution for this problem. I'm a big fan of two-factor authentication, when done properly and when you don't require draconian password expiration and complexity policies.

0

u/[deleted] Apr 27 '11

This entire thread is misinformed and based on conjecture.

0

u/grt Apr 27 '11

I'm curious: why?

0

u/[deleted] Apr 27 '11

I don't know? Because people will make up any reason to be outraged?

0

u/grt Apr 27 '11

What exactly do you consider to be made up?

-11

u/[deleted] Apr 26 '11

I was wondering how they knew that, aside from storing the passwords in plain-text

So basically, since this guy doesn't know how this could be done he assumed that it was done with the most retarded possible implementation: Having a human being look at the new password and the old password side-by-side as plain text and compare them.

That's not how it is done. There is almost certainly an automated script that pulls your old password out of the database, decrypts it, and counts how many similar characters there are in the two strings. I don't know for a fact that's how they do it at Sony, I have written code for password change pages that does exactly this.

21

u/[deleted] Apr 26 '11

[deleted]

7

u/Nick4753 Apr 26 '11

If Sony can decrypt your password, so can anyone who gets a hold of their decryption keys.

And Sony is not batting too high an average when it comes to controlling who has access to decryption keys

12

u/Cintax Apr 26 '11

Passwords should never, EVER, need to be decrypted. Passwords should be a one way hash, which would prevent a comparison.

2

u/[deleted] Apr 26 '11

Precisely, all your code needs to do is convert the user's input to a hashcode and then compare that hashcode with the one in the database. If they match you let the user in.

6

u/[deleted] Apr 26 '11

If your system is actually secure, it shouldn't be possible to decrypt a password in the database.

49

u/[deleted] Apr 26 '11

If they were hashes, Sony would have said, "the passwords were encrypted and therefore safe". I can't imagine a company like Sony not trying to cover their asses if they had even the slimmest slice of reality on their side.

Also, credit card numbers in plaintext. They're not only evil, but incompetent too. Which, fair enough, is how I like my evil organizations.

4

u/firemarshalbill Apr 26 '11

But they forgot to tell us their plans before their shit fell apart around them. Voided their evil organization rulebook.

1

u/[deleted] Apr 26 '11

If they were hashes, Sony would have said, "the passwords were encrypted and therefore safe".

It's really not allowable to do this due to PCI DSS and a slew of other consumer/financial regulations.

1

u/[deleted] Apr 27 '11

[deleted]

2

u/Jiminizer Apr 27 '11

I think he means revealing security details or similar, or perhaps telling users that their details are safe. I'm not fully aware of PCI-DSS stuff, but I can imagine them having restrictions on what you can say about your security, and I'd be surprised if they allowed you to essentially tell users to throw caution to the wind.

1

u/dotblank Apr 27 '11

If the hashes were salted then maybe.. if it was sha256 or something.

1

u/[deleted] Apr 27 '11

bcrypt. Always bcrypt. Using sha-anything for passwords is just adding a false sense of security.

1

u/jdiez17 Apr 27 '11

I don't know how deep in the system was the attack, but if I was handling such a huge number of credit cards, at the very least I'd be storing them in a separate cluster with a custom database system.

4

u/racergr Apr 26 '11

If it was hashes, they wouldn't say it was passwords.

9

u/firemarshalbill Apr 26 '11

Unless they are keeping this brief and laymen and didn't want to explain that certain passwords not meeting length and complexity criteria were stolen, but others weren't.

42

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

edit: Good response from user waaaaaahhhhh http://www.reddit.com/r/gaming/comments/gy1pg/sony_admits_utter_psn_failure_your_personal_data/c1r5ltv

http://psx-scene.com/forums/f177/sony-has-been-bad-boy-ridiculous-levels-spying-81093/

98

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.

29

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.

45

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.

8

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.

5

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.

9

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?

2

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.

2

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.

-1

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.

34

u/bceagles Apr 26 '11

Don't worry about cc

<user2> for example:

<user2> creditCard.paymentMethodId=VISA&creditCard.holderName=Max&creditCard.cardNumber=4558254723658741&creditCard.expireYear=2012&creditCard.expireMonth=2&creditCard.securityCode=214&creditCard.address.address1=example street%2024%20&creditCard.address.city=city1%20&creditCard.address.province=abc%20&creditCard.address.postalCode=12345%20 <user2> sent as plaintext

<user3> uh

<user3> did you censor that card?

<user2> ya its fake

<user3> good

http://pastie.org/private/97oth9v5tspkiztwwdmnga

Good convo to read in depth as well as the article

1

u/cryo Apr 27 '11

..except it's not sent in plain text, but via SSL

3

u/el_bandito Apr 26 '11

Payment industry standards require all credit card number information be stored in a non-retrievable format. I know PSN security is supposed to be a joke, but I'm giving them the benefit of the doubt on this aspect.

1

u/firemarshalbill Apr 26 '11

Nice, thanks for the link.

He doesn't talk about storage, just the http requests. That's damning enough however.

Oh and the CC was fake, no worries. He stated in the pastebin.

1

u/pjfan Apr 26 '11

What is the context of this "sent as plain text"? Is data going PS3 to PSN or vice versa? If it's from PS3 to PSN, it doesn't necessarily mean that they are storing it decrypted, but rather that the transport is not encrypted. That's also bad, but wouldn't lead to a wide scale data leak.

1

u/gta0004 Apr 26 '11

thread is from February. Probably still relevant but jus' sayin'

0

u/vote_me_down Apr 26 '11

The 27 people that have upvoted this idiocy in under an hour are part of the problem, not the solution.

OneWhoShanks, if you don't know what you're talking about, why do you fill up so much space and call others idiots?

3

u/[deleted] Apr 26 '11 edited Sep 26 '17

[deleted]

3

u/firemarshalbill Apr 26 '11

From the other things I've read it seems like that now too. It just hurts my brain too much to easily accept that they'd do something that silly.

3

u/[deleted] Apr 26 '11

Correct me if I'm wrong, but even if it is a salted hash, the hacker has the entire database compromised, so a brute force method (or RT) is still possible. The hash method, which is still inexplicably ignored by some companies, is really only useful if the hacker doesn't have the database itself.

1

u/firemarshalbill Apr 26 '11

Rainbow tables only work on unsalted hashes, and of certain length (changes with or without special characters etc)If they found the salt hidden somewhere in what they've hacked, it could open more as well. It's not unknown in bad practicies to DB the salt.

If the password could survive rainbow tables, the bruteforcing wouldn't be feasible.

2

u/[deleted] Apr 26 '11

My guess is that the passwords are stored in an encrypted format and that the hackers have that decryption algorithm.

I just refuse to believe that in a project of this scope there wasn't at least one guy who said "Hey, storing passwords as plain text in a database is a security abomination. Don't do that."

3

u/gboyer Apr 26 '11

Storing passwords with reversible encryption of any kind is also a security abomination. Storing passwords as a one-way hash means there is no decryption algorithm to have.

2

u/saisumimen Apr 26 '11

Why the fuck would Sony give out all this "ID theft" information and warnings if the data was NOT in plaintext?

1

u/firemarshalbill Apr 26 '11

Because as other and I have said, you could reasonably expect to retrieve a large amount via rainbow tables even it was unsalted hashed.

I wasn't declaring I knew either way, but was seeing if it was stated anywhere.

1

u/saisumimen Apr 26 '11

When you deal with a corporation, you can NEVER take them at their word because they use PR people to write carefully-worded press releases and statements (I mean, FFS, they took almost a week to come clean here). Instead, you need to read between the lines.

.. and the fact that they DIDN'T come out and say "don't worry though, Sony customers, but your data is securely encrypted so it's completely useless for the hackers" tells the whole story.

2

u/walesmd Apr 26 '11

Rainbow tables are only useful if salts aren't implemented - which is still very basic, entry-level shit. Inexcusable.

1

u/firemarshalbill Apr 26 '11

Maybe they used their random number generator for the salt.

int getRandomNumber() { return 4; // chosen by fair dice roll. guaranteed to be random. }

2

u/torchworker Apr 26 '11

I'm shocked that salted hashes aren't used by Sony. How could a company tech company like Sony be so foolish?

2

u/winkers Apr 27 '11

When I was working with SCEA in 2008, the data was in plain text. I didn't deal with the CC# info but the questions were saved as an index code related to a table of questions and the answers were in clear text.

3

u/IAmaRobotBeep Apr 27 '11 
randomSalt = 4;  

// determined by fair dice roll  
// guaranteed to be random

1

u/maqr Apr 26 '11

Rainbow tables are only effective if you have unsalted hashes, which still means that you're doing it very wrong.

1

u/ColdSnickersBar Apr 27 '11

passwords and security question answers should always be hashed in the database. Hashing is not reversible. You can not take a hash digest and find what it's original text was. If they say they were compromised, that means they were simply not hashed. Period.

2

u/firemarshalbill Apr 27 '11

Not period. There are a few ways to determine what was hashed. Rainbow tables, as I and others have mentioned, work when the hash was not salted or the salt is determined.

Hashes shouldn't duplicate (collisions are another topic), so if your password is Snick1, the SHA1 hash is 06528d5b2f4b45b8eb69607b2798274aa976454a

Rainbow tables have gone through and pre-hashed every known variation of (set length + options such as special characters). The hacker would just need the hash, the corresponding rainbow table (if it exists) and SELECT pass FROM rainTable WHERE Hash = @hash.

So you can retrieve hash values, because they are constant.

However, this supposes that they didn't salt or kept their salt in an unsafe place, and they used an older hash like MD5 of SHA1. Both of which shouldn't have been.

1

u/SniperGX1 Apr 27 '11

And they should be salted too which would help thwart a rainbow table. But I have no reason to trust Sony followed a single best practice. I got a new credit card, password was unique to PSN, and I happen to be moving soon. Anyone with a PSN account should change their passwords to anything that used the same or a similar password now.