Passwords stored in a database as hashed values can be recovered either through brute-force calculation of the hashes or through use of rainbow tables (which are specific to the algorithm used).

A rainbow table is created as a series of pre-computed values for either a dictionary file or more commonly every combination of a given character set [a-z, A-Z, 0-9] being a common example.

Essentially they can speed up the cracking of a password by allowing the hash value to be looked up in the table rather than requiring the attacker to create the hash for each password. Rainbow tables for common password algorithms (eg, NTLM, MD5, etc) can be found on-line, making it fairly straightforward to get access to large volumes of them.

There are a number of ways of improving the security of the hashes stored in the database.

First up is to user a per user Salt value. this value is stored in the database along with the hashed password. It isn't intended to be secret but is used to slow down the brute force process and to make rainbow tables impractical to use.

Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database.

A third means of helping improve the security of the passwords is to use a slow password function. this won't have a huge impact on individual users, but will massively slow down an attacker in cracking passwords retrieved from the database. some more information on this approach is available here

Passwords stored in a database as hashed values can be recovered either through brute-force calculation of the hashes or through use of rainbow tables (which are specific to the algorithm used).

A rainbow table is created as a series of pre-computed values for either a dictionary file or more commonly every combination of a given character set [a-z, A-Z, 0-9] being a common example.

Essentially they can speed up the cracking of a password by allowing the hash value to be looked up in the table rather than requiring the attacker to create the hash for each password. Rainbow tables for common password algorithms (eg, NTLM, MD5, etc) can be found online, making it fairly straightforward to get access to large volumes of them.

There are a number of ways of improving the security of the hashes stored in the database.

First up is to use a per user salt value, this value is stored in the database along with the hashed password. It isn't intended to be secret but is used to slow down the brute force process and to make rainbow tables impractical to use.

Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database.

A third means of helping improve the security of the passwords is to use a slow password function, this won't have a huge impact on individual users, but will massively slow down an attacker in cracking passwords retrieved from the database. Some more information on this approach is available here

Passwords stored in a database as hashed values can be recovered either through brute-force calculation of the hashes or through use of rainbow tables (which are specific to the algorithm used).

There are a number of ways of improving the security of the hashes stored in the database.

First up is to user a per user Salt value. this value is stored in the database along with the hashed password. It isn't intended to be secret but is used to slow down the brute force process and to make rainbow tables impractical to use.

Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database.

A third means of helping improve the security of the passwords is to use a slow password function. this won't have a huge impact on individual users, but will massively slow down an attacker in cracking passwords retrieved from the database. some more information on this approach is available here

Passwords stored in a database as hashed values can be recovered either through brute-force calculation of the hashes or through use of rainbow tables (which are specific to the algorithm used).

A rainbow table is created as a series of pre-computed values for either a dictionary file or more commonly every combination of a given character set [a-z, A-Z, 0-9] being a common example.

Essentially they can speed up the cracking of a password by allowing the hash value to be looked up in the table rather than requiring the attacker to create the hash for each password. Rainbow tables for common password algorithms (eg, NTLM, MD5, etc) can be found on-line, making it fairly straightforward to get access to large volumes of them.

There are a number of ways of improving the security of the hashes stored in the database.

First up is to user a per user Salt value. this value is stored in the database along with the hashed password. It isn't intended to be secret but is used to slow down the brute force process and to make rainbow tables impractical to use.

Another add-on I've seen to this is to also add in what was called a pepper value. This was just another random string but was the same for all users and stored with the application code as opposed to in the database. the theory here is that in some circumstances the database may be compromised but the application code is not, and in those cases this could improve the security. It does, however, introduce problems if there are multiple applications using the same password database.

A third means of helping improve the security of the passwords is to use a slow password function. this won't have a huge impact on individual users, but will massively slow down an attacker in cracking passwords retrieved from the database. some more information on this approach is available here