Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I was just reading about how it's better to use bcrypt to protect passwords instead of saving password hashes in databases, and that got me thinking about other aspects that hackers work on that I had never thought of before. Please correct any part of my questions as I have very basic understandings of cryptography and hacking in general. I'm just looking to learn the general aspects of these types of attacks, for myself.

I understand Coda's point in that salting your password wont save you if the attacker is just brute forcing passwords instead of trying to decrypt your hashes using rainbow tables, so we have two different types of attacks:

  1. The hacker has a password file/database but does not have the code/program, or trying to gain access by brute forcing would cause account or IP blockage. In this case, they'd be forced to try and decrypt the password field of let's say the database. If you saved a hash, then they'd just try comparing the hash field to a rainbow table of different types of hashes of different words, right? What would happen if I stored the Hash of the Hash of the password? Are there rainbow tables for that?

  2. On Coda's article, he mentions that you basically can rent computing power for cracking for cheap. Trying out millions of passwords per second. This would obviously be against a file or database I'm guessing, not a live site (unless they hacked the server, got the website code, removed the account locking mechanism and mounted their own environment, would they even try that?). If they are doing this against a password file, does each hacker write their own program who will craft requests to brute force or decrypt said password source?

  3. When they are trying to brute force decrypt a password file, do they try with every possible encryption/hashing method? Or what is the most average or common way?

Thanks in advance for your responses

share|improve this question
1  
Is "Bruce forcing" where you ask Bruce Schneier what the password is? –  Ladadadada Jul 14 '12 at 16:55
    
hahaha you are mean Ladadadada –  silverCORE Jul 14 '12 at 17:47
    
there i updated it. –  silverCORE Jul 14 '12 at 17:48
    
A suggestion for the future: I recommend asking one question per question. This site doesn't deal well with questions that actually ask multiple different questions (as this one does). Instead, it is better to split them up into multiple posts. –  D.W. Jul 15 '12 at 23:12
add comment

3 Answers

up vote 2 down vote accepted

If you go through how Rainbow Tables work, I believe you'll be able to answer some of your own questions. Almost all questions that you've asked require a understanding of how they work, what they are and how are they created.

However, I'll try to answer your questions.

If you saved a hash, then they'd just try comparing the hash field to a rainbow table of different types of hashes of different words, right?

Yes, but not its not that straightforward and its not different types of hashes. Rainbow tables are hash algorithm specific. Essentially they are just a time-space trade off. You still compute hashes when you use rainbow tables - a lot of them. How many do you compute before you crack the password depends on how big (and exhaustive) the rainbow table is.

To explain it in a very simplistic way, a rainbow table gives you hints. Say your password hash is "XYZ", rainbow table requires you to hash 'XYZ' multiple times (can be millions). After each iteration, you are required to check if the resulting hash is present in the rainbow table. If found, it'll will tell you to hash another string (start of that chain) n number of times (where again n can be a in millions) to get the password.

So again, rainbow tables just help you crack faster, they don't make it as easy as just a lookup in a large database (which is in fact one extreme end of rainbow tables, when basically you've just pre-computed hashes of all possible passwords).

What would happen if I stored the Hash of the Hash of the password? Are there rainbow tables for that?

If you save hash of a hash, it'll be just one single more step in the way passwords are looked up in the tables. However, the attacker has to know that you are storing hash of a hash to be able to crack it.

As a note - people do hash a password multiple times and then save the resultant hash and apply related techniques. However it is not to make it more difficult to use rainbow tables. The basic concepts of rainbow table can still be applied to it.

This would obviously be against a file or database I'm guessing, not a live site (unless they hacked the server, got the website code, removed the account locking mechanism and mounted their own environment, would they even try that?

Yes, you'd not try password cracking live on a website. The network latency and other factors just make it impossible. Normally all you need is a file of password hashes.

If they are doing this against a password file, does each hacker write their own program who will craft requests to bruce force or decrypt said password source?

You could write your own program once you understand how the rainbow table is constructed, but normally the rainbow table vendor will give you the program that goes with it.

When they are trying to brute force decrypt a password file, do they try with every possible encryption/hashing method? Or what is the most average or common way?

You cannot use a MD5 rainbow table for SHA1 hashes. So tables are tied to their hash algorithm. Also, rainbow tables don't work with hashed passwords. When I say don't work, I mean that you cannot use a generic rainbow table to crack a salted password. You can create a rainbow table that will crack all passwords salted with that particular salt but then as you can imagine, you'll need as many rainbow tables as the number of salts - which already defeats the purpose as rainbow tables are expensive to compute.

Also I will not invest my time in cracking a password unless I know the algorithm used to hash it and if there is anything done to obscure the hash. Essentially I am saying that I'd want to see the code used to come up with the hash rather than trying to crack it with random tables and presumptions.

share|improve this answer
add comment
  1. a shortcut to this problem would be to registe in the website and put the password 11111 and get another dump of the database and see if you could figure it without the code. I'm not sure about any rainbowtables that has a MD5(MD5(password)) tables but there is several GPU cracking tools that has it http://www.insidepro.com/eng/passwordspro.shtml.

  2. Brute forcing live site takes a lot of work which is unnecessary if you have the database dump. There are two different ways that i know of regarding cracking hashes. You find a website that offer this service, or you build your own in amazon, there is a talk about using amazon GPU cloud service to crack passwords. link: http://stacksmashing.net/2010/11/15/cracking-in-the-cloud-amazons-new-ec2-gpu-instances/

  3. that depends which is the web application you are using, most are known for using a combination but nothing that the php code can't reveal. I wouldn't rely on this point.

You can search google for GPU password brute forcers and use them to help you determine which is best to use. Using bycrypt sounds a good idea for now since it's slow to crack or not available in brute forcing applications.

Good luck

share|improve this answer
    
hah, thanks Thawab, I was not looking to crack anything or attack any site/system. I am just trying to learn theory and concepts about the topic, not to actually do it :) –  silverCORE Jul 14 '12 at 7:13
add comment

The attacker knows the code. This is the usual assumption, which has two faces:

  • There are many ways for the attacker to know the code. The code exists on the servers themselves. It has been developed, so it is also on the developers' machines. It is also in the versioning system used by the developer. It is in the backups of all these systems. More often than not, the code is some opensource software project, and is thus known by everybody, by definition.

  • Even when the attacker does not know the code, you cannot quantify how much he does not know it (equivalently, how much time and resources it will take him to rebuild it). There is not much to say about security when you do not quantify things; you will just get feelings, not facts.

Thus, you must assume that the attacker knows all about the code he is trying to attack. Those who did not assume that ran into trouble. Auguste Kerckhoffs explained it all in 1883 and he was Totally Right -- still is, even with todays technology.

A dictionary attack is what is also known as "brute force" when applied to passwords. Dictionary attacks are to cryptography what big clubs are to military tactics: a clumsy tool which can make some damage, requires a lot of club-wielding soliders to be effective, and can be handled by a caveman. In the case of passwords, this is just "trying potential passwords" until one works. There are two kinds of dictionary attacks:

  • Online dictionary attacks: the attacker submits his "guessed passwords" to the target server. In that case, how the server stores the passwords (or hash thereof) is irrelevant; the attacker is "outside". It is up to the server to limit the rate at which such passwords can be submitted. An extreme case of that model is a bank smart card which locks itself up after three successive wrong PIN. For a server which can be used remotely, locking accounts is a bit harsh (it would allow any attacker to lock the accounts of other people) but delaying login attempts is doable and effective (if the server does not allow more than one attempt per 5 seconds on each account, the attacker is limited to 17280 guesses per day).

  • Offline dictionary attacks: the attacker could obtain enough data to "try passwords at home". For instance, he got a copy of the database table containing the password hashes. These things happen: many vulnerabilities (e.g. SQL injection attacks) can result in that kind of read-only access to the entrails of the server. Even in that case, we would still prefer that the attacker does not learn the passwords themselves (not the least reason being that the average user reuses passwords, so a password for a user on one site may be a good password for the same user on another unrelated site). How passwords are hashed is then utterly relevant.

Offline dictionary attacks are of course much scarier than their online counterparts. A simple hash function invocation (e.g. you use SHA-1 on the password and just store the result) will not be robust enough, for two reasons:

  1. Hash functions are too fast. An off-the-shelf GPU will compute one or two billions of SHA-1 instances per second. Ambitious attackers will rent some CPU. The average password complexity (i.e. the kind of password that average users choose) will not resist more than a few minutes to that kind of power.

  2. Hash functions are always the same. This allows the attacker to optimize things a lot. For instance, if attacking 1000 hashed passwords simultaneously (he grabbed the file containing all the hashed user passwords), he can hash each potential password once and look the value up in the list, thus attacker 1000 passwords for the cost of attacking one. Another optimization (which is the same thing, modulo a space/time swap) is the use of precomputed tables: attackers collude; one of them spent some dollars on computing all the hashes for "common passwords" into a big table; then all his fellow attackers just have to look their password hashes up in that table. The mythical rainbow tables are that kind of table, with an extra storage optimization (a 500 TB table will actually fit in 200 GB, for instance) which does not change things qualitatively.

To fix these two issues, we use password hash functions which are slow (instead of one hash function invocation, we use one million iterations of the hash function; the average user will not notice that his login attempt took 50 milliseconds instead of 50 nanoseconds; but the attacker will notice that his attack cost was multiplied by one million...) and which are salted (a salt is like using a new variant of the hash function for each stored password; it makes precomputed tables useless, and defeats parallel attacks). Good password hashing functions like bcrypt and PBKDF2 do both. A simple invocation of SHA-1, as LinkedIn was doing, does neither.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.