I promised an update to address poor passwords after discussing multiple instances of “12345” being used on a Syrian email server.
Passwords are everywhere. You need them to log into your operating system, websites, email servers, etc.
….and they are terrible from a security standpoint. Yet there’s not really a better option for user authentication. So how can we reduce password insecurity?
At the OS-level, password complexity rules should be enforced. In a Windows environment, this is a single setting that ensures users choose passwords that contain a mix of capital letters, lower-case letters, digits, and special characters. There are some other restrictions as well, preventing the user name from being part of the password and restricting password reuse.
In a Linux environment, we have PAM (Pluggable Authentication Modules), a flexible framework that allows you to control how passwords and authentication are handled. Combined with cracklib you can validate passwords against a dictionary of common, easily cracked passwords. So, even if something technically meets your complexity requirements (PassWord123!) you can still block it.
Windows can also get this sort of control, but it is a bit more involved. As I mentioned above, there is just a single setting to enforce password complexity rules. When enabled, that setting uses the default Windows password filter included in the OS. If that doesn’t give you enough security, a custom DLL can be coded and hooked into the Registry.
Of course, having a decent password to login to your system doesn’t help you if your email password can be hacked. On a Linux server, we go back to PAM. Any application can be written to utilize PAM, so find an email server where you can control the password security. If you are running the mail server on Windows, you have to hope the vendor has methods available for you.
Re-examining the dump that started all this, I have to wonder what Anonymous is actually presenting here. Is the mySQL query the results of something run directly against the mail server, or did they get a list of hashed passwords, crack them, and load the results into their own database?
The presence of one or two decent passwords in that list lead me to think they weren’t cracked, which would mean that these were stored as plaintext in the database.
I’ll gloss over the fact that passwords should all be hashed and salted, since that’s off the topic at hand.
To enforce better passwords stored in a database, we could create a trigger to check against a dictionary before committing the row. So, when a user sets their password, an update or insert query is generated. Before that update is processed, a function runs to check the password and gracefully fails if the password isn’t up to snuff.
In a properly secured database this gets a bit tougher to implement, since the query should contain a hashed and salted value. Theoretically, the database trigger could take the salt value for the user (which is stored elsewhere in the database), then compare the value in the query to the dictionary by applying the salt and hashing. However, depending on the size of the dictionary used, this could require too much computing power to be reasonably performed every time a user updates a password record.
To close, I’ll link XKCD’s take on what makes a good password.