Implementation Notes on MD5 Authenticator

These are some implementation notes on the MD5 Authenticator and its relative security. They assume you have a basic understanding of security and cryptography principals.

If you use the MD5 Authenticator, then passwords are stored in the database as a hash. Anyone who can obtain access to the database containing the passwords could conceivably determine the User account password by using a dictionary of hashed passwords. The way this works is the bad guy has a dictionary that contains "ABC" in the dictionary; he has the pre-computed hash of "ABC" which translates to 13232312312312312aa. When the bad guy gets a database with a hashed password of 13232312312312312aa he finds that hash in his dictionary and then reads across to see the password is "ABC" and can now login. Good password selection can mitigate this risk.

Passwords sent to the system for authentication are hashed with a seed value. To pickup passwords on the network, the attacker would have to generate a dictionary using the exact seed value. This makes dictionary generation computationally difficult but not impossible. In other words to perform a dictionary attack of network traffic, the hacker would have to create a dictionary of hashed passwords using the seed value as part of the hashed password. Since the seed changes on every login, it would be difficult.

The seed used is the system clock time and the system verifies that not more than 30 minutes have elapsed since the seed's creation. This means that a User cannot access the system using a replay attack after 30 minutes have elapsed.

Passwords are sent as plain text when the User uses the change password screen.

If you still have concerns about security, then we recommend that you use the MD5Sum or LDAP Authenticator in conjunction with an SSL certificate.