Passwords are a constant source of problems in my organization. They're irritating, they're obtrusive, they're constantly being forgotten, and they don't even provide a good level of security. Long-term, I'm trying to replace our Windows passwords with smart-card access, but until that happens, we've got to cope with passwords.
Our current problem is at our help desk. When Joe User forgets his password, all he has to do is call the help desk and they'll reset it for him. You have to offer this service - legitimate users are forever forgetting their passwords, and you have to have a way to let them back into the system.
This Week's Glossary X Window System: A multitasking, windowing graphical user interface program that runs on a Unix host for communicating between X terminal devices and Unix host systems. X terminal: A terminal connected to the X Window System that presents a window-based user interface to the user and allows the user to access multiple applications at the same time. For the more technical reader, here are the details of three security risks that our scanner identified on four of our systems, with information about how to remedy them: • A remote host shouldn't allow trusted access from the scanning machine. This trust may extend to other inappropriate machines as well. Examine the .rhosts file and ensure that it contains a list of only those machines that should be trusted. • Open X Window displays allow an attacker to capture keystrokes and to execute commands remotely. Many users have their X server set to "xhost +," permitting access to the X server by anyone, from anywhere. Either issue an "xhost -" command to deny access to everyone and selectively allow only trusted hosts to connect with xhost + commands, use a cryptographically secure authentication protocol such as xauth, or remove X Window. • The inverse query feature supported on some domain name servers (DNS) shouldn't be used. An attacker can use this feature to obtain a zone transfer. Zone transfers identify every machine registered with your DNS and can be used by attackers to better understand your network. The zone transfer occurs even if you've disabled zone transfers on your server. Configure your DNS to disable inverse queries. |
But what's to stop me from calling the help desk pretending to be Joe User and getting someone to reset his password and tell it to me? Not a lot - as long as I can convince them that I'm Joe User, they'll tell me his password. They have to.
Despite all the fuss you hear about choosing strong passwords, in my experience, few attacks depend on exploiting passwords that are easy to figure out. Many attackers just call their target's help desk and get them to do the dirty work. That's called "social engineering;" it's a common attack strategy.
Authentication Challenge
To get around this problem, we need to get the help desk to make sure it only gives out passwords to the right people. In other words, we need to authenticate password reset requests. Well, we already have a simple way of authenticating users. We give them passwords -which they forget. Our help desk is much more professional about this than most, but it's still a difficult problem.
I've been looking for an easy, practical solution to this problem for a while, but when I asked a large group of technologists in our office for suggestions, I got all the predictable responses.
We could identify them by their Social Security numbers, but the numbers are publicly available. We could make them go to the help desk with an identification card, but some users work hundreds of miles away from the help desk.
Get their managers to send e-mail? The managers won't stand for the added hassle, and it's not that easy to keep track of who works for whom.
The heart of the problem is that there are only three ways to authenticate a person: by something you know (such as a password), by something you have (such as an ID card) or by something you are (such as your facial features). So once your initial shared secret (that is, the password) is forgotten, you have to rely on either another shared secret - a backup password - or on one of the other two authentication mechanisms: something you have or something you are.
If a user forgets one shared secret he uses every day, he isn't likely to remember a backup password. The only ways around that that I know of are writing it down or making it easy to figure out. Writing down passwords is a very bad idea: If you can read it, so can someone else. And if it's easy to figure out (like your Social Security number or mother's maiden name), then it's easy for someone else to figure out.
So that reduces it to something you have or something you are. But unless you're at a very small company, these tend to be expensive solutions that are difficult to manage.
This time, however, someone came up with a simple, practical, cheap solution: Get the help desk to leave the new password on the user's voice mail.
Access to our voice mail is protected by a personal identification number (PIN), so access to a user's voice mail should, in theory, be restricted to that user. Of course, a user can easily forget his PIN, but the chances of him forgetting both his PIN and his password at the same time are relatively low. And the slight hassle of having to access voice mail might make users think a little harder about their password before calling the help desk.
Basically, it's authentication based on another shared secret, but it's one that users should be able to remember if they use it often enough. This solution isn't 100% secure, but it's better than what many companies have (nothing), and it should be easy to implement.
Security Scanner Goes Live
We ran our first live security scan using Internet Security Systems Inc.'s (ISS) Internet Scanner this week, and everything went like a dream. For months now, we've been going through the process of getting the hardware, configuring policies, running test scans and convincing our engineering team to let us at their prized live networks. The team finally accepted that the scanner wasn't going to bring the live networks crashing down around its ears and gave us the access we needed.
Internet Scanner is a simple tool that scans IP addresses looking for servers, then identifies any visible security vulnerabilities on those servers. It's ISS's simplest and oldest product, and it's also its best.
The scan took a total of 20 minutes to try every nonintrusive test it knew of on eight machines. Running the scan was just a matter of plugging our laptop into the target network, giving it a new IP address and pressing the start button on the scanner. That's the sort of ease of use that I approve of.
The application gave me a neatly formatted report - available either on-screen, in HTML or in Microsoft Word format - detailing every vulnerability it found, the potential consequences of each vulnerability and how to fix them. Of the eight machines on the network, two refused to let the scanner find out anything about them at all - not one vulnerability was found. The two routers turned out to have just one vulnerability, which is a very good result.
We also had three Windows NT machines with a few technical vulnerabilities that we already partly knew about, but the real find was the eighth machine, a Sun Solaris box that was riddled with security vulnerabilities. In fact, the scanner showed two technical vulnerabilities in the box's X Window System - and the owner of the box didn't even realize the X Window System was installed.
The cooperative system owner and system administrator had the box fixed within hours - definitely a good result.
Now we need to start ramping up our scanning efforts and covering more of our network segments. I hope they'll all be this easy.