What I wanted was a password generator that could output a configurable length password using only easily distinguishable letters and numbers, so I wrote one. As usual I place this code in the public domain, feel free to use it any way you want.

Features:

1. The entropy of the password is as good as the underlying operating system. If you use a recent Linux or OSX version, the data returned from /dev/random is quite good.
2. The code is simple and it is easy to verify that the program actually uses the entropy that it reads.
3. The resulting passwords are easy to type on keyboards and write on paper without confusing the reader with similar characters such as 1 (one) and l (lower case l).
4. The length of the password is configurable.

#!/usr/bin/python
 
import sys
 
# alphanumeric chars minus l, I, O, 0, 1
alphabet = "abcdefghijkmnopqrstuvwxyzABCDEFGHJKLMNPQRSTUVWXYZ23456789"
# Some expeimentation told me that 2 ** 5.8 = 55.7
BITS_PER_CHAR = 5.8
 
# The default password length has the capacity of a bit more
# than 64 bits of entropy.
DEFAULT_LEN = 12
 
def main(args):
	count = DEFAULT_LEN
	if len(args) > 1:
		if args[1] == '-h':
			usage()
			return
		elif args[1] == '-c' and len(args) > 2:
			count = int(sys.argv[2])
		else:
			usage()
			return
	print(create_password(count))
 
def string_to_bignum(s):
	num = 0
	for c in s:
		num = ord(c) + (num << 8);
	return num
 
def create_password(length):
	random = open("/dev/random", "r")
	needed_bytes = (int)(length * BITS_PER_CHAR) / 8 + 1
	n = string_to_bignum(random.read(needed_bytes))
	random.close()
	s = ""
	for i in xrange(length):
		s = s + alphabet[n % len(alphabet)]
		n = n / len(alphabet)
	return s
 
def usage():
	print """mkpasswd [-h] [-c COUNT]
Create a random password using the operating system's entropy pool
using a 57 character alphabet of letters and numbers. The characters
in the alphabet excludes characters and letters easily confusable such
as I and 1. 
 
Each password character holds about 5.8 bits of entropy, so the
standard 12 character password can hold a theroretical maximum of
69 bits of entropy.
 
The actual entropy present in any generated password is a function
of the entropy gathering algortihm present in the kernel of your
operating system.
 
  -h        display this help text
  -c COUNT  create a password with COUNT characters."""  
 
if __name__ == '__main__':
	main(sys.argv)

DNSSEC protects the DNS system against a certain group of security problems such as the kaminskybug, where an attacker tricks a DNS server to return the wrong data to end users. If an attack against the DNS system is successful that means serious trouble, since we depend on it to work reliably in a vast number of online activities. An attacker that controls the DNS system can trick people to for example supply their account information to their online bank and use that to steal money. Whenever there is the potential for large scale fraud you can pretty much be sure that someone will try to break it, and that is why DNSSEC is important.

So, we need DNSSEC. What's stopping us from using it? A few things, but the most important obstacle in my opinion is that it is a complex set of standards and that it is difficult to understand. There are some presentations and HOWTO documents online that attempts to explain and help people get started, but the learning curve is steep. One thing that I ran into when experimenting with my own zones was that somehow I managed to corrupt the signatures of one zone and I couldn't easily pinpoint what the problem was.

When confronted with this I got the idea to build an online service that tries to answer a simple question. What data was used and what cryptographic operations was performed to actually verify one specific DNS record? The answer to that question can be thought of as a chain of operations and records where one link connects to the other from all the way from the record being verified down to the DLV root key.

I decided to write the service in Python and it was one of the most fun programming projects that I have worked on in years. In a way it was basic research but with a clear application and an end result that I think could be a useful contribution. I even wrote my own RSA signature verification functionality, with a lots of help from Python's excellent large integer support.

The service can be found at http://dnssec.resare.com Feel free to give it a spin. There are no doubt bugs and errors that will be fixed and other modifications that will be made, but the basic functionality is in place.

Thanks to Alex for the beautiful HTML design,  to the python dns library dnspython that I use extensively and the airspeed templating library.

Learning new programming languages is an interesting thing to do. I've done it a few times now and if the language is good it gives you a few new perspectives and new ideas on how to be a better programmer. I must say that ruby is a nice acquaintance. The learning curve is a bit steeper than with languages like python (or maybe I'm just getting old) but many things are elegant and I hope to get to work more with it in the future.

Anyway, without any further ado I give you pwhash.rb. Feel free to use it in any way that is compatible with GPL3. I'm fully aware that I have yet to master the style and details of ruby, so if you have any criticisms or ideas on how to improve upon it, feel free to drop me a line.

Online services generally use usernames and passwords to identify their users. The simplest way of doing that is to save the information in clear text, perhaps in a database or in a text file. When a user logs in, look up the stored password and compare it with the one supplied by the user. If they match, authentication is successful. A simple solution, but a problematic one. If the username and password information gets in the hands of the wrong people. Since many user the same password over and over again it is likely that the username-email-password combinations can be used to log into other services.

This is a real problem. Writing secure web applications is difficult, and security problems that gives an attacker access to login data can be introduced not only by your own code but also by third party libraries and frameworks.

Because of this it is a good idea to make it somewhat more difficult to use the password information for an attacker using some sort of scrambling method. Many people call such methods password encryption, but encryption implies that its possible to decrypt  the information with the right key, and keys can be lost so it is better to make the process one way. The basic idea is to take a plaintext password and change it into something called a hash that can not be reversed back into the plaintext. However, the scrambling process needs to be repeatable so that a plaintext password can be verified to match the password that was once used to create the hash.

To help in this process there is a family of cryptographic functions that called cryptographic hash functions. They work in a way that a variable length input is turned into a fixed length output in a way that it's very difficult to a) find two inputs that generate the same output and b) find the input given a specific output. Assuming that the cryptographic hash function works as advertised, shouldn't this should solve all our password storing problems? If we store a cryptographic hash of the user supplied password using for example the SHA-1 algorithm, an attacker that gets hold of our login data can't run SHA-1 backwards to get the passwords. All he has is a list of hash values, but at the same time we can repeat the SHA-1 function when a user needs to authenticate and compare the hashes of the new and old password. If they match they must be the same.

This would be an efficient method if it were not for one little detail: Users choose bad passwords. Some use password, some use their first name some a1. There are lists available with common passwords, and once an attacker puts a computer to the task of trying out passwords many of them gets broken. Worse yet, since the SHA-1 algorithm is such a common one, there is almost certainly hard drives out there filled with pre-calculated SHA-1 values for all common passords and even the ones for all possible password combinations shorter than for example 8 characters. With such pre-calculated values any short or simple password can be found in seconds.

To solve the second problem, the one with pre-calculated hash values, something called a salt value is used. A salt is a random number that is added to the plaintext password before it is encrypted. If the salt can have say a billion possible values, someone doing pre-calculated hash values need to do a billion times more pre-calculations and have a billion times more storage to store the hashes. The salt value can be stored in an unaltered form together with the hash value, and be used when verifying a password by simply doing the same hash operation with the same salt a second time. Another benefit of adding salt to the password is that if you have a large number of users, the attacker can't reuse each password guess with all the users, since their salt values differ.

The problem with easy to guess passwords is much more difficult to solve. The only thing that helps a bit, besides educating users in methods for choosing better passwords, is to make it more time consuming to do one hash calculation. That way it takes longer to try out millions of common passwords and password combination and guessing right will take longer, hopefully too long to be worth it. To make it take a bit longer to calculate the hash you can simply repeat the cryptographic hash function over and over again. Doing it once on my dual core desktop computer takes less than a millisecond. Doing it a thousand times increases the time spent calculating one hash value to about 200 milliseconds.

So, to take good care of your users' login information you should:

1. pay attention to security on your servers. That includes operating system security, backup management as well as avoiding misstakes in your own code.
2. encourage them to use good passwords.
3. store hash values of the passwords instead of plaintext versions
4. use a good cryptographic hash function to hash them
5. use a large enough and random enough salt value when hashing
6. repeat the hash function until you reach a reasonable tradeoff between efficiency and difficulty of repeating it by an attacker.

Soon, I'll publish some java code I've written that implements recommendations 3-6. But that's for another day, now I need to put this computer to sleep.

Update 090330: Since I wrote this post I have published the code for two implementations of these recommendations, in Java and Ruby.

Why is this important? Well, if you have a scenario when for example a government agency has the ability to eavesdrop on and store vast amounts of data it might come to a situation when said agency gets really interested in decoding some of the encrypted information that is has snooped. If you are a government agency it might be enough to send a nasty letter to for example a webmail or social networking service demanding the key, or even break into the hosting facility that holds the secret key and obtain it, legally or illegally.

Anyway, back to my question. After some research I have found the somewhat dissatisfying answer is most of the time, stored encrypted traffic can be decrypted if the key is obtained. There is however a technique that effectively prevents such a scenario called Perfect Forward Secrecy. It is available when using the the DHE key exchange protocol, which is part of some of the cipher suites that can be used with TLS, the protocol used when connecting to a website with an address starting with https.

DHE stands for Diffie-Hellman key exchange with Ephemeral parameters, a method for a server and a client (in this case a web browser) to find a common session key that is used to encrypt the actual data without ever sending the actual session key in clear text. The key, as well as the Diffie-Hellman parameters used by the client and server to calculate the key is (hopefully) never stored on disk, but created for each connection (or, in the case of session caching, each couple of connections between the same server and client) and then discarded. The long term secret key used to authenticate the server and hopefully prevent man-in-the-middle attacks can not be used to re-create the session key even if it is known by an attacker.

To be able to use DHE to set up the encrypted connection, both web server and web browser need to support it. All modern web browsers that I have tested supports it, but for some reason many web servers doesn't. Why? I'm not really sure, but I think that it might have to do with several factors. It it requires a bit more server resources to set up a DHE key exchange than it does to set up a straight RSA one. Also, I think that many people making decisions about which cryptos to provide has too much confidence that a secret key will remain secret. 

Anyway, if you want to test if your web browser supports Ephemeral Diffie-Hellman key exchange, feel free to visit my cryptography test page that I set up to try this out. If you want to avoid certificate warnings you might want to install the CACert root key in your web browser. It is as least as secure and well maintained as the other root certificates that are already bundled with your web browser or operating system.

I sometimes say, half jokingly, that my motto is There is no problem that doesn't have a technical solution. This is of course false, but when it comes to privacy on the internet, technology can be helpful.

For those of you that doesn't know about FRA and the new law, it is the Swedish equivalent of the NSA and they have traditionally provided the swedish government with military intelligence gathered from intercepted radio traffic. Since the airwaves has become kind of boring to listen to over the years with people using new means of communication, our politicians has come up with a new law that grants the FRA access to all Internet and telephone communication that crosses Sweden's borders.

Many people has seen the problems with this new situation. FRA is an organization that is impossible to subject to efficient regulatory oversight, and with vast amounts of personal data being collected it is obvious that invasion of privacy can happen and probably will happen on on a massive scale. Why? Because FRA works in secret and their continued existence is conditioned on their ability produce interesting information. So, my theory is that you can pretty much assume that FRA will do the things that are most efficient to get information about criminal or suspicious activity, regardless of wether it invades someone's privacy or not, and regardless of what the official FRA rhetoric says about the right to privacy.

What is the most efficient information gathering techniques you can use with massive amounts of internet traffic? I believe the answer is by profiling individuals. Find out what websites you visit, find out who you send emails to. Who are your friends on Facebook? If we assume that FRA does not have any limits internally as to what it does with the information it collects, my guess is that all political activity that is considered somewhat extreme will be investigated, and not only the people actually members of suspect policial parties but also their friends, neighbours and relatives. Also, it would lessen the efficiency of the system to discard user profiles that the organization finds no use for, so everything even remotely interesting will be saved and can be revisited if a suspicion arises sometime in the future.

Does this sound scary? Well, I think it is, and that is why I advocate the use of cryptography for all types of communication, as often as possible. The history is full of examples of governments that has gone from good to somewhat abusive to totalitarian and evil. The internet activity that seems innocent now might not be seen as innocent in the future. Done right, the use of cryptography can bring a great deal of protection from eavesdropping to internet users. So, please do.