bit-tech.net

Nvidia coughs to forum password leak

Nvidia coughs to forum password leak

Nvidia's forums - and other registration-required sites - are to remain offline until the company has secured its servers against attack.

Nvidia has confirmed that hundreds of thousands of accounts on its official forum have been leaked to ne'er-do-wells as the result of an intrusion on its website last week.

Late last week, Nvidia suspended all access to its official forums - forums.nvidia.com - as it investigated an attack. That attack, the company has now concluded, resulted in persons unknown making off with the user name, email address, profile information and hashed passwords for around 400,000 accounts.

Nvidia has stated that it has reset all passwords to a temporary value, which will be provided via email to each account holder. While this fixes the problem of the leaked passwords, it's still an issue for those who used the same password on other sites. 'As a precautionary measure,' Nvidia recommends, 'we strongly recommend that you change any identical passwords that you may be using elsewhere.'

While similar to the attack on Yahoo last week, which saw a similar number of account credentials leaked, Nvidia's approach to information security has greatly lessened the potential impact of the breach. Where Yahoo stored password values in plain text, Nvidia stored only the one-way hashes of the passwords - and further used a random salt value each time to dramatically increase the complexity of a brute-force attack on the hashes.

Although that doesn't necessarily put users in the clear - simple passwords of fewer than eight characters or comprising dictionary words will likely still fall victim to a targeted attack on the hashes - it's a ray of sunshine in a period of time where credential-leaking breaches are coming thick and fast.

While the company further investigates the breach, it is keeping five of its user-facing sites - Nvidia Forum, Developer Zone, Nvidia Research Site, Nvidia Board Store and Nvidia Gear Store - offline until it is sure that the flaw has been resolved and the systems made secure once more.

14 Comments

Discuss in the forums Reply
Picarro 16th July 2012, 10:47 Quote
Oh for the love of God.

How hard can it be to secure your servers from attack?
Chicken76 16th July 2012, 11:24 Quote
Quote:
Originally Posted by Picarro
How hard can it be to secure your servers from attack?
Very, very hard.
WarrenJ 16th July 2012, 11:46 Quote
It is very hard indeed. I'm guessing you don't know a lot about website development or server architecture?
MjFrosty 16th July 2012, 11:47 Quote
There is always a smarter fish! Or in this case a sadder act.
Picarro 16th July 2012, 11:55 Quote
Quote:
Originally Posted by WarrenJ
It is very hard indeed. I'm guessing you don't know a lot about website development or server architecture?

Not a single thing I am afraid.
Gareth Halfacree 16th July 2012, 11:59 Quote
Quote:
Originally Posted by Picarro
Quote:
Originally Posted by WarrenJ
It is very hard indeed. I'm guessing you don't know a lot about website development or server architecture?
Not a single thing I am afraid.
Don't feel bad - from the fact that Yahoo stored plain-text passwords, it wouldn't preclude you getting a job there...
Bakes 16th July 2012, 15:21 Quote
The article states that random salts make brute forcing harder. That would be the case - but only if the hackers had been dumb enough to not dump the 'salt' field of the table at the same time as they dumped the 'password' field.

The goal of salting is to make using reverse lookup tables impractical, as well as stopping admins from realising that users have the same password. For example, if I set my password to 'password', the md5 hash would be '5f4dcc3b5aa765d61d8327deb882cf99', which can be easily looked up on almost any database (such as md5decrypter.co.uk) since 'password' is really common. If I set my password to 'password' and it's salted with 'd61d8' giving the full password 'd61d8password', it hashes to a value which is not found in the same md5 hash database. Furthermore, two users with the same password will have different salts, so the hashes will be unique, even if the passwords are not.

I use lastpass nowadays. Means that if any one password is compromised, people don't get access to any of my other accounts (Google Authenticator is used to provide 2-factor authentication).
Cerberus90 16th July 2012, 15:30 Quote
I read the other day that Lastpass had a break in on their systems just recently (I think). I'd been looking at the options for password stuff after the yahoo thing.

I might start using PasswordMaker, just a bit of a hassle going through and changing stuff.
Gareth Halfacree 16th July 2012, 15:46 Quote
Quote:
Originally Posted by Bakes
The article states that random salts make brute forcing harder. That would be the case - but only if the hackers had been dumb enough to not dump the 'salt' field of the table at the same time as they dumped the 'password' field.
Not quite - the whole point of a salt is that it doesn't matter if the attacker knows the salt or not. If the salt is sufficiently random(ish,) then you could publish the salts publicly and still be perfectly secure.

Attacker wants to crack hashes with no salt: needs to hash dictionary or rainbow table once.
Attacker wants to crack hashes with 10 salts: needs to hash dictionary or rainbow table 10 times.
Attacker wants to crack hashes with 100,000 salts: needs to hash dictionary or rainbow table 100,000 times.

If an average rainbow table takes a powerful computer four months to calculate, then you've just made the attacker need 400,000 months of CPU time to exhaust the hashes. Doesn't matter if the hashes are secret or known to the attacker - he or she still needs to hash the rainbow table (or dictionary) once for each salt.
Bakes 16th July 2012, 19:18 Quote
Quote:
Originally Posted by Gareth Halfacree
Quote:
Originally Posted by Bakes
The article states that random salts make brute forcing harder. That would be the case - but only if the hackers had been dumb enough to not dump the 'salt' field of the table at the same time as they dumped the 'password' field.
Not quite - the whole point of a salt is that it doesn't matter if the attacker knows the salt or not. If the salt is sufficiently random(ish,) then you could publish the salts publicly and still be perfectly secure.

Attacker wants to crack hashes with no salt: needs to hash dictionary or rainbow table once.
Attacker wants to crack hashes with 10 salts: needs to hash dictionary or rainbow table 10 times.
Attacker wants to crack hashes with 100,000 salts: needs to hash dictionary or rainbow table 100,000 times.

If an average rainbow table takes a powerful computer four months to calculate, then you've just made the attacker need 400,000 months of CPU time to exhaust the hashes. Doesn't matter if the hashes are secret or known to the attacker - he or she still needs to hash the rainbow table (or dictionary) once for each salt.

That's why you wouldn't use rainbow tables in such a case. Rainbow tables are at heart, merely shortcut devices. They're the cryptographical equivalent of a library.

If you have a million unsorted books and you're looking to see if you own a specific book, you just go through each box in turn and pray you find it quickly. (analog of brute force).

If you have a million books and you want to open a library, where each book can be taken out many times by many people, you sort the books first to make them easy to search through (rainbow tables). The sorting operation takes a lot of time, but each subsequent search is fast (rainbow tables).

If you knew passwords were salted, you simply wouldn't use a rainbow table. Generating would be totally impractical, since you'd be taking up terabytes - especially since each salt would only be used roughly once in a moderate to large user database.

Regenerating your rainbow tables thousands of times is akin to getting a million books, sorting them, looking for one book, binning all the books, then getting a million more books (repeat). It's totally impractical - and isn't really even valid as a process. Far better is to get a million books, just check in each box of books for your book, and then bin them.

Salting totally stops the use of rainbow tables - it makes them totally impractical, as you have said.

However, rainbow tables are not brute forcing, as mentioned in the article. Brute forcing is where you simply go through each possible combination of characters until you have a success (it's much faster than regenerating rainbow tables because you don't have to use system storage). A computer with two gtx580s in could test 20 million keys a second. If you knew the keys were salted, you could simply append the salt to the start or end of each trial password. It would not affect the process of brute forcing at all.

So, salting:
Stops rainbow table attacks in their tracks (precomputed lists of hash/password pairs)
Doesn't affect dictionary attacks (testing passwords against words in a predefined list)
Doesn't affect brute force attacks (testing all possible passwords).

You are correct that rainbow tables would be made useless - but that does not in any way affect the statement
Quote:
dramatically increase the complexity of a brute-force attack on the hashes.
Gareth Halfacree 16th July 2012, 20:47 Quote
Quote:
Originally Posted by Bakes

So, salting:
Stops rainbow table attacks in their tracks (precomputed lists of hash/password pairs)
Doesn't affect dictionary attacks (testing passwords against words in a predefined list)
Doesn't affect brute force attacks (testing all possible passwords).
I'm confused. You have a good grasp of this, but you're still failing to understand how salts work.

To brute force, the attacker needs to try every possible password combination - as you say. If you hash '0' as a password, you can compare it to every hash in the list. Hashes generated = one, hashes checked = all of them. Then you can move on to '1', then '2,' and so on.

If the hashes are salted, you still need to generate the hashes one at a time. Unlike the above example, however, you can only compare your attempt to the hashes in the list which have a matching salt. You hash '0' with the salt 'a' and get the hash for 'a0' - if someone has the password '0' with the hash 'a,' you'll get a hit, but not if they have the password '0' with the salt 'b' or 'c' or 'd' or... Hashes generated = one, hashes checked = only those with a matching salt.

If you have 10,000 salts, you make the brute force attack 10,000 times more difficult. *That's* why you salt.

For dictionary attacks, it's the same: if you have a 10,000-word dictionary, you need to generate 10,000 hashes to check an unsalted list. If there are 10,000 salts, you need to generate 100,000,000 hashes for a dictionary of the same size. So, as I said, salting "dramatically increase the complexity of a brute-force attack on the hashes."

Any questions?
Bakes 17th July 2012, 02:07 Quote
Quote:
Originally Posted by Gareth Halfacree
Quote:
Originally Posted by Bakes

So, salting:
Stops rainbow table attacks in their tracks (precomputed lists of hash/password pairs)
Doesn't affect dictionary attacks (testing passwords against words in a predefined list)
Doesn't affect brute force attacks (testing all possible passwords).
I'm confused. You have a good grasp of this, but you're still failing to understand how salts work.

To brute force, the attacker needs to try every possible password combination - as you say. If you hash '0' as a password, you can compare it to every hash in the list. Hashes generated = one, hashes checked = all of them. Then you can move on to '1', then '2,' and so on.

If the hashes are salted, you still need to generate the hashes one at a time. Unlike the above example, however, you can only compare your attempt to the hashes in the list which have a matching salt. You hash '0' with the salt 'a' and get the hash for 'a0' - if someone has the password '0' with the hash 'a,' you'll get a hit, but not if they have the password '0' with the salt 'b' or 'c' or 'd' or... Hashes generated = one, hashes checked = only those with a matching salt.

If you have 10,000 salts, you make the brute force attack 10,000 times more difficult. *That's* why you salt.

For dictionary attacks, it's the same: if you have a 10,000-word dictionary, you need to generate 10,000 hashes to check an unsalted list. If there are 10,000 salts, you need to generate 100,000,000 hashes for a dictionary of the same size. So, as I said, salting "dramatically increase the complexity of a brute-force attack on the hashes."

Any questions?

I think we're disagreeing over the micro and macro scales. If one were attempting to bruteforce all of the hashes simultaneously, then yes, salting would provide a lot of protection. If one were attempting to bruteforce single passwords, then salting would not be at all effective, except against rainbow tables.

If I were attempting to retrieve the plaintext passwords of over a hundred thousand users, I wouldn't worry about getting the full passwords of everyone - because I'd likely be able to commit all the crime I needed to off just a few users. I'd just check each user with the thousand or so most popular passwords - a simple dictionary attack - and I'd likely get a whole bunch of matches over a large sample size. Since the salt must be stored, salting would provide no real additional protection due to the time involved.

So yes, I was wrong - I completely forgot about the case of someone simultaneously bruteforcing all of the passwords. If you're looking for the details of individual users, though, salting provideds no additional protection.
Gareth Halfacree 17th July 2012, 08:02 Quote
Quote:
Originally Posted by Bakes
So yes, I was wrong - I completely forgot about the case of someone simultaneously bruteforcing all of the passwords. If you're looking for the details of individual users, though, salting provideds no additional protection.
True (rainbow tables aside,) but that never happens. Think like an attacker: you are expending effort to crack hashes in your brute-force attack. If you target a single user, you have only one chance of getting the right hash. If you scan the entire list of hashes for a match, you have 400,000 chances (in this case) of finding the right answer. It's the hash generation that is computationally intensive; once you've generated the hash, trying to match it to an entry on the list takes a fraction of a fraction of a second whether you're comparing one hash or one million hashes. Therefore it's in the attacker's best interest to always target the entire list - it costs very little in the way of performance reduction, but vastly increases the attacker's chances of successfully cracking a user account.

This is exactly the sort of scenario that salting is designed to prevent.
Bakes 18th July 2012, 05:16 Quote
Quote:
Originally Posted by Gareth Halfacree
Quote:
Originally Posted by Bakes
So yes, I was wrong - I completely forgot about the case of someone simultaneously bruteforcing all of the passwords. If you're looking for the details of individual users, though, salting provideds no additional protection.
True (rainbow tables aside,) but that never happens. Think like an attacker: you are expending effort to crack hashes in your brute-force attack. If you target a single user, you have only one chance of getting the right hash. If you scan the entire list of hashes for a match, you have 400,000 chances (in this case) of finding the right answer. It's the hash generation that is computationally intensive; once you've generated the hash, trying to match it to an entry on the list takes a fraction of a fraction of a second whether you're comparing one hash or one million hashes. Therefore it's in the attacker's best interest to always target the entire list - it costs very little in the way of performance reduction, but vastly increases the attacker's chances of successfully cracking a user account.

This is exactly the sort of scenario that salting is designed to prevent.

I'll refer to md5 a lot in this post, but sha1 is equally applicable.

MD5 crackers are really fast, it turns out. A computer with 4x5970 graphics cards installed can hope to achieve around 33.1 billion keys tested per second.

If we assume that each core of the 5970s only has enough free registers to store one key, and that multiple cores cannot access the same part of memory (I know, I know, it's already unrealistic).

By testing one key at a time, we allow the key we're hoping to crack to be stored in the registers of the GPU. These are effectively instant access - we lose no time by using them - they can be accessed in the same instruction in which they are addressed.

Now, 33.1/3200*4 = about 2.5 million passwords tested per processor per second.

This is then gutted if you check each one against the four hundred thousand keys you bring up.
They must be loaded from the global memory - and at massive penalty - with CUDA it takes about 500 operations to load from memory. This means that you're taking about 250ms per key - managing a much more sedate 4 passwords per second tested per processor. It's not that bad - you have lots of registers, not just the one - but you'll still be restricted by those loads from memory.

2.5 million / 4 = 625000 > 400000 - it is more effective to run the brute forcing algorithm for each individual key than it is to run the brute forcing algorithm for all keys, since the act of loading each key from system memory is a massive drain on performance.

I'm not saying it's cut and dry - in fact I know my argument is pants because it's 5am and I'm not reasoning properly. I'm just saying that you shouldn't negate the time that needs to be spent accessing those 400000 keys - when you're testing 2.5 million keys per second per processor (Amdahl's law implies the task should be very much parallelizable (if that's a word), if you lose a millisecond per key, you've dropped a lot of time already.

Hashing is very, very cheap for small sources.
Log in

You are not logged in, please login with your forum account below. If you don't already have an account please register to start contributing.



Discuss in the forums