Engineering in the white spaces
____________________________________
Demonstrating the password utilities library
Before demonstrating the new password utilities library, we interrupt our scheduled programming to bring you the latest offender in end-user personal data storage. Sony's Playstation Network and Qriocity services have recently suffered a major intrusion that exposed personal data for its 77 million users. It's not completely clear from their FAQs, but it appears that the user passwords weren't hashed or encrypted, but instead stored in plain text. This makes the Sony rootkit fiasco positively tame in comparison. Read more
03-May-2011 23:55
____________________________________
The final step is to measure the information entropy of specific passwords and their hashes. In this context, entropy is a measure of unpredictability. For randomly-generated passwords, the information entropy (measured in bits) is a reasonable proxy for password strength.
For example, a password with 42 bits of entropy is as strong as a string of 42 bits chosen randomly. An attacker would need 242 attempts to exhaust every possibility of finding this password by brute force. Adding an extra bit of entropy doubles the number of guesses required, making the attacker's task twice as difficult.
Read more08-Apr-2011 21:25
____________________________________
Generating and verifying password hashes
To create the salted hash, we're going to use the .NET Framework's implementation of a key derivation function called PBKDF2, also published as RFC 2898. PBKDF2 has some useful properties: you can use a salt, you can define the hash output size, and you can configure the slowdown factor by specifying the number of iterations over the hash function. Read more
02-Apr-2011 20:00
____________________________________
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.
The benefit of using password hashes is that because the hashing function is one-way, it's not possible for an attacker to reverse-engineer a password from its hashed value.
Read more26-Mar-2011 19:30
____________________________________
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 more17-Mar-2011 01:00
____________________________________
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 more05-Mar-2011 19:00
____________________________________
FizzBuzz is an interview-related meme that did the rounds about a year ago. The idea is that you can use a very simplistic question to screen-out a significant percentage of candidates applying for a job in software development. If you can't program FizzBuzz in a deep coma while having half your brain removed, then you can't program anything properly. Read more
13-Mar-2008 23:00
____________________________________
The Skeptical Software Development Manifesto
We are always interested in claims to the invention of better ways of developing software. However we consider that claimants carry the burden of proving the validity of their claims. We value:
* Predictability over novelty
* Empirical evidence over anecdotal evidence
* Facts and data over rhetoric and philosophy
That is, while there is value in the items on the right, we value the items on the left more.
Read more26-May-2007 23:50
