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: http://www.schneier.com/blog/archives/2005/06/more_md5_collis.html > 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 well. 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.