6

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.

1
  • 1
    I'd strongly question the “easy to remember” requirement. It's a web app, why would anyone remember their password? Commented Sep 18, 2012 at 19:29

6 Answers 6

14

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.

2
  • 2
    Exactly - only make passwords easy to remember if you want users to keep using them. Commented Sep 18, 2012 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. Commented Sep 18, 2012 at 13:37
4

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".

1
  • It's taken me a long time to read this (excellent) answer but I just had to comment to say using 'apple', 'orange' as client's passwords was not a joke. Thankfully, the guy who suggested it is no longer my boss. Commented Oct 5, 2014 at 6:37
3

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.

3

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.

2

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;
}
-1

Create an universal word/password. Eg: 12howareyou

Then add to it the name that first comes to you about where you need the password. Eg: stackexchange12howareyou or 12howareyoustackexchange. For this last example, if you know the universal password by heart you will be able to type it very quickly. Looking at the website title, or the url, or something else, you will know the rest of the password, just need to add it.

12howareyoureddit

12howareyougmail

12howareyoumicrosoft

12howareyouSOMEWORDABOUTTHEPLACEWHEREYOUNEEDIT

This way you will always know the password (one part of it you already know, the other part you can easily know), and nobody can find it as they don't know the universal word/password neither where it is (after, before the websitename),

2
  • I'm pretty sure that many people use innovative schemes that make it easier to remember passwords. However... One of the reasons to advocate strong passwords (= long, unique, complex passwords) is to make it hard for a defender to crack the passwords by bruteforce. Whenever you use an algorithm (such as yours), you run the risk of reducing the bruteforcing effort significantly. When millions of users start doing this, even a few possibilities factored in by attackers will have high probablility of succeeding against some users. Why not use Password Managers?
    – Sas3
    Commented Aug 6, 2017 at 2:00
  • Misguided advice in general, but also completely unrelated to the question which is asking about generating passwords on the server to assign to users. This answer is (bad) advice about how a user can choose their own password.
    – Ben
    Commented Aug 7, 2017 at 15:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .