Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I have recently developed a new web application which our clients log into using a username and password. As we're just rolling out this system, we'll be setting the usernames and passwords ourselves, the client will not get to decide what their initial password will be.

So I need to assign a password to each of our clients.

The trouble is that my boss wants it to be easy to remember. He suggested using 'apple', 'orange', 'banana', etc. This would leave us at huge risk of a dictionary attack and, seeing as the application can display some sensitive information, this would be a concern.

In a perfect world, the passwords should be around 6-8 characters in length, easy to remember and not include spaces or special characters. But they also need to be secure.

What is the best way to go about this? I've seen the xkcd comic regarding random words for secure passwords but, if I shorten the idea from four to just two short, random words, would this be secure? How secure would a password generated from this site be?

My chosen solution: as per Terry's answer, I am going to allow users to change their password themselves as I believe this is the best course for us.

share|improve this question
    
I'd strongly question the “easy to remember” requirement. It's a web app, why would anyone remember their password? –  Gilles Sep 18 '12 at 19:29
add comment

5 Answers

up vote 10 down vote accepted

What exactly is the issue with a completely random password?

Auto generated passwords should be changed by your clients upon first login anyway, so there will not be an usability issue. It is not a good practice for your clients to retain the initial password, as it would have to be sent to them in a plaintext format. For that purpose - one time login tokens would be much more secure.

A password containing two dictionary words IS NOT secure. A simple dictionary attack trying out various combinations of words would easily crack your password.

share|improve this answer
2  
Exactly - only make passwords easy to remember if you want users to keep using them. –  bethlakshmi Sep 18 '12 at 12:57
    
This is a good response. Thanks. My boss is simply prioritising usability over security and thinks username/password combinations should be easy to remember. –  bobble14988 Sep 18 '12 at 13:37
add comment

Using several words instead of a single password is actually a good idea, but only because there are so many possible words available. You can calculate the possible combinations yourself:

Random characters:
26 characters in alphabet ^ 8 places = 2.0E11 combinations
52 case sensitive characters ^ 8 places = 5.3E13 combinations

Sentence with words:
135'000 words in dictionary ^ 4 places = 3.3E20 combinations

This leds to following important points:

  1. You need a dictionary that is large enough ("apple", "orange" and "banana" is a joke of course)
  2. Use enough words, 4 seems necessary to me, especially if your sentence should be readable (smaller groups with substantives / verbs).

If you create readable sentences, they can be a bit longer without loosing the advantage of easy remembering. "The dog jumps over the blue fence" is not harder to remember than "dog fence over blue".

share|improve this answer
add comment

Here is a type of password that is "reasonably" robust and yet "reasonably" easy to remember and type:

Select two random lowercase letters, then two random digits, then two random uppercase letters, then two random digits.

The lowercase/uppercase mix and the digits allow such passwords to be accepted by most "password rules". The entropy of such passwords is about 32 bits (because 262*102*262*102 = 4569760000, which is slightly above 232). That's not a lot, but sufficient to thwart online dictionary attacks (when the attackers tries to log on your server by "guessing" the password, possibly with a script). They offer non-negligible resistance to offline dictionary attacks (e.g. for a password-encrypted file, or the storage of hashed password in a database) IF (and only if) they are employed with proper password-strengthening techniques, i.e. salts and slow hashing (bcrypt).

It turns out that I find such passwords easy to remember. There are relatively convincing indirect clues that I am a human being and that my brain works, at least qualitatively, along the same lines than any other human being, including "managers". Thus, it is plausible that your manager would find such passwords easy to remember as well.

Important: when I say random, I mean it. Appropriate randomness cannot be achieved in the privacy of a human brain. You shall:

  1. use a computer to generate random digits and letters;
  2. within that computer, rely on a cryptographically secure PRNG (e.g. /dev/urandom on Linux/FreeBSD/MacOS X or CryptGenRandom() on Windows);
  3. accept the password. Don't generate a hundred passwords until you reach one which pleases you, because this reduces your entropy. Generate one password and learn it.

Ideally, we would not let users choose their own passwords; we would provide a tool which generates passwords for them. Depending on the situation, securely transmitting the computer-generated password to the human user could prove challenging, which is why we are not always in the ideal case.

It seems overly optimistic to expect average users to use and remember passwords with an entropy of more than 32 bits or so.


If your manager is not cooperative, there is an alternate plan: tell him to write down his password on a piece of paper, and keep that in his wallet. A wallet is relatively secure: at least, he takes care of it on a daily basis. This takes care of the "easy to remember" part, at least for the first days. Also, that's what the US president does for some of his nuclear launch codes (be sure to let your manager know that, too).

Do not enforce a rule of changing the password every month: such rules are irksome and they turn users into enemies (i.e. more or less voluntary accomplices for the attacker).

Make sure that users know that they should report loss of passwords promptly and that they will not be blamed. Realistically, once you have more than a dozen users, a password leak will occur (regardless of whether the password is stored in a wallet or in a brain). The only thing worse than a leaked password is a user concealing the leak out of fear of a sanction.

share|improve this answer
add comment

The trouble is that my boss wants it to be easy to remember

Then ask him how he quantifies that and how easy it should be to break in to the system.

Answer has now been accepted, however there are major issues that nobody is addressing. Yes passwords should have adequate entropy to prevent them being brute forced, however as the application developer that's not your only way of protecting the system. You should add additional controls to limit the frequency with which a particular account attempts to log on - and probably limit the number of failed logins for an account, and from a specific remote address - which also implies a reporting mechanism and a means of unlocking.

As per the accepted answer, you should NOT be picking passwords for users. By all means generate an initial password - but your application should force the user to change it at first logon to something which meets your complexity requirements but which the user can remember. If this is a public facing service, then better to use openid.

share|improve this answer
add comment

If you say 6-8 characters I would choose 8.

The maximum security for a password with only lowercase letters and numbers but still easy to remember would be this:
Use vowels and consonants altering, so the password is always pronounceable.

In php this would be the function:

function generate_pass(){
    $b="euioayj"; // counts as vowel
    $v="qwrtzpsdfghklxcvbnm1234567890qwrtzpsdfghjklxcvbnm"; // count as consonants
    $blen=strlen($b)-1;
    $vlen=strlen($v)-1;

    do{
        $pass=$b[rand(1,$blen)].$v[rand(1,$vlen)]. 
        $b[rand(1,$blen)]. $v[rand(1,$vlen)]. 
        $b[rand(1,$blen)]. $v[rand(1,$vlen)]. 
        $b[rand(1,$blen)]. $v[rand(1,$vlen)];
    } while (!preg_match('/\d/',$pass));
    return $pass;
}
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.