We will soon be implementing a tougher security standard for encrypting passwords within the our events database. It should occur invisibly behind the scenes and I won’t bore you with the technical stuff, but if we do have any glitches, I’m going to honestly advise this is going on and quietly iron those out. Everybody loves a bit of improved security.
Those account managers and associates able to create user accounts or reset passwords, I am asking to set something a bit more challenging and individual. Here’s why.
There is a body of several thousand identical user passwords in our database at the moment – I can spot them at the database level, even though they are encrypted, and if I crack one, I get several hundred more accounts for free. So there are two things to do:
- Create user passwords which are longer, mixed-case, mixed character strings: “password1” is not acceptable, for reasons below.Good strong passwords are strings such as “ThursdayMay142015” or “A11_W0rk_and_N0_P1ay” or “England5_Germany0”If you want to go nuts, there is no maximum length so you could go “Royal.Borough.of.Windsor.and.Maidenhead…”
Just bear in mind that “EvidenceInformedPractice” (the organisation’s tagline) is too blindingly obvious, as is the person’s own name, “Thursday” and common words by themselves which might be included in a ‘dictionary’ attack.
- Since we’re going to tell folks what this initial password is, neither us or they need to remember it; you are also going to impress on them the need to change it to something they *can* remember when they next login. So an inconvenient initial password will encourage them to do that.Everyone has their own scheme for managing passwords, even if it is weaker than ours, and at some point we have to trust the customer to do right (even when they’re wrong).
Hopefully this will balance the need for security against the number of service calls we get. We shall see. RC
Related: How-to: Generate Good Passwords