Linux System Administration: A User's Guide
The reason for a good password goes right back to my description of the password file earlier in the book, specifically as it relates to the password field in nonshadow files. Here's a quick reminder of the format:
The password field (field 2) is encoded by virtue of a hashing algorithm. If you are curious as to the gory details, type <@cxb>man crypt<@$p> and you'll find everything you ever wanted to know about encoding passwords. The short form is this: that strange password is actually a coded version of your password based on a two-character, randomly generated salt. This salt is then used to seed the hashing routine to generate the final group of characters.
The term hashing represents a technique for taking a string of characters (a person's last name, for instance) and generating a unique key (ideally) for easy retrieval of the information from a database. What you are doing is encoding the normal text into a shorter, (usually) numeric representation.
Password crackers figure out passwords by using that salt to generate passwords against every word in the dictionary. While this sounds pretty complex, it's not. A simple program calls the crypt routine, runs the hash on a word and then compares it to the password entry in the /etc/passwd file. If it matches, bingo! They have your password. If it doesn't, they move on to the next word. On a reasonably punchy system, it doesn't take all that long for crackers to work their way through every password in the book.
Don't believe me? Take a look at the output in Figure 1 from a little program called Nutcracker, a freeware tool that does the kind of brute-force password checking I was talking about.
As you can see in Figure 1, picking something you'll remember easily because it is a common word is a bad choice for a password.
Have a look at what happens when I log in to a machine. Everything looks normal. I have a login name, a request for my password. I enter the password and voilà, I am in. But hold on—read that little one-line message that appears after I enter the password:
login: mgagne Password: Last login: Mon Jan 8 16:00:39 from energize
What the heck is “energize”? Energize is the hostname of the computer from which I last logged in apparently, except I don't have a system called energize. Furthermore, let's pretend that I don't know anyone with that system and I always log in from the same place. The only explanation is that somebody from a system called energize logged in to the server with my login name and password.
This is just a hypothetical situation, but it does illustrate one other habit that you should consider training your users to adopt. If they are logging in from the same PC day in and day out, that message should never change. If they do not recognize the hostname in the last login message, they should make it a policy to alert you.
Security isn't just the domain of the system administrator. After all, you've got plenty on your hands. Any help is appreciated. You need to get the users involved. Let them know that system security is their business as well as yours.
Marcel Gagné (email@example.com) is president of Salmar Consulting, Inc., a systems integration and network consulting firm and the author of Linux System Administration: A User's Guide, published by Addison-Wesley.
Webinar: 8 Signs You’re Beyond Cron
11am CDT, April 29th
Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.Join us!
- March 2015 Issue of Linux Journal: High-Performance Computing
- Not So Dynamic Updates
- April 2015 Video Preview
- Users, Permissions and Multitenant Sites
- New Products
- Flexible Access Control with Squid Proxy
- Security in Three Ds: Detect, Decide and Deny
- Non-Linux FOSS: MenuMeters
- DevOps: Everything You Need to Know
- Tighten Up SSH