Password-Based Encryption (PBE)
The examples that we've given so far have used binary keys. These keys need to be stored in some fashion
– on a hard drive or floppy disk for instance. Password-based encryption (PBE) uses a password as the key.
This is convenient because the security then rests with the user rather than in a physical medium.
Unfortunately, password-based encryption in general isn't as secure as algorithms with binary keys like
TripleDES or Blowfish. To demonstrate this, let's say we use Blowfish with a key size of 128 bits. That gives
us a keyspace of 2128. Password-based encryption typically uses ASCII characters. An average user's
password might be 6 characters in length. If it's entirely lowercase, there are only 266 possible keys, or
roughly 228. Adding capital characters and symbols helps quite a bit, but it cannot even approach the
keyspace of a good symmetric algorithm.
To add to their insecurity, most passwords are simple everyday words. If an attacker were trying to crack a
password, they would likely try every English word, which could be done rather quickly on a fast computer.
This is known as a dictionary attack and is surprisingly successful. There are a number of tools out there
that will automate a dictionary attack – some even test combinations of words, differing capitalization, and
the use of numbers and some symbols. It's quite interesting to try one of these tools out and see how secure
a password is. A good password should be at least 8 characters long and use capitalization, numbers, and
symbols, like "m1Nnes0+a". It's important that the password be simple enough to memorize, however, as
you should never write a password down.
Password encryption uses a combination of hashing and normal symmetric encryption. The password is
hashed using a message digest algorithm like SHA-1 (we'll discuss this topic more in Chapter 6), and then
the resulting hash is used to construct a binary key for an algorithm like Blowfish as shown in the following
diagram:
As we mentioned, one of the problems with password-based encryption is that it is possible to create a
precompiled list of passwords, hash them, and have a set of keys ready to try on encrypted data. This
allows an attacker to try all normally used keys very quickly, and so determine if any of them decrypt the
data. There are two techniques used to combat this attack: salting and iteration counts. A salt is a random
value appended to the password before it is hashed to create a key, and the iteration count is the number of
times the salt and password are hashed. Let's examine each of these in some detail and see how they
improve security.
Salt
By adding a random piece of data to the password before hashing it, we greatly increase the number of
possible keys created from a single password. Without a salt, the word "sasquatch" hashes to a specific
value. If we add 8 bytes of random data before hashing it, then "sasquatch" can hash to 264 possible values.
That means that it is effectively impossible to create a precompiled-key list dictionary, as it would be far too
large. Instead, the attacker is forced to perform a hashing computation rather than a simple lookup on the
data, which will take quite some time.
The salt is stored with the data that is encrypted. Each time a new piece of data is encrypted, a new salt is
generated. This means that the same phrase will encrypt to a different value each time it is encrypted, even
if the same password is used every time. To decrypt, the salt must be extracted from the encrypted data,
and then combined with the password to create the decryption key.
An example of the use of a salt is the password checking system in Linux. Typically passwords are MD5-
hashed with a random salt. The salt is then prepended to the resulting hash. That salt and hash are then
written to the password file. The first few characters are the salt and the remaining characters are the
password hashed with the salt. When someone tries to log in, the operating system reads the password they
type in and their entry in the password file. It then hashes the user's typing along with the first characters of
their password entry. If the resulting hash is equal to the remaining characters in their entry, their password
is correct.
In just a moment we'll show an example of using salt and password-based encryption that should help make
this process clearer.
Iteration Count
The iteration count is an attempt to increase the time that an attacker will have to spend to test possible
passwords. If we have an iteration count of a thousand, we need to hash the password a thousand times,
which is a thousand times more computationally expensive than doing it just once. So now our attacker will
have to spend 1000 times more computational resources to crack our password-based encryption.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
