Password Security

From CS Support Wiki
Revision as of 14:41, 27 October 2008 by Jpr9c (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

A user recently submitted a request inquiring about password strength in our department; the reply touched on several general security questions, so it is included below as the basis for a FAQ on this issue. We will update this page as time permits:

> I recently mistyped the tenth character of my password into a CS department
> Linux box and was allowed in without complaint.  A little experimentation
> revealed that only the first eight characters of my password made any
> difference; the rest could be omitted or replaced with anything I wanted.
> This is typical of the old DES encryption scheme;

Yes, that's correct; we generate DES passwords by default.  The linux
boxes use a Solaris NIS backend, and default encryption on Solaris is
still good old DES.  We have allowed our passwords to remain this way.  Even 
if you have an MD5 password (which the NIS server will store), the hash 
is generated using only the first 8 characters.

> is there any chance we could use something stronger (even MD5 would do)
> so that I may use a pass phrase instead of a pass 8-character-string?

No.  In short, MD5 is no better:

> If not, might I suggest you inform users that only the first eight
> characters of their password are used so they can ensure that that
> substring is hard to guess?

Well, we have done that in the past, when the brute force attacks on DES
became easily feasible and with the growth of Linux (and it's default of
MD5) in our environment.

However, the focus on encryption strength alone in password policy, is
akin to using a screen door latch on the kitchen door around back, while
insisting on a time-lock deadbolt on the front door.  Any semi-effective
password policy must include short lifetimes, and, at a minimum, libcrack
checks against the dictionary.  The political will does not exist in the
department to tolerate the hassle factor.

Here's what I do and I suggest you do - stick with your passphrase - that
has always been the very best mnemonic for difficult strings anyway - and
use that phrase to generate a string.

For example, one of our old (now discarded) admin passwords is "tdsotm"  
taken from Pink Floyd's "The Dark Side of the Moon".

I would encourage where possible to incorporate non-alpha characters as

We have decided, for the longer term, to view passwords as inherently
insecure; our most recent major exploits (captured dept. systems) have
been accomplished with the use of keystroke loggers on vulnerable hosts.
The "hijacked" accounts are then used to launch privilege escalation
exploits, and that's pretty much the whole ball game; our systems are, by
design, very vulnerable and transparent to users.  We are moving to
replace passwords altogether with the use of certificate- and
asymmetric-key- based security.

If you are deeply concerned, you can harden your own account by simply
modifying your own .ssh/ssh_config to require the use of key-based
authentication (disable keyboard-interactive), and generate a key-pair  
which requires a passhrase  as well.  This will limit password-based
authentication to 'console' sessions.