Bethesda hacked, user accounts info compromised

They're using a range of techniques but I don't believe that brute forcing is one of them. Most of the sites they've dumped have had SQL injection vulnerabilities or other issues in the application layer. A few have them have been servers that were just poorly configured and were hacked at the server level. Not sure what else they've been doing.
 
TheWesDude said:
eleven, again... you seem to be mis-using the idea of salt.

if i take data and hash it, i get a value.

if i take data and add a pre-defined "padded" data and add it to the information before i hash it, and then hash it and use that new hash to verify the data, i can be sure of the source.

a "salt" is pre-determined data that will be ADDED to the original data BEFORE it gets hashed.

it is much less useful when hashing smaller volumes of data and much more useful when hashing larger volumes of data.

plus there is the consideration of how do you "share" the salt before you hash said data, as if it is shared in a way that is in of itself unsecured, it becomes a vulnerability to use that "salt".


and if they are breaking into all these sites, my question is, are they using md5 or something bigger? do these sites they are breaking into have methods of detecting people attempting to brute force their servers?

if you dont have some methods of detecting and stopping someone from brute forcing your servers, then anyone can break into your server. it seems like lots of places have forgotten or stopped using basic and core security considerations in favor of usability.

Thanks for the clarification, it's starting to make sense now. A SALT is basically something added to data before a MD5 encryption, the SALT hash is (ideally) taken from a different value than the password itself?

I think around half of the sites were successfully attacked as a result of a SQL inject exploit but it's only the word of the hacking groups at the moment. From what I remember, Sony's hack was the only one touted to be as a result of a basic injection, given the fact that the data was all plain text, it doesn't seem too far fetched.

I never really understood the point of having captcha or fail limits on login pages before since they seemed very user unfriendly. It's all becoming clear now though.
 
Brother None said:
verevoof said:
Seriously. Why haven't they been stopped? How hard could it be to track down these people who have a website, Twitter accounts, released their own phone numbers...

I think such cases are hard to put together, especially since many countries suffer under antiquated law and methodology. It's happening, and will keep happening, but it's slow.

I very much so doubt the police seriously keeps in mind "Anon retaliation". Though they retaliate indeed, did in the Netherlands and Spain. Fuck em, more people to throw in jail, I say.

No, it's not that much of a mystery to begin with.
The only reason you know about these guys is that they chose to make themselves known. I assure you. They are well financed, very well trained and the only thing they do when they hear about jail is laugh. And I can see why, only the stupid end up in jail, the average work for the governments or the sec firms, while the elite end up yacht racers.
Does Beth want to press charges? I think they'd rather pay everyone just to shut up about it. If LS would not have made their deed public... no one would know about it.
 
Elven6 said:
Thanks for the clarification, it's starting to make sense now. A SALT is basically something added to data before a MD5 encryption, the SALT hash is (ideally) taken from a different value than the password itself?

I think around half of the sites were successfully attacked as a result of a SQL inject exploit but it's only the word of the hacking groups at the moment. From what I remember, Sony's hack was the only one touted to be as a result of a basic injection, given the fact that the data was all plain text, it doesn't seem too far fetched.

I never really understood the point of having captcha or fail limits on login pages before since they seemed very user unfriendly. It's all becoming clear now though.

say i have a password of the following:

nmarocksuknoit!

that would generate a hash

that is an example of:
data = hash

now lets say i want to use salt+hash

i take the original password and add a pre-determined salt of 12345

now i have:

nmarocksuknoit!12345

that is an example of:
data+salt = hash

or alternatively i could do
12345nmarocksuknoit!

that is an example of:
salt+data = hash

using a pre-determined salt is only as secure as the method used to share the salt.

using a salt with a hash is an attempt to combine the idea of PSK ( pre-shared keys ) with hashing.

unless you know BOTH data + salt, you do not know the hash.

in todays usage of using a hash instead of using the password, it makes knowing what the data or even the salt is irrelevant. if all you send is the hash, the values used to generate that hash is irrelevant.

all i have to know is what your hashed value is for your login info. and then just send that.

unless you are using a hashing algorithim that is returning 512 or more bits, it is pretty insecure. even with a salt.

nowadays the best security is a 512 or 1024 ASK setup ( asynchronus keys ) as hashing is only "secure" when going over trusted paths. and the internet is NOT a trusted path.
 
TheWesDude said:
Elven6 said:
Thanks for the clarification, it's starting to make sense now. A SALT is basically something added to data before a MD5 encryption, the SALT hash is (ideally) taken from a different value than the password itself?

I think around half of the sites were successfully attacked as a result of a SQL inject exploit but it's only the word of the hacking groups at the moment. From what I remember, Sony's hack was the only one touted to be as a result of a basic injection, given the fact that the data was all plain text, it doesn't seem too far fetched.

I never really understood the point of having captcha or fail limits on login pages before since they seemed very user unfriendly. It's all becoming clear now though.

say i have a password of the following:

nmarocksuknoit!

that would generate a hash

that is an example of:
data = hash

now lets say i want to use salt+hash

i take the original password and add a pre-determined salt of 12345

now i have:

nmarocksuknoit!12345

that is an example of:
data+salt = hash

or alternatively i could do
12345nmarocksuknoit!

that is an example of:
salt+data = hash

using a pre-determined salt is only as secure as the method used to share the salt.

using a salt with a hash is an attempt to combine the idea of PSK ( pre-shared keys ) with hashing.

unless you know BOTH data + salt, you do not know the hash.

in todays usage of using a hash instead of using the password, it makes knowing what the data or even the salt is irrelevant. if all you send is the hash, the values used to generate that hash is irrelevant.

all i have to know is what your hashed value is for your login info. and then just send that.

unless you are using a hashing algorithim that is returning 512 or more bits, it is pretty insecure. even with a salt.

nowadays the best security is a 512 or 1024 ASK setup ( asynchronus keys ) as hashing is only "secure" when going over trusted paths. and the internet is NOT a trusted path.

I see, now it's beginning to make sense. The only issue would be to make sure the salt hash itself is secure, which makes sense since I remember hearing Gawker had a "weak salt". Thanks again for the clarification/bearing with me.
 
Back
Top