[Previous entry: "Busy day in geekly"] [Main Index] [Next entry: "Hax0r Handl3!"]

04/28/2003 Archived Entry: "The weather is here, wish you were beautiful!"

Jen has a t-shirt with that saying on it, it's a good reminder to pay attention to veiled insults. By the way, I like the way you did your hair before!

Geek stuff: I'm in a situation where I've got to allow a whole bunch of users to change their password. I don't want to set up something web-based due to security concerns. I've looked into making their shells /usr/bin/passwd and setting up an ssh client on a machine in their office. The difficulty is the limitations on what they can change their password to by using that program.

From the man page for passwd:

passwd will try to prevent you from choosing a really bad password, but it isn't foolproof; create your password wisely. Don't use something you'd find in a dictionary (in any language or jargon). Don't use a name (including that of a spouse, parent, child, pet, fantasy character, famous person, and location) or any variation of your personal or account name. Don't use accessible information about you (such as your phone number, license plate, or social security number) or your environment. Don't use a birthday or a simple pattern (such as backwards, followed by a digit, or preceded by a digit. Instead, use a mixture of upper and lower case letters, as well as digits or punctuation. When choosing a new password, make sureit's unrelated to any previous password. Use long passwords (say 8 characters long). You might use a word pair with punctuation inserted, a passphrase (an understandable sequence of words), or the first letter of each word in a passphrase.

These principles are partially enforced by the system, but only partly so. Vigilence on your part will make the system much more secure.

The difficulty is that there is very little that apparently can be done to choose the restrictions for the passwords that are chosen, and I just KNOW there will be users that will absolutely refuse to choose passwords that are a mix of lower case, upper case, number and punctuation. If they do choose one, they will rapidly forget it. So I'm kind of stuck. Any thoughts?

Replies: 5 comments

That'd be a matter of trusting myself not to completely screw it up :) Posted by Greg @ 04/30/2003 09:16 PM PST

Don't forget that on most systems, the password is actually stored in shadow, and is only root accessable, preventing any CGI from directly manipulating it unless you change the access rights (DON'T DO THIS) to the shadow file. The whole point of the shadow file is to prevent non-root jailing so that you can't brute force the pwd, etc. If you have to change the password, I would recommend that you simply write a web-enabled script ran over SSL that can also use Apache's limit and directory access directives to give some level of control of WHO can even see/get this page. (ie: Only allow it from the local network etc). Through that, you can write a CGI that would calculate the entropy as the user enters in the pwd and force them to use something half decent. Here is why. The effective bit length of a random password is log2(n^m), where n is the pool size of valid characters and m is the length of the password. By forcing the user to use a larger pool with a larger password, you get a more effective password. Here is a snippit in C/C++ to handle this: double entropy_bits( double pool_size, double pwd_size ) (      return log(pow(pool_size, pwd_size)) / log(2); ) int main() (     printf( "%f", entropy_bits( 93, 8 ); ) From that you can get the relative strength of the password.(hold that to guessable passwords etc) As an example, if the available pool of characters is 93 (which would be case-sensitive alpha, numeric and punctuation chars) you need 9 chars to create the equiv of a 56-bit key, and 20 chars to generate a 128-bit key. As you can see, this is why we are moving to more of a passphrase scenerio for crypt to make it that much harder to crack. Anyways, back from that tangent, once your script can force 'somewhat' of a good password, you could communicate to the system (by SSH to localhost as that user) and use an expect script to actually change the passwd. Off the top of my head, the expect script would look SOMETHING like this: #!/usr/bin/expect -f set timeout 5 gets stdin username gets stdin oldpwd gets stdin newpwd # Can't remember how to concat in expect... the $username may need tweaking spawn "/usr/bin/ssh" "$username@localhost" expect ( "ssword: $" ( send -- "$oldpwd\r" ) ) expect ( "ast login: " ( send "/bin/passwd\r" expect "password:" send "$newpwd\r" expect "password:" send "$newpwd\r" ) "ogin incorrect" ( exit 1 ) timeout ( exit 254 ) eof ( exit 253 ) ) # End expect script Of course, that script isn't tested at all, and could easily be wrong, but you get the idea. Something to check here would be if the username/pwd is shown in the process list as expect is running. You might need to do some argument hiding to prevent that if its the case. But alas, this should give you a good place to start. One final note. If you REALLY don't want to force better passwords (which I HIGHLY DON'T recommend) you can modify the /etc/logins.def to tweak it to what you will accept. I must be cander, I think this is the wrong approach. IMNSHO - The weakest link is the human factor, and if you make it EASIER for them to circumvent good passwords, the rest of your system is shot. You would be better to make a more userfriendly web page to guide them through the process than to accept weaker passwords. I would recommend the use of passphrases etc, and you could even show the user the text from the man pages for passwd and "Hints for user passwords". And I quote: Hints for user passwords The security of a password depends upon the strength of the encryption algorithm and the size of the key space. The UNIX System encryption method is based on the NBS DES algorithm and is very secure. The size of the key space depends upon the randomness of the password which is selected. Compromises in password security normally result from careless password selection or handling. For this reason, you should not select a password which appears in a dictionary or which must be written down. The password should also not be a proper name, your license number, birth date, or street address. Any of these may be used as guesses to violate system security. Your password must easily remembered so that you will not be forced to write it on a piece of paper. This can be accomplished by appending two small words together and separating each with a special character or digit. For example, Pass%word. Other methods of construction involve selecting an easily remembered phrase from literature and selecting the first or last letter from each word. An example of this is      Ask not for whom the bell tolls. which produces      An4wtbt. You may be reasonably sure few crackers will have included this in their dictionaries. You should, however, select your own methods for constructing passwords and not rely exclusively on the methods given here. Well, thats enough rambling on about this. Hopefully this is a good start for you. Good luck. P.S. This commenting system is REALLY harsh man. You gobbled up my nice formating and everything. :) Posted by SilverStr @ 05/01/2003 08:41 AM PST

Thanks for that, that's got me in the right direction anyhow. I wish login.defs had more options...the only one applicable to the password strength is PASS_MIN_LEN. I'll probably let those users muddle through and pick a password based on the normal criteria. Which means I'll likely just set their shell to passwd until they change it, then back to /bin/false. One thing to note is that no matter what they pick it will be better than what is currently assigned to them (which occurred previous to my being hired). It's really that bad, and all users have the same. : Posted by Greg @ 05/01/2003 08:47 PM PST

i've found that the periodic table is actually a really good source of password stuff. Take Sodium and Chlorine, for instance. Sodium is chemical symbol Na, and number 11. Chlorine is chemical symbol Cl and number 17. Mix the numbers and symbols, and you could get 17Cl11Na or 11Na17Cl or Na11Cl17 or Cl17Na11 or.... it gives a mix of upper and lower-case letters, and numbers, AND isn't a total pain in the hind parts to remember :) Posted by cybergeek @ 05/01/2003 11:45 PM PST