Novell Home

Choosing Passwords

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 2 Jun 2005
 

Here are some readers' tips on choosing passwords. For more information on this topic, visit the Novell Wiki on "Talking Passwords" at:

http://wiki.novell.com/index.php/Talking_Passwords


A reader asked:

I wanted to gauge people's opinion and current setups for password policies. We are about to roll out Universal Password - our current policy is 6 characters, 42 days reset, no duplicates and 6 grace logins.

Although we can be clever with advanced universal password rules, we want to provide a better level of password security without creating more helpdesk calls due to overly complex policies. So we don't want a 26- character, dictionary proof password with at least 7 forms of punctuation 3 capital letters and 5 digits that needs to change daily and never repeat, ever.

What is the best mix of security and complexity? What is your policy?

We also want to use self-service password resets. The users answer a set of questions that can be used to reset all passwords within the meta-directory. However, most suggestions I've had are either obscure (what did you have for lunch on January 12, 1982) or obvious (what color is your hair?).

What are good questions to ask users? What you do you ask them?

... And here are responses from Forum readers on this topic:


Reader 1: I would consider what is at risk should a password be lost, and I'd base my password requirements on that. For instance, the janitor shouldn't need to have a dictionary-proof password unless he/she uses that password to open doors all over the organization.

Similarly, people with the most power over the computers (probably you and your comrades) should be required to have better passwords. Of course, the stronger passwords you have throughout, the better, but I believe it should be part of YOUR job to have a better (more-secure, non-written, regularly-changed) password. If I get your password and find an open ssh port somewhere, what can I NOT do?

With that in mind, if you go to Universal Password, understand that you can create multiple policies and apply them to different parts of your tree. For instance, on the Login Policy Object you can apply a standard policy that, unless overridden, will apply to your entire tree. It could be something like a 9-character password that is case- sensitive (they are by default, I think, when you use UP), with at least two non-alpha characters (numerals, special characters, etc.) that expires once every other month.

As you get into the network administrator's container, either apply the policy directly to the parent container (direct parent, no grandparenting here, please) or directly to the powerful users. These would be your 17-character (prevents LANMAN hashes in Windows) password, expiring monthly, with at least three non-consecutive numeric characters, no dictionary hackability, and at least one special character. Anyway, I don't feel too bad asking these of administrators, because they are supposed to be a cut above the rest. Using some techniques these things can be fairly straight-forward.

So is "iJmAsSmAm" a good password? Is it tough to remember? What if you threw in a random number at the end of it, like 69? iJmAsSmAm69? The following line may look familiar to some, and it explains where the password came from (1969 was the recording year, or so I'm guessing, from a Google search that I did not look at thoroughly) ...

"I'm just mad about saffron, saffron's mad about me."

Anyway, passwords don't have to be hard, they just shouldn't be easy to guess. As for the questions to ask to get a password back, you can have any number of mandatory questions needing to be answered. You can also set up Challenge/Response to require one (or more) random questions (that have been filled in before). So, you have 5 required questions that everybody would always get, and 2 of 5 others that would be selected at random. Ten questions would take about 2 minutes to answer. Classics exist and are fairly good. You can elaborate on those to make it just a bit trickier.

  • Mother's maiden name
  • Maternal grandmother's maiden name
  • First kissed by
  • First date (firsts seem to be a pattern here...and they're memorable, and not terribly guessable, really)
  • Favorite town ever (real or imaginary)

Passwords are important, to be sure. It only takes one to get inside a network, but you have to make life reasonable to users so they don't do stupid things like writing passwords and sticking them under their keyboards, or using easy passwords. Technology can help, but don't be afraid to put together a quick presentation with some ideas about how to create and remember passwords.

One thing I've found to be useful is a utility that makes pronounceable "words" - not things that show up in the dictionary; something like apg (http://www.adel.nursat.kz/apg/) might be useful.


Reader 2: We have just gone through this process ourselves. There are many different views in our organization about acceptable policies and getting the balance. For the record, our questions are:

  • Who was your childhood best friend?
  • What was you favorite childhood holiday destination?

We have also allowed a third user-specified question and suggested using:

  • What was the name of your childhood pet?
  • What was the name of your favorite school teacher?
  • What is the first line of your favorite song or poem?

The problem with using questions like mother's maiden name is that there are cultural differences that may make this question invalid. Also, it is a common question used in banking, and some users may feel nervous about handing out this info to their employer, even if it's encrypted. Finding questions that everyone in your organization can answer and that no other person will know is a real challenge.

We decided on 3 questions, because a well-known consulting company recently researched the issue and found that 3 well-formed security questions were safer than a normal user password. They argued that the chances of 3 questions being breached was in the order of 3%, whereas breaching a normal password is a 5% chance. Don't ask me how they came up with these figures, but it was enough for us to get it approved. This is all subject to the policies you put on your password, I suppose.

Our current password policies are:

  • Min. Password Length = 6
  • Periodic password changes =
  • 60
  • Require Unique Passwords = Yes
  • Intruder Lockout = 3 attempts, 2 day lockout

By the way, in case you didn't know this, Intruder Lockout applies to password reset attempts too, so don't be too worried about users trying to guess other users' security questions if you have this set. But it could create a bit of helpdesk work if you have a problem user deciding to try and guess his manager's questions.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell