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.