back to article Nvidia admits forums hacked, user data swiped

Nvidia has admitted that it suspended its user forums last week because they were hacked and posters' personal data lifted. The graphics chip maker said last night that its investigation following the discovery that "unauthorised third-parties gained access to some user information", specifically user login names, email …

COMMENTS

This topic is closed for new posts.

hashed and salted

im curious to see if these hashed and salted pwd's will find their way on the web.

it should give good protection and give the hackers a run for their money to figure them out ;

it *is* bad that it took nvidia a week to notify ppl about it though..

1
0

NNTP?

Remind me what was wrong with NNTP again?

1
0

Have had the e-mail this morning

Am glad they have informed me (though quicker would have been better) and they do seem to have done the right thing with their passwords (salting and hashing) as I recommend in a blog post of mine. However, I'm curious about this 'random salt' part. Does each user have a unique, random salt? If so, is that appended to the password or stored in a column in a row. Either way, not sure what a random salt would add over hashing, say: [e-mail]+[nvidia_global_salt]+[password]. Modifying the result further in a custom way would also help obscure the password against hash table attacks (eg XORing against the hash of the e-mail), but I wonder how much better that would be in practice (a question for somebody knowledgeable in cryptographic maths). My guess is that, to a certain degree, the more steps you add, the more likely an attacker is to give up before discovering a method to reverse the password - provided it doesn't impact on the effectiveness of the original hash.

0
0
Holmes

Re: Have had the e-mail this morning

Salting passwords usually stops people from using a dictionary hack on them but if the random salt was also given out then it would be a security risk...depends on the exact type of encryption which is used (md5/SHA-1 etc)

0
0

Re: Have had the e-mail this morning

Salted hashed do not defend directly against dictionary attacks. I think you were meaning rainbow table based attacks.

Salting does not add any defence against a brute-force/dictionary attack against a single account. It does mean, however, that if five accounts had used the same password, they need to be attacked individually. Without salting, those five accounts would have the same hash and it would be clear that they had the same password.

0
0

Re: Have had the e-mail this morning

I understand how salting is required, I'm just wondering how the salt can be random without storing it somewhere (and I would guess that this location would be in the user table, along with the hashed password). So in my blog, I recommend hashing something like the following:

moo@test.comNVIDIA_SECRET_SALT_[user password]

What NVIDIA seem to be doing from what i've read is hashing the following:

[random text][user password]

If the random text is truly random on a per account basis, there must be a record of it somewhere in order to be able to hash it with the user's password in order to produce the correct hash (so the user can log in). I'm curious as to how NVIDIA handled this random hash - if they stored it in the user table, it won't provide a great deal of protection against hash table lookups as it will quickly become obvious the the criminals who obtained the data that they simply need to subtract the details of column 'X' (or whatever it's called) from the password to get back to the user's password. Admittedly, you have the same problem with my approach as it will become obvious that 'NVIDIA_SECRET_SALT_' is appearing in all the passwords.

0
0

Re: Have had the e-mail this morning

> If the random text is truly random on a per account basis,

It is. It needs to be unique per account. The gain in security comes because it is impractical to pre-compute and store rainbow tables for all possible values of the salt. If you used a single salt for all of your records it would be practical for an attacker who discovered it to compute rainbow tables to discover your passwords.

> there must be a record of it somewhere

Yes, you can either store it separately, e.g. in its own field in the user's record in a database, or concatenate it to the hashed password (used for Unix /etc/passwd at some point).

> they simply need to subtract the details of column 'X' (or whatever it's called) from the password to get back to the user's password.

It doesn't work like that. You calculate/store/compare hash(salt + password). For a decent hash function subtracting the salt from the hash doesn't give you the password.

0
0

Cracked, not Hacked

When will we stop misusing the term "hack" to describe computer security breakers? The correct term for a security breaker is "cracker".

The term "hacker" was coined in the 1950s at MIT's Tech Model Railroad Club, before there was any computer security to be broken. A hacker is simply anybody who uses ingenuity to solve problems in a playful manner.

Using the term "hacker" to refer to crackers is the same as using the term "Asian" to refer to NASCAR drivers. It makes no sense.

Just because you've seen one or two Asians driving NASCAR does not mean all NASCAR drivers are Asian.

0
0
(Written by Reg staff) Silver badge

Re: Cracked, not Hacked

Yes, yes. It's a bit sad that someone needs to point out that language evolves and now 'hacked' means 'cracked' as well.

C.

0
0
This topic is closed for new posts.

Forums