Typical Password Mechanisms

   

---

Although there are almost as many different mechanisms in place for using and storing passwords as there are applications that use them, there are quite a few commonalities between the mechanisms.

Username and Password

Most password mechanisms require that you know both who you are and some token to prove that you really are who you claim to be. That is, you are required to provide a username and a password to confirm that choice. This is obviously useful in enabling the system to distinguish between different users, as many users can securely have exactly the same password, as long as none of them knows the others are using it as well. In a way, the user information can also be thought of as adding extra entropy to the password. If an attacker has to guess at both a user ID and a password, it's more difficult than guessing at the password alone. It's not a whole lot more entropy, and usernames almost certainly display even less entropy than dictionary words, but for every bit of additional entropy, a brute-force attack is going to have to try twice as hard. To make this additional potential entropy work for you, disguising the list of users on the system is necessary. With Mac OS X, this means turning off the iconic login window and making people type their usernames as well as a password. Users will initially find this bothersome, but in the long run it usually saves them time, as well as makes things just a bit more secure. If you have more than a handful of users on the system, it takes many of them a considerable amount of time to find their user ID in the login window scrolling list, and from observation, the frustration involved with this step is much greater than that involved in typing a user ID. It also means that you need to disable any services that might provide information to the network regarding what user IDs are available on the system. Finger is one of the primary culprits here, but NIS and NetInfo (covered in later sections of this chapter) are also potentially troublesome here.

Of course, if every system has a user named root on it, one with superuser capabilities, that's an obvious target for password attacks. Many systems therefore disable root login both from the network and the console. Users are allowed to su to root, but direct login as root is prohibited . This is a good idea as a general practice because root is typically a disembodied account with no specific person attached to it. Requiring users to su to root, rather than allowing root logins, provides an additional level of traceability of action because it prevents anyone from logging into the machine and anonymously using root powers.

Password Storage

Password storage schemes are wide and wildly varied. The worst store the password in plaintext form, doing only the most trivial job of hiding them from prying eyes.

The best encrypt the passwords well enough that they can't be decrypted at all from the stored value, providing only a one-way encryption of the information and necessitating brute-force methods to compromise the information. Remember, however, that no matter how carefully the passwords are protected, there just aren't that many of them, especially when people choose poor passwords with little entropy, and this makes the brute-force approach applicable to any scheme.

Plaintext Storage

As bad an idea as it sounds, a few programs are written in such a fashion as to store passwords in plaintext. Thankfully, these tend to be applications such as mail servers that hold user accounts as separate from system accounts. CommuniGate Email server from Stalker Software (http://www.stalker.com/CommuniGate/) is one package that can be configured to behave in this fashion. CommuniGate stores user IDs and passwords in files on a per-user basis, typically in the directory /var/CommuniGate/Accounts/ , where its behavior can be configured separately for each user. One possible configuration is storing the user ID and password as cleartext. For example, in the following configuration, the user jray's account is set to use the cleartext password mysecret .

 #  cat /var/CommuniGate/Accounts/jray.macnt/account.settings  {   AccountEnabled = YES;   LoginEnabled = YES;   MaxAccountSize = unlimited;   MaxWebFiles = 0;   MaxWebSize = unlimited;   Password = mysecret;   PasswordEncryption = clear;   PWDAllowed = YES;   RealName = "John Ray";   RequireAPOP = NO;   RPOPAllowed = YES;   RulesAllowed = Any;   UseAppPassword = YES;   UseExtPassword = YES;   UseSysPassword = YES; } 

For CommuniGate, the user IDs and passwords stored in this way are mail-account-only user IDs and passwords, so if the cleartext file is read without authorization, the only information the culprits get is names and passwords for mail accounts. This means that they could access and change user's email, but the system passwords that allow your real OS X users to log in are not necessarily jeopardized. We say " necessarily " because users have a bad habit of using the same password for multiple different accounts, and so they very well might have chosen the same passwords for their logins as for their mail. Necessityand system administrators working in its name don't do much to discourage this behavior at all by forcing users to change their passwords frequently. Experience indicates that a large fraction of users who have both email and system accounts will have chosen the same passwords for each.

This particular configuration is set up with cleartext passwords because this example system has a large population of noncomputer-savy users who require both dial-in and email access, and these needs are serviced with separate software solutions. The users really need to have everything made as convenient as possible, so mandating that they choose two good passwords for the system is impractical they're disinclined to choose even one.

We are, as they say, stuck between a rock and a hard place: If we synchronize the systems to make things easier for them, they have only one password, and both systems are vulnerable if one is compromised. If we keep them separate, but force them to make good passwords, chances are they'll make just two passwords, and swap them back and forth each time their password expires , which is probably worse than one good password. Overall, there's no good solution because, as you should be coming to understand, passwords are a poor solution to the general problem of proving that you are who you say you are.

Encryption

A better storage system for passwords, and the one that's typically used in Unix systems, is encrypting the password and storing the ciphertext . The encryption may vary between quite weak and very strong encryption, but the general purpose remains the same: to prevent people from using what they might see (if they were to look at the stored passwords) to guess what the passwords are. Sometimes, such as with the Digimarc 2-digit "PIN" key that was mentioned in the steganography section of the previous chapter, it makes almost no difference whether the password is encrypted because brute-force attacks against the system are so simple.

When the key is more complex, however, a strong encryption system can make brute-force attacks much more difficult to carry out. With the best of these systems, the encryption algorithm not only makes the password difficult (or better, impossible ) to decrypt, but also is computationally expensive, so as to make brute-force attacks impractical because of the time required to execute the attack. If the only route to a crack is through brute-force examination of every possible key, each additional bit of key length doubles the computational cost involved in discovering the key. Because of differences in exactly what different algorithms mean when they discuss key length, you can't take this as an absolute method of comparison between the strength of different algorithms, but it's a good first-order approximation .

In many cases, the authentication system is set up so that the stored password cannot (through any known mechanism) be decrypted. This may seem counterproductive, in that one wants to be able to compare the password provided by the user with the one that was stored. This comparison, however, can be carried out just as easily with the encrypted password. The user's password is stored encrypted, and the password entered by the user as he attempts to authenticate is encrypted, then these two encrypted values are compared. It is possible with some storage schemes (MD5 checksums, for example) that there are multiple passwords that hash to the same stored value, but finding a hash collision is no more likely than finding the correct password, so this is of only minor concern.

For example, the standard Unix password system stores user IDs and passwords in a plaintext file, which any users can read. The passwords stored there are encrypted through an application of the DES encryption algorithm (Chapter 4, "Theft and Destruction of Property: Data Attacks"). A typical password file might look like this:

 root:nA5oSdDy859bE:0:1:Operator:/:/bin/csh nobody:*:65534:65534:nobody:/: daemon:*:1:1:daemon:/: sys:*:2:2:sys:/:/bin/csh bin:*:3:3:bin:/bin: sync:*:1:1:sync:/:/bin/sync ftp:*:99:20:anonymous ftp:/store/ftp:/bin/csh guest:2dj7u1tEvDLpk:101:8:Guest Account:/home/guest:/bin/csh ray:OPA7l1cyVYwrs:515:10:William C. Ray:/priv/home/ray:/bin/tcsh skuld:CZ4a7y1AlpgMW:100:5:System Software Administrator:/usr/local/test:/bin/tcsh joray:pA2lf397a0mYa:2001:21:Joan Ray:/priv/home/joray:/bin/tcsh jray:a3kSXs1ROd17p:2002:21:John Ray:/home/jray:/bin/tcsh 

Here root , guest , ray , skuld , joray , and jray have active accounts with passwords set. nobody , daemon , sys , bin , sync , and ftp show a * character instead of an encrypted password. This effectively locks the account out ( root can still su to it) because the * is not a valid password encryption, and therefore no entered password can ever match this value. In traditional Unix, this file is /etc/passwd (or /etc/master.passwd in Mac OS X, if you've enabled "BSD Configuration Files" from the Directory Services utility, and set it to use the password file), and each user's encrypted password is the value immediately following the first colon of the line. In an attempt to make the decryption even more difficult, the standard system works in reverse of the way that might initially seem to be appropriate. Instead of encrypting the password through the use of some key, and storing the encrypted valuewhich would subject the entire scheme to failure if the key should happen to be discovered in the standard use, the password itself is used as a key to encrypt a known value.

NOTE

The form of this use is worth repeating, as it's a clever way to use an encryption system with a strong algorithm. As the developers of the DVD encryption system discovered the hard way, if you embed the key to your encryption algorithm in your software, a single failure that allows someone to discover that key can lead to a failure of the entire system. It is therefore a poor design to store passwords (or any other data) encrypted with a key that you're also storing in the same software. To alleviate this concern, for data that is on the order of the size of passwords, one can reverse the usual use, and use the provided password as the key, and encrypt a known value instead. For the purposes of comparing the stored value to the encrypted result of what the user enters, which is encrypted and which is the key does not matter: Any particular key and data value will still always encrypt to the same result, but using the password as the key prevents the key from being a stored value, and therefore limits any compromise that guesses a key from compromising anything but that individual value.

NIS (Network Information System) Passwords

The previous section illustrated password storage in the classical single-password-file on a single machine style. More typically in clustered environments, systems use a server to transfer the passwords between all the clients , enabling each client to have identical information regarding each user. In the traditional Unix environment, this is facilitated by the NIS (Network Information Services, formerly known as the YPyellow pagessystem), which functions as a network database to serve user ID and password information to any collection of machines that want to cooperate as a cluster.

NOTE

There are vulnerabilities specific to this service, but the general concepts apply in some fashion and at some level to any service that provides system passwords from remote systems.

NIS information is served as collections, each of which is given a unique (one should hope) NIS domain name. Any machine that wants to participate as a peer in a cluster subscribes to the domain by name. It does so by broadcasting a request on the network for any server that claims to serve a domain by that name. The system was designed to make it simple to build cooperative clusters with provisions for redundant service for user authentication, while requiring as little human intervention in copying data in circles as possible. For this purpose it works well: Any machine can join the cluster simply by requesting information from the named domain and then acting upon it. Likewise, the cluster can easily be made fault tolerant, because the clients aren't locked into a particular server for the authentication information. Because clients query for authentication information by broadcast, slave NIS servers can be configured to automatically mirror information from the master, and to respond to broadcast queries for the information if they don't see a response from the master.

This scheme, although widely used with clustered Unix machines, is insecure on two fronts. It was devised in the days when all Unix machines were run by trained and trusted system administrators, and there was an implicit understanding that if a Unix machine were attempting to connect, it was very likely to have a trusted operator at the helm. Therefore, the only effective security built into the system is the capability to restrict responses to NIS information requests to only particular trusted subnets, and the notion that keeping the NIS domain name secret will prevent unauthorized queries to that domain. Like many early security measures built into Unix, these ideas have been antiquated by the advent of desktop Unixes such as Mac OS X and Linux. If an unauthorized client wants to access the information in the domain (such as to gain access to the password file), it has only to broadcast a request for that domain and be within one of the subnets that the server is configured to believe is secure, and a server will respond with the requested information. Unless we have absolute control over all machines on the "trusted" subnets, and absolute certainty that no other machines can be added, in today's environment we cannot responsibly believe that only authorized machines will request the information. Likewise, although the NIS domain name can be considered to be a password of sorts, it's unwise to rely on its remaining unknown as a strong protection against unauthorized access to the information available through the domain.

If you have an NIS domain to which you can subscribe, it is quite simple to access the password (and other) information stored in it and use this information for authentication on your machine. You need to contact the administrator of the system serving the domain to determine the domain name, whether your machine is permitted access, and to confirm that your subnet is listed among the trusted subnets for that domain on the server. After you have done this, follow these steps to configure your machine to make use of the information:

1. Configure your machine to accept user information from NIS.

2. Configure the NIS domain name for your machine.

3. Bind your machine as an NIS client to the domain.

Each of these steps will need to be done while you are su ed root, or via sudo . After you are finished, you will be able to log in to your machine as any user specified in the domain, using the passwords that the domain specifies and the home directory and shells configured in that domain for the users, just as though you had created the users locally in your own NetInfo system. As of this writing (OS 10.2.2) however, there's a bug with the GUI login application that prevents it from using the NIS information. (NIS login and other information functions properly through ssh ( slogin ) login and su functionality, however.)

Using NIS for Lookups

The first step of the process is accomplished by adding a flag specifying that lookupd should obey NIS-provided information for users. You can accomplish this by creating the file /etc/lookupd/users and specifying appropriate options for LookupOrder , or by creating the NetInfo directory /locations/lookupd/users and populating it with the same information, and then restarting lookupd . If you prefer the file route, create the file /etc/lookupd/users and place in it the following line:

 LookupOrder     NIAgent YPAgent 

This tells lookupd that when it's looking for user authentication information it is to first go to your NetInfo system and inquire there (NetInfo is a NeXT -inspired service that provides more sophisticated network-information-database-type services than NIS, and is the default information service for OS X), and if matching information is not found, to subsequently query the NIS system. If you prefer to add the information to your NetInfo domain, you can do so either by using the NetInfo Manager application in your Applications/Utilities directory, or by using the command-line niutil commands shown here. ( niutil is covered in greater detail in the next section.)

 niutil -create . /locations/lookupd/users niutil -createprop . /locations/lookupd/users LookupOrder NIAgent YPAgent 

Alternately, you can create the content for the directory as a text file and then insert the content by using the niload command to populate the directory. First create a text file containing the following content:

 {   "name" = ( "lookupd" );   CHILDREN = (     {       "name" = ( "users" );       "LookupOrder" = ( "NIAgent", "YPAgent" );     }   ) } 

Because lookupd actually controls the search order for a number of different types of services, it might be better for you to specify a default order as well. Also, including the CacheAgent as the first source to check can speed lookups on your system considerably in some situations. These changes make the file look like the following:

 {   "LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent" );   "name" = ( "lookupd" );   CHILDREN = (     {       "name" = ( "users" );       "LookupOrder" = ( "CacheAgent", "NIAgent", "YPAgent" );     }   ) } 

In either case, the changes get loaded into your NetInfo domain with the following commands ( assuming you've named you text file lookupd.txt ):

 niutil -create . /locations/lookupd niload -r /locations/lookupd . < lookupd.txt 

Selecting an NIS Domain

The second step is to configure your machine to subscribe to a particular NIS domain. It is possible to subscribe to (and switch among) multiple domains, but this is beyond the scope of this book. For a single domain, the process is simple: Just issue the domainname command, where <domainname> is the name of the domain you plan to subscribe to:

 domainname <domainname> 

If you want to make this subscription to the domain permanent, then edit the /etc/hostconfig file so that it reads:

 NISDOMAIN=<domainname> 

If you make this change, the next time the machine is rebooted, all this will be configured automatically.

Binding Your Client to the NIS Domain

The third step is to bind your domain to the domain. If you are on the same broadcast subnet as the server for the domain, to subscribe to a domain you need to know only the NIS domain name. (Remember, this is not the same thing as your DNS domain.) If you are on a different subnet, you need to know both the domain name and the server's IP address. If you are on the same subnet, simply issue the following command:

 ypbind 

If you need to bind to a server on a different subnet, the process is only a little more complicated (though it may be considerably more frustratingthe first step sometimes takes a while to respond when it can't talk to the NIS server immediately). If your machine is on a different subnet from the server, use the following commands instead:

 ypbind -ypsetme ypset <ip address of NIS server host> 

Taken all together, if you were trying to bind your machine to the NIS domain rubbermonster , and the server were at IP address 192.168.1.4 , the process after adding NIS to the lookupd would look like this:

 domainname rubbermonster ypbind -ypsetme ypset 192.168.1.4 

The second step may take some time. If you find it annoying, start another terminal window, log in as root, and run the ypset command from it. After these commands have all been executed successfully, you should be able to then run the ypcat command and get the same sort of output shown earlier as being in the /etc/password file. Here I've left my full prompts in the output to more clearly display the sequence of operations:

 Racer-X ray 7#  nidump -r /locations/lookupd .  {   "name" = ( "lookupd" );   CHILDREN = (     {       "name" = ( "users" );       "LookupOrder" = ( "NIAgent", "YPAgent" );     }   ) } Racer-X ray 8#  domainname rubbermonster  Racer-X ray 9#  ypbind -ypsetme   (I got bored and ran   ypset 192.168.1.4   in another window)  Racer-X ray 10#  ypwhich  192.168.1.4 Racer-X ray 11#  ypcat passwd  root:nA5oSdDy859bE:0:1:Operator:/:/bin/csh nobody:*:65534:65534:nobody:/: daemon:*:1:1:daemon:/: sys:*:2:2:sys:/:/bin/csh bin:*:3:3:bin:/bin: sync:*:1:1:sync:/:/bin/sync ftp:*:99:20:anonymous ftp:/store/ftp:/bin/csh guest:2dj7u1tEvDLpk:101:8:Guest Account:/home/guest:/bin/csh ray:OPA7l1cyVYwrs:515:10:William C. Ray:/priv/home/ray:/bin/tcsh skuld:CZ4a7y1AlpgMW:100:5:System Software Administrator:/usr/local/test:/bin/tcsh joray:pA2lf397a0mYa:2001:21:Joan Ray:/priv/home/joray:/bin/tcsh jray:a3kSXs1ROd17p:2002:21:John Ray:/home/jray:/bin/tcsh 

At this point, I'm able to log in to my machine as any of these users, and it's just as though I created them in my own NetInfo system through the Accounts control pane.

The potential security failures of the system should be obvious: I've just snagged a copy of the password file from a remote server, without doing anything beyond asking it politely. If I were trying to steal information, it couldn't get much easier for me stealing the password file, could it? Perhaps more insidiously, if someone wanted access to my machine, all they'd need to do is whack the actual server and stick in a server that served a domain by the same name. I'd possibly never know the difference, and the culprits would be able to insert any user IDs and passwords into my list of users. This would enable them to enter my system at will. This attack becomes trivially easy with the broadcast version of the protocol, where the client doesn't even have an IP address for the server. Just disabling the server's network connection and popping an imposter system online for a few moments can insert users into my system, who my machine will allow access. There's nothing to prevent them from inserting a user with an equivalent user ID to root (UID 0). This could be devastating.

LDAP (Lightweight Directory Access Protocol) Passwords

Like the NIS, LDAP is a network service designed to provide user account information across a cluster of cooperating machines. LDAP has traditionally been used more frequently in clustering "desktop workgroup"-type computers than in clustering Unix boxes, but it is becoming more common in this environment as well. OS X, trying to interoperate in both worlds seamlessly, provides access to either or both systems. Unlike NIS, in which the database and query system are integrated, LDAP is technically just a specification for a standard for carrying out the on-network dialog between a client requesting and a server providing directory-type information. LDAP can theoretically be used as the interface to just about any network directory service, and Apple has used it to build their OpenDirectory service package on top of NetInfo (discussed in the next section) for OS X.

In the case of LDAP, OS X's support currently appears to be seamless in some situations and strewn with cavernous gulfs in others. There are five different interfaces (or rather, five that have been found so far) through which the system can be configured to communicate with LDAP services:

• Two interfaces are available through Directory Access in Applications/Utilities. LDAPv2 and LDAPv3, although they require similar information, are configured through two completely dissimilar interfaces. These theoretically configure the system to accept LDAP information for logins and/or address-book purposes.

• On the other hand, there are also two different (both between themselves and from the Directory Access configuration) places in which to configure lookupd , which is the general directory services information daemon where the system (supposedly) gets its normal user information. lookupd can either read a series of configuration files from /etc/lookupd/ or use the NetInfo directory /locations/lookupd/ from your local NetInfo heirarchy. Unfortunately, it seems there's a file missing from the system because attempts to directly configure lookupd to use LDAP, in a fashion similar to what was done with NIS in the previous section, result in errors being logged to /var/log/system.log regarding a missing LDAP.bundle file.

• Finally, there are configuration files living in /etc/openldap/ that appear to carry the configuration for an assortment of LDAP command-line tools such as ud (a textual interface to LDAP services).

Annoyingly, the way that these interoperate (if at all) is not clearly documented, and none of the three systems (and their five interfaces) appear to be aware of the existence of the others. Also annoyingly, the man pages for each appear to have originated on systems where that interface was the interface to LDAP, leaving the administrator with considerable confusion if she isn't trying to connect to an Apple server for which LDAP is mostly all autoconfiguring. Fortunately, in a book regarding security, our place is not to teach you to make sense of or configure this morass , but to point out the deficiencies in the system from a security standpoint.

Being considerably more complex a system than NIS, one might expect LDAP to suffer from more potential security problems than NIS. A quick survey of securityfocus.com and cve.mitre.org would lead one to believe that this is likely to be true. CVE itemizes 24 LDAP vulnerabilities to 17 for NIS. SecurityFocus, on the other hand, lists 225 entries for LDAP and 358 for NIS. It's a little difficult to pick apart these numbers to make sense of any trends available, SecurityFocus includes links both to nonvulnerability articles mentioning various security topics and to potentially multiple articles regarding each vulnerability, whereas CVE tries to catalog distinct security issues, so the CVE distribution is probably more reflective of reality. When considering the relationship between LDAP's 24 CVE issues and NIS's 17, it should be kept in mind that NIS has been in use for well over twice as long as LDAP. On the other hand, many of NIS's vulnerabilities are core security flaws in the protocol, whereas LDAP's tend more toward programming errors or misinterpretations of the implementation details.

Probably the largest security problem with LDAP, however, is one that's shared with NIS: It provides user authentication information to remote machines, just for the asking. With LDAP a server administrator has the option of requiring a user ID and password to access LDAP information from the server, but as can be seen from the documentation for OS X's LDAP interfaces ( lookupd in particular), there's not necessarily much protection provided for these authentication tokens. This allows the same variety of unauthorized access to user authentication information, and the same potential for spoofing the information from the server as is suffered by NIS clients.

Unlike NIS, LDAP clients that are easily available on the Internet can allow anyone easy access to explore LDAP servers. For example, Jarek Gawor's LDAP Browser/Editor (http://www.iit.edu/~gawojar/ldap/) is a cross-platform Java client that enables you to easily explore any LDAP server you can identify. It even comes preconfigured to connect to the University of Michigan's LDAP server. This server doesn't seem to be particularly communicative without additional information, but if you'd like to use the client to explore other public repositories of information, Notre Dame's Office of Information Technologies makes a convenient list available at http://www.nd.edu/~eds/search/ldap_search.shtml.

NetInfo Password Database

Finally, we come to NetInfo, which is Apple's implementation of a hierarchical network directory service. NetInfo is considerably more complex than NIS, which should imply that there are more potential security flaws. Thankfully, it was designed by programmers more in touch with their paranoid inner selves. There are a few specific security issues, but by and large, NetInfo has not divulged a significant number of flaws at this point. SecurityFocus and CVE barely even know it exists, with only 21 and 2 entries respectivelynot bad for a protocol that's been around since the early 1990s, though the lack of penetration in the market has probably reduced somewhat the level of stress-testing to which it has been subjected.

Conceptually NetInfo is similar to NIS and LDAP, in that it provides a range of data types divided into a number of different classes. The fact that it's hierarchically arranged as a directory structure, rather than as flat files like NIS, makes it somewhat more complex to access, but its primary difference is that the servers providing the information can be hierarchically arranged in the design of how they can provide the information. In a clever abstraction of information services, each client functions as its own NetInfo server, can further serve its NetInfo directory structure, and can subscribe to others.

Covering NetInfo in sufficient depth to do it justice would take a book or two worth of writing, so we'll touch on only the basics that apply to the user ID and password system here. NetInfo stores user information in the NetInfo directory /users . You can list directories by using the -list option to the niutil command, in the form niutil -list <NetInfo domain> <directory> , where <NetInfo domain> is typically the root domain . on your machine, and <directory> in this case is /users .

 Racer-X ray 5%  niutil -list . /users  11       nobody 12       root 13       daemon 14       unknown 15       smmsp 16       www 17       mysql 18       sshd 52       ray 53       software 60       skel 61       jim 63       james 67       bar 

You can read any particular record by using the -read option to niutil , in the form niutil -read <NetInfo domain> <directory><property> , where <property> is the name of the property you want to query.

 %  niutil -read . /users/software  authentication_authority: ;basic; ;LocalWindowsHash; picture: /Library/User Pictures/Nature/Nest.tif _shadow_passwd: hint: uid: 503 _writers_passwd: software realname: Skuld _writers_hint: software gid: 100 shell: /bin/tcsh name: software _writers_tim_password: software passwd: xwNc7eG6/lR4. _writers_picture: software home: /Users/software sharedDir: Public 

Alternatively, you can dump any record (or all records) from the database by using the nidump command. The nidump command conveniently enables you to search for records with specific properties, by using the syntax nidump -r <directory name>=<desired dir>/<property name>=<desired property> <NetInfo domain> .

 %  nidump -r /name=users/uid=5002 .  {   "authentication_authority" = ( ";basic;" );   "picture" = ( "/Library/User Pictures/Nature/Zen.tif" );   "_shadow_passwd" = ( "" );   "hint" = ( "Urusei!" );   "uid" = ( "5002" );   "_writers_passwd" = ( "skel" );   "realname" = ( "skeleton account" );   "_writers_hint" = ( "skel" );   "gid" = ( "99" );   "shell" = ( "/bin/tcsh" );   "name" = ( "skel" );   "_writers_tim_password" = ( "skel" );   "passwd" = ( "AtcBqXhZAfJ7A" );   "_writers_picture" = ( "skel" );   "home" = ( "/Users/skel" );   "sharedDir" = ( "Public" ); } 

If your domain is a tagged domain, you can use the syntax nidump -r <directory name>=<desired dir>/<property name>=<desired property> -t <NetInfo domain> instead.

 %  nidump -r /name=users/name=ray -t localhost/local  {   "authentication_authority" = ( ";basic;" );   "picture" = ( "/Library/User Pictures/Fun/Orange.tif" );   "_shadow_passwd" = ( "" );   "hint" = ( "AA-Megamisama" );   "uid" = ( "501" );   "_writers_passwd" = ( "ray" );   "realname" = ( "Will Ray" );   "_writers_hint" = ( "ray" );   "gid" = ( "20" );   "home" = ( "/Volumes/Wills_Data/ray" );   "name" = ( "ray" );   "_writers_tim_password" = ( "ray" );   "passwd" = ( "8R83ac3Pl1FxQ" );   "_writers_picture" = ( "ray" );   "shell" = ( "/bin/tcsh" );   "sharedDir" = ( "Public" ); } 

In each of these cases, note that I have been able to read or list the user and password information without needing to be root. This is a problem; it facilitates the type of attacks against the password system that are demonstrated in the next section.

Consolidated Password Storage Mechanisms

With the recent massive proliferation of software, services, and online systems that want to use passwords or passphrases, many users have started either using the same password for everything or looking for a way to consolidate all their passwords into some interface that does the remembering for them. Early on, Web browsers started incorporating this ability to remember things that you entered into Web forms for you so that you didn't have to enter them again. Other software quickly sprang up to fill the void for remembering passwords where Web browsers couldn't do the job. By now, you should immediately see the idea of encrypting and storing all your identity tokens in a single container, protected by a single key, as a rather dangerous one. Nevertheless, Apple's provided a version of this functionality as a built-in component of OS X in the form of the Keychain.

The Keychain facility, managed through the Keychain Access program in the Utilities folder under Applications, provides a centralized service through which any application can store identification tokens for the user. As a matter of fact, it's a bit difficult to prevent applications from storing identification tokens in the Keychain: I am aware of having told only one application that I wanted it to store information in the Keychain, yet my copy seems to have a dozen keys stored in it.

NOTE

Too many Keychainsjust like my pants pockets!

Discussing the Keychain facility, Keychain Access.app, and Keychains is a bit difficult because we have a Keychain facility that holds Keychains and a Keychain Access.app that enables you to configure what Keychains are held by the Keychain facility.

If you're comfortable with the idea of storing all of your passwords or other identification tokens in a single application where they can all simultaneously be exposed by a single compromise of the storing application, then the Keychain can provide some relatively sophisticated functions for managing this type of information.

NOTE

Despite the reality of the potential for a single-point compromise of all of your security information, should you use Keychain to store it all, it's not really all that bad a solution for many purposes. If you've a choice between remembering and using one actually strong password or passphrase to remember and protect all your identity tokens, and getting lazy and using dozens of weak passwords that you've had to remember yourself, using something like Keychain is probably the lesser of two evils.

The problems inherent in the system are real, and should be a significant concern. The problems with identity tokens in general, however, are rather severe, and there is simply no good and practical solution. If you're not going to be superhumanly conscientious with respect to picking and remembering your security tokens, you're going to be making compromises, and it may be that using an application such as Keychain is the best of the possible compromises in your situation.

Only you can make this decision, but you need to make it based on a clear understanding of the potential problems.

Most uses of the Keychain are almost transparent to the user. An application might ask you, when you enter a password for some function, whether you want to store the information in the Keychain. If you tell it yes, it will store the plaintext of the information in the Keychain (as an encrypted value), and will retrieve and use that value from the Keychain whenever it would require you to enter the information.

All the information that's stored in the Keychain is encrypted, but by default the Keychain is decrypted, and the plaintext contents made available to the applications that need them when you log in. In its default use, the Keychain uses your login authentication as the authorization token by which it decrypts your information and makes it available, so the strength of your login directly affects the level of protection that any information stored in the Keychain is afforded.

Figure 5.1 shows the Keychain Access interface to the Keychain. In the panes shown in this interface, you have access to a list of the keys stored in the currently open Keychain, and are shown the attributes of any key you choose. Checking the Show Passphrase box will, depending on the settings for that particular item, either immediately display the plaintext password or passphrase in the box immediately below it, or it will pop up a requester dialog asking for you to enter the password or passphrase for that Keychain, and asking under what circumstances the display of the passphrase should be allowed.

Figure 5.1. The Keychain Access.app Keychain facility control application.

Figure 5.2 shows the dialog requesting the password, to enable Keychain Access to display the password/passphrase. Keychain Access.app is requesting permission from the Keychain facility to display the passphrase. It must obey the access restrictions that have been configured for the passphrase just as any other application needs to do, so this same dialog appears when any other application requests this information as well. The password it wants is the password for that particular Keychain, which, if you're using the default, is your system login password. What's going on here might be moderately confusing initially: You've asked Keychain Access.app to show you the plaintext of a passphrase, and the running system Keychain facility has popped up a dialog box to ask you whether it should allow Keychain Access.app to decrypt and display that information for you. If you select Allow Once, the information is displayed in the text box below the check box, but the permission will not be permanent: Closing Keychain Access.app and requesting the same information again results in you being queried for your password again. If you select Always Allow, the next time you open Keychain Access.app, you can display that passphrase without needing to enter your system password. If you've a tendency to leave your console while you're logged in, this is probably a dangerous selection to make.

Figure 5.2. When an application requests access to a Keychain item, you are asked whether to allow it to read the data.

The Access Control tab gives you control over general access policies for the selected item. Under this tab, the options shown in Figure 5.3 enable you to control whether any application should be allowed access whenever it asks whether the Keychain facility should query for each application when it requests access, whether to require the Keychain password for access to the item, and which (if any) applications should be allowed unconditional access to the information. In the case of the id_rsa application password shown, it's set to allow unconditional access to the SSH Agent program, which is yet another key-serving application that enables secure encrypted network transmissions (covered in greater detail in Chapter 14, "Remote Access: Secure Shell, VNC, Timbuktu, Apple Remote Desktop"), and to otherwise query you regarding whether any application is allowed to access the information if it requests it.

Figure 5.3. The Access Control tab enables you to configure access policies for this piece of information.

The Keychain can actually store almost any small snippits of information that you can put in a short textual note. The Note button of the interface brings up a dialog where you can enter brief messages or information, such as credit card numbers, that you'd like to protect. This is protected with the same encryption with which the passwords it contains are protected, and is subject to the same vulnerabilities if your password should be compromised, or if you allow the information to be displayed without requiring confirmation. The Keychain facility also enables you to store multiple separate Keychains for each user, each protected with a different password or passphrase. Additional options available under the Keychain Access.app menus enable you to configure other defaults for the Keychain facility, such as whether it should expire a user's access if she's been idle for some period, or if the system has gone to sleep.

---

Top