Book Review: The Block Cipher Companion

A few months ago I picked up a new book called The Block Cipher Companion by Lars Knudsen and Matthew J.B. Robshaw.  Shortly thereafter, I posted a review on ethicalhacker.net.  I am reposting that review here.

The book is aimed at practioners and aspiring researchers in block cipher cryptography.  It is very well-written and accessible (for a cryptography book).  I've been interested in cryptography since Applied Crypto came out when I was in high school so I was very excited to finally see a dedicated book on block ciphers. 

How big is 2**128?

Most cryptographic algorithms deal with numbers that are 128 bits or larger.  A 128-bit number has 2¹²⁸ possible values, but how big is 2¹²⁸?  Most people realize that it’s a “big number” but don’t comprehend exactly how big.  Who can blame them?  Outside of a few disciplines such as cryptography and astrophysics, most people will never encounter a number this large.  

It’s important to understand this, however, because it tells us what is and is not possible in cryptography.  Conversely, a number of inaccurate statements about cryptography arise because of a poor understanding of this quantity.  For instance, many articles I’ve read recently claim that it is possible to use rainbow tables even for password hashing algorithms with a 128-bit salt.  Others have claimed that it is or will be possible to brute-force 128-bit keys.  To understand the problem with these claims, let’s figure out just how big this number is.

Sorry about the mess.

Sorry about not truncating my posts earlier.  Math I'm good at; visual design, not so much.

Everything should be much more readable now.

An Introduction to Password Protection

In June 2004, I published an article on password protection in ;login:.  The article discusses the history and basic concepts behind the password protection measures used in Unix and Windows.  Parts of it are out of date (e.g. the password length recommendations), but the technical parts hold up fairly well as an introduction to password security.  It also provides lots of references for further reading.

Disclaimer: I no longer stand by some of the advice I gave at the end of the article.  Password aging and expiration, for instance, are worthless.  Read it for the technical bits, but skip the ending.

The article is online here.

Passwords: Attacks and Threats

People throw around a lot of advice about password security, but we don't often talk about what we're trying to accomplish.  The purpose of this post is to flesh out some of the questions we should be asking to determine who the potential attackers are and what attacks we are trying to prevent.  This allows us to consider if and why we would want to implement defenses such as password salting and stretching, two-factor authentication, time delay, password expiration, and account lockouts. 

At a basic level, a password is used to secure access to an account so let's assume there is a corresponding threat that someone would try to get into that account.  But, we need to get more detailed than this.  Who would try to get into account (i.e. the threat actor)?  Why?  Would they be happy with any account or just a specific one like root or Administrator?  Does the attacker need to crack a large number of accounts or will he be satisfied with just a few?  Would the attacker be likely to use an online attack or an offline attack?

How long should passwords be?

There's a lot of advice thrown around about what the actual password requirements should be, but most organizations do not stop to consider what the goals of those requirements are.  In this post, I throw some numbers around to determine minimum password lengths for different security requirements and hashing algorithms.  The minimum lengths can get a bit silly, but this is why we need to use strong password hashes and should use two-factor authentication when practical.

The first consideration is whether the organization wants to prevent offline cracking attempts or just online attacks. Online password guessing is easier to stop. With even a short temporary lockout (five seconds is sufficient), the passwords do not need to be that strong: five characters with a reasonable complexity requirement should be sufficient. With a 5 second lockout, you can guess 17,280 passwords per day per user. At that rate, it would take 145 years to exhaust the password space assuming five character, mixed-case, alphanumeric passwords.

Rainbow Tables Not Considered Harmful

Since the LinkedIn password dump was posted online a couple of weeks ago, there's been a lot of discussion about hashing algorithms, salts, and, of course, rainbow tables.  Rainbow tables were described in Phillipe Oechslin's 2003 paper Making a Faster Cryptanalytical Time-Memory Trade-Off and are a type of lookup table for password hashes that only require a fraction of the storage needed for a naive lookup.  You might, for instance, only store 1/2000 hashes. 

Rainbow tables seemed like a pretty big deal at the time.  Rather than an attacker brute-forcing passwords every time he needs to crack some hashes, an attacker can make tables ahead of time so that he will only have to perform a relatively quick lookup operation later.  This is way more efficient than brute force if the attacker is dealing with unsalted password hashes from relatively small sites (thousands of users or less). 

Today, rainbow tables don't seem like such a big deal after all.

Passwords Matter

This is in response to a Tenable blog post "Do Passwords Matter?"  I have several issues with the post that I address here.

Password Salts

When discussing password cracking, the post says "A 'salt' will help slow down this process a little."  Actually, salts slow down the process a lot.  It's still no more difficult to brute-force an individual user, but it becomes insanely hard to brute force all of the accounts for a large set of hashes (e.g. the 6million+ hashes dumped from LinkedIn).  With salts, it's six million times harder to crack six million passwords than to crack one.  Salts also prevent rainbow tables and other precomputation attacks completely.  The Tenable post points out that developers sometimes implement salts incorrectly.  That's really beside the point.  Just because some developers get it wrong doesn't mean the others should stop trying to get it right.