InfoQ

InfoQ

News

My Bookmarks

Login or Register to enable bookmarks for unlimited time.

The content has been bookmarked!

There was an error bookmarking this content! Please retry.

Gone in 160 seconds - cracking passwords with Rainbow Hash Cracking

Posted by Gavin Terrill on Sep 12, 2007

Sections
Development,
Architecture & Design
Topics
Ruby ,
Architecture ,
Security ,
.NET ,
Java
Jeff Atwood recently wrote about a technique to crack passwords called "Rainbow Hash Cracking". The technique, a variant on a dictionary attack, relies on a speedy search mechanism to do a table lookup against precomputed hash values. Jeff begins by surveying the password storage landscape, pointing out that passwords should never be stored in plain text:
Passwords are never stored in plaintext. At least they shouldn't be, unless you're building the world's most insecure system using the world's most naïve programmers. Instead, passwords are stored as the output of a hash function. Hashes are one-way operations. Even if an attacker gained access to the hashed version of your password, it's not possible to reconstitute the password from the hash value alone.
The Rainbow Tables technique pre-computes the hash value, saving time at the expense of creating very large tables:
But it is possible to attack the hashed value of your password using rainbow tables: enormous, pre-computed hash values for every possible combination of characters. An attacking PC could certainly calculate all these hashes on the fly, but taking advantage of a massive table of pre-computed hash values enables the attack to proceed several orders of magnitude faster-- assuming the attacking machine has enough RAM to store the entire table (or at least most of it) in memory.
Ophcrack, a Windows Password cracker, uses the Rainbow Tables technique. Jeff was able to use the smallest available table that ships with ophcrack (at 388 Mb) to find two out of five passwords within 3 minutes on a Windows XP machine. This table contains mixed case letters and numbers (about 80 billion hashes), and is able to crack 99.9% of Windows LanManager passwords. Jeff advises that support for LM hash, the early Microsoft encryption mechanism susceptible to a Rainbow Table attack, is not disabled by default:
I'm stunned that the legacy Lan Manager support "feature" is still enabled by default in Windows Server 2003. It's highly advisable that you disable Lan Manager hashes, particularly on Windows servers which happen to store domain credentials for every single user
LM Hash is vulnerable to this type of attack because it does not use today's common method of introducing "salt" to the encryption process. If encrypted passwords do not use a salt it is relatively simple to do a reverse lookup to find the plain text password.
But when a remote hacker obtains a large list of hashed passwords from a server or database, we're in trouble. There's significant risk from a rainbow table attack. That's why you should never rely on hashes alone--  always add some salt to your hash so the resulting hash values are unique.
A "salt" consists of random bits used as an input to the hash function in conjunction with the password, and mitigates the risk in two major ways:
  • it increases the length of the hashed value and potentially adds characters that were not part of the character set used in generating the table
  • you effectively need a separate Rainbow Table for each password as the salt is unique for each user
Both of these items add a significant amount of time to crack each and every password. In a follow up to Jeff's article, Thomas Ptacek points out in "Enough With The Rainbow Tables: What You Need To Know About Secure Password Schemes", the key to foiling password cracks is using an encryption algorithm that is, and can remain, relatively slow, such as bcrypt:

Why is bcrypt such a huge win? Think of the problem from two perspectives: the server, and the attacker.

First, the server: you get tens of thousands of logins per hour, or tens per second. Compared to the database hits and page refreshes and IO, the password check is negligable. You don’t care if password tests take twice as long, or even ten times as long, because password hashes aren’t in the 80/20 hot spot.

Now the attacker. This is easy. The attacker cares a lot if password tests take twice as long. If one password test takes twice as long, the total password cracking time takes twice as long.

Jeff concluded that the solution to protect your password from rainbow table attacks is to salt your passwords.
Summary by anjan bacchu Posted
  1. Back to top

    Summary

    by anjan bacchu

    Hi,

    Nice post.

    editor : Thanks for the summary.

    When a blog post or a forum thread gets a lot of comments, it will be nice if the original poster or editor can add a summary/update at the bottom of the post to summarize for the (new) readers.

    Good bloggers(Tim Bray, Tim O'Reilly come to mind) do this process some times. I hope jeff does that as well.

    BR,
    ~A

Educational Content

New-age Transactional Systems - Not Your Grandpa's OLTP

John Hugg discusses high volume transaction processing applications with high and low frequency profiles, and how VoltDB can be used for that purpose.

Cool Code

Kevlin Henney examines code samples to see what can be learned from them starting from the premise that one won’t write great code unless he knows how to read it.

Collaboration: At the Extremities of Extreme

Jason Ayers share the observations he made watching a team of developers collaborating in real time on the same code base, pushing XP, pair programming and continuous integration to their extremes.

Yesod Web Framework

Michael Snoyman presents Yesod, a web framework written in Haskell and containing a web server, templating, ORM, libraries (templating, gravatar, etc.).

Transactions without Transactions

Richard Kreuter and Kyle Banker on how to avoid classical RDBMS transactional systems by using compensation mechanisms, transactional messaging or transactional procedures.

Attila Szegedi on JVM and GC Performance Tuning at Twitter

Attila Szegedi talks about performance tuning Java and Scala programs at Twitter: how to approach GC problems, the importance of asynchronous I/O, when to use MySQL/Cassandra/Redis, and much more.

10 tips on how to prevent business value risk

One category of risk that project teams need to ensure they address is business value failure – delivering a product that fails to provide value for the business investor.

Interview: Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives

InfoQ spoke to the authors of Software Systems Architecture on a couple of new topics, the System Context viewpoint and Agile, which have been added to the second edition.