Keepass Password Generator

With the increasing password complexity demands in both online and offline services, you basically can’t live without a password manager. Personally I use 1Password, but at work Keepass is recommended. Main reason is that it remains local (no passwords in the cloud). Downside is that you need to have a proper backup in case of emergencies (or rely on decent password reset mechanisms.

Since a generic password scheme is obvious highly overrated, you basicalle need a different password scheme for every website, application or service. The worst being password schemes that limit the amount of characters to between 6 and 10…. Seriously? Others limit the amount of special characters like @\/’”| because of some fear of SQL injection schemes. Which is not a problem if you implement the backend correctly…. But that’s for another day.

Due to all these password challenges I had to reconfigure my Keepass (default) password generator to be a bit more friendly. For those bad password scheme website I have specific generation algoritms, and in a few cases the demands on the password are so ridiculous that I had to make a generator just for that service.

Anyway, the latest ‘challenge’ was that a service demanded a letter at the start and finish of the password, so that resulted in the following pattern:

L[uullddss]{22}L

This results in a password:

• Starting with a mixed-case letter (L), followed by a 22 character mix of at least

• 2 upper-case (uu) letters (ABCDEFGHIJKLMNOPQRSTUVWXYZ),

• 2 lower-case (ll) letters (abcdefghijklmnopqrstuvwxyz),

• 2 digits (dd) (1234567890),

• 2 printable special characters (ss) ( !"#$%&'()*+,-./:;<=>?@[\]^_`{|}~ ),

• and finishing with another mixed case letter (ABCDEFGHIJKLMNOPQRSTUVWXYZ abcdefghijklmnopqrstuvwxyz)

Note that the previous default password length was 22 character, so increasing it with 2 additional letters to 24, the password became a bit stronger. Otherwise the password would have weakened substantially, because the first and last character was one out of 52.

This results in the following preview:

View fullsize

When you need to communicate passwords, or manual type them (on another device) it might be helpful to exclude certain characters that (depending on the font) look alike (e.g. 1Il|, O0). This can be accomplished in the ‘Advanced’ tab of the password generator.

Note that excluding these characters reduce the complexity of the password (which can be corrected up to some extend by increasing the password length).

View fullsize

And in those weird cases where certain character are not allowed you can use the ‘exclude characters’ option in the screenshot above (make sure you increase the password length accordingly to maintain password security).

Choose Your Password (Language) With Care

When you want to use words / sentences in a password, it pays to use a non-English dictionary. Just check the Kaspersky blog on strong passwords., and try it for yourself.

View fullsize

The English word combination 'horse' and 'toad' are considered weaker than the Dutch equivalent ('paard' and 'pad'). 

View fullsize

View fullsize

Storing Plain-text Passwords

Security is a hot issue now-a-days. You get told over and over that no one will ever ask you for your password. Not your bank, not Paypal, and not even your online grocery store. This is to make sure that people won't be persuaded by phishers and other scumbags in giving them the password.

But why is it that a lot of companies and other initiatives on the Internet seem to store passwords in plain text in their databases? There is NO NEED to do this. Almost every hypertext scripting engine (ASP, PHP, Coldfusion, Perl, Ruby on Rails) supports the hashing of passwords.

COLDFUSION: <CFSET hashedPwd = HASH(password, "SHA-256") />

When a user logs in with a username and password, they are checked against the credentials in the database. The password gets hashed, and the hash is checked against the stored hash in the database. This way no one will be able to figure out the actual password (especially if a relativley strong hashing algoritme is being used like SHA-256).

If the same user forgets his/hers password you only need a mechanisme to reset the password to a random password, and communicate this with the user (by e-mail, SMS, snail-mail, or whatever) and allow the user to change this new password to one of his own at the next logon.

Another nice feature of hashing passwords is that the user can use a password with lots of printable characters (like !@#$%^&* (){{}|":;'\][/.,<>?`~), or complete sentences because these won't be stored. Only the hash (a hexadecimal string) will end up in the database. No matter how long the password/sentence is, the hash will always be a fixed length.

Maximum flexibility for the user, and a secure way of storing the passwords in the database. So if financial institutions or other high profile web-presences fail to do so, they should be made aware, and change their code.

So there's absolutely no need for anyone to be able to see your (plaintext) password besides yourself. And don't let them tell you otherwise.