Blog Mar 2011


Password salting, hashing, and stretching        

Hashing a password involves a one-way function that converts an (optionally salted) password into a fixed-size set of bits. The idea is that you always store the password hashes rather than the passwords themselves. After storing a password hash, you can then verify the associated password, by hashing it and then comparing with the stored hash. Read more

26-Mar-2011 19:30


Generating random passwords        

Now that we have a PasswordPolicy class and a Die class, the actual password generation process is very straightforward.

We first need to know the password policy, and then roll a die which has the same number of sides as the number of symbols in the policy's acceptable symbols list. The roll result is used as an index into the symbols list, and the symbol at that position becomes the next character in the password. Repeat for as many characters as the password needs - again, this is defined by the password policy.

Read more

17-Mar-2011 01:00


Secure pseudo-random numbers        

The term "pseudo-random", as used by cryptographers, may be misleading to a non-technical reader. Numerous important systems, ranging from military communications to the encryption that protects virtually all online transactions, rely on the functionally-equivalent security between "cryptographically-secure pseudo-random" and "random". Read more

16-Mar-2011 20:00


A password policy implementation        

Most applications that use a password or passphrase for user authentication also have a policy that dictates the password complexity requirements. These requirements range from a simple minimum length to some very complex rules. There's a decent case for arguing that the more complex policies might actually reduce security in some circumstances. This is because these policies encourage users to invent easier-to-remember (i.e. weaker) passwords or to write down passwords in order to remember them. Read more

12-Mar-2011 21:20


A race against time - protecting user passwords        

Imagine that your website's password database has been compromised and is in the hands of the attacker. He can launch an offline attack on the database, and dump your users' account names and cracked passwords publicly on the Internet. At this point, you have 4 potential problems:

  • Many of your users will lose trust in your organisation.
  • Your organisation will have some unpleasant publicity.
  • The dump can be harvested by people looking to compromise your application's users.
  • The dump can be harvested by people looking for passwords that might have been reused on other web sites.

So you're now in a race against time. 

Read more

05-Mar-2011 19:00