The operating system UNIX has been chosen because it is the most used as far as the authentication of users is concerned. As far as his implementation is concerned, only we should take into account this operating system in the machine that acts like servant, not being necessary in the peripheral one of the user, who will have a paper solely, at the most, transmitting encrypted keys.

There is a brief introduction of the access systems and security of this operating system, followed by a description of each one of the used systems of authentication under this system.

These systems of access can be used like support to previously explained, so that the security is increased exponentially.

Classic authentication

In an habitual UNIX system each user has a name of entrance to the system or login and a key or password; both data store generally in the file /etc/passwd. This file contains a line by user (although there are entrances that does not correspond to real users, as we will see next) where indicates the necessary information so that the users can connect to the system and work in him, separating the different fields.

In first place they appear the login of the user and its encode key; next we have two numbers that will be the user identifier and the one of group respectively. Fifth field, denominated GECOS is simply administrative information about the real identity of the user, like its name, telephone or number of office. Finally, last fields correspond to the directory of the user (initial his $HOME) and to the shell that has been assigned to him.

On the contrary much people think, UNIX is not able to distinguish its users by its name of entrance to the system. For the operating system what really it distinguishes to a person of another one (or at least to a user of another one) it is the UID of the user at issue; login is something that is used mainly for comfort of the people (obvious it is easier to remember a name of entrance like toni who of a UID like 2643, mainly if it is took into account in several machines, each one with a different UID). Therefore, if in /etc/password exits two entrances with a same UID , for UNIX will be the same user, although they have login and password different: thus, if two users have assigned UID 0, both will have superuser privileges, without concerning login that use. This specially is taken advantage of by attackers who have obtained privileges of administrator in a machine: they can add a line mixed between all the others, with a name of normal user but with UID 0; thus they guarantee its entrance to the system as administrators in case of being discovered, for example to erase fingerprints.

In the file of keys they are going to exist entrances that do not correspond to real users, but that is used by certain programs or it is accounts maintained by reasons for compatibility with other systems; typical examples of this type of entrances are lp, UUCP or postmaster.

These accounts have to be blocked in most cases to avoid that somebody can use them to accede to our system: they only have to be accessible for root by means of the order his. Although in his majority they fulfil this condition, in some systems these accounts have keys by defect or, worse, they do not have keys, which turns a completely open door the intruders; he is advisable that, once installed the operating system, and before putting to work the machine, we verify that they are blocked, or in defect that have non-trivial . Some examples of accounts on which there are to pay a special attention are root, guest, lp, we give, 4DGifts, tour, UUCP, nuucp, games or postmaster; he is very recommendable to consult the manuals of each concrete system, and periodically to check the existence of accounts without key or accounts that would have to remain blocked and they are not it.

In order to encode the keys of access of its users, the operating system UNIX uses an irreversible cryptosystem that uses the standard function of C crypt(3), based in algorithm DES. This function takes as key the eight first characters from the password chosen by the user (if the length of this one is smaller, is completed with zeros) to base a clear text block in of 64 bits put to zero; in order to avoid that two equal passwords

are in a same based text, an exchange is made during the process of coding chosen of automatic and at random for each user, based on a field formed by a number of 12 bits (with which we obtained 4096 different exchanges) call salt. The resulting coding becomes to base again using the password of the user like key, and permuting with same salt, repeating the process 25 times. The based block final, of 64 bits, is linked with two bits zero, obtaining 66 bits that become representable in 11 characters of 6 bits each one and that, along with salt, happens to constitute the field password of the file of passwords, usually /etc/passwd. Thus, both first characters of this field will be constituted by salt and the 11 rest by the based password:

As we have said before, this cryptosystem is irreversible. Then, how can a user connect itself to an UNIX machine? The process is simple: the user introduces his password, which is used like key to encode 64 bits to 0 being based on salt, read in /etc/passwd, of this user. If after applying to the coding algorithm the result password of the file of passwords corresponds with stored in the last the 11 characters of the field, the key of the user is considered valid and the access is allowed. In opposite case it is denied to him and the failed attempt of connection is stored in a file.

Improvement of the security

Problems of the classic model

The encode text’s attacks constitute the main threat to the system of authentication of UNIX; unlike much people believe, it is not possible to decipher a password, but it is very easy to encode a word together with a certain salt, and to compare the result with the chain stored in the key’s file.

In that way, an attacker will read the file /etc/passwd (this file has to have permission of reading for all the users if we want that the system works correctly), and by means of a fortune-teller program(or crackeador) as Crack or John the Ripper will code all the words of a file called dictionary (a file ASCII with a great number of words of any language or field of the society - classic history, deports, rock singers...), comparing the result obtained in this process with the code key of the file of passwords; if both agree, it has already obtained a key to accede to the system of non authorized way.

This process can, but usually it is not carried out in the local machine, since in this case there are enough possibilities of detecting the attack: from modifying in code of the crypt function (3) so that he alerts to the administrator when he is invoked repeatedly (whenever the fortune-teller code a word he uses this function) until simply realizing excessive load of CPU (the programs fortune-tellers usually consume a time of considerable processor). The habitual thing is that the attacker transfers a copy from the file to another computer and makes the process in this other machine; it has not to be an UNIX servant with great capacity of calculation: there are many fortune-teller programs that execute them in a normal PC, under MSDOS or Windows. Obviously, this second case is much more difficult to detect, since an audit of the programs that each user executes is needed (and utilities as cp or FTP usually does not call the attention of the administrator). This audit is offered by many UNIX systems but usually it is not used because of the excessive resources that it can consume, eve in small systems; obviously, we never must trust the historical archives of orders of the user, since the attacker can modify them to hide their activities, with no need of any special privilege.

Acceptable passwords

The main form to avoid this type of attack is to use passwords that are not words of the typical files dictionary: combinations of small letters and capital letters, numbers mixed with text, symbols like &, $ or %, etc. Of course, we have to flee from simple keys like Internet or beatles, own names, weak combinations like Pepito1 or qwerty, names of places, book actors, characters, sportsmen... numerous studies on how to avoid this type of passwords in the users and also powerful tools have been designed to obtain it, like Npasswd or Passwd+ have been made. It is quite advisable to install some of them to force the user to use acceptable passwords (many Unices already brings them incorporated), but does not agree to trust all the security of our system to these programs.

As a rule, any administrator should execute with certain regularity some fortune-teller programs, as Crack, to verify that their users have not chosen weak passwords (in spite of the use of Npasswd or Passwd+): it can be possible to use keys generated before installing these utilities or keys assigned by the own root that have not pass through the control of these programs.

Shadow Password

Another method more used every day to protect the passwords of the users is the denominated Shadow Password or darkening of passwords.

The basic idea of this mechanism is to prevent that the users without privileges can read the file where the based keys are stored; in the previous point we have commented that the file /etc/passwd must have permission of reading for everybody if we want that the system works correctly.

In equipment with darkening of passwords this file continues being legible for all the users, but unlike the traditional mechanism, the encode keys are not kept in it, but in the file /etc/shadow, that only root can read. In the corresponding field of the encode key of /etc/passwd she does not appear this one, but a symbol that it indicates certain programs (like /bin/login) that are to look for the keys in /etc/shadow.

The aspect of /etc/shadow is in certain way similar to the one of /etc/passwd that we have already commented: there is a line by each user of the system, in which his login and his encode key is stored. Nevertheless, the rest of fields of this file are different; they correspond to information that allows them to implement another mechanism to protect the keys of the users, or Aging Password, we will speak later about it.

Since a couple of years ago, the great majority of Unices of the market has been incorporating this mechanism; if when installing the operating system the keys appear stored in /etc/passwd we can verify if pwconv order exists, that turns a classic system to a darkness one.

If it is not so, or if we used an old UNIX that does not have the mechanism of Shadow Password, it is very advisable that we obtain the package that implements it (surely it will be a file that we can find in multitude of servants, adapted to our clone of UNIX) and we will install it in the equipment.

To allow that all the users read the encoded keys has represented during years, and continues representing, one of the greater problems of security of UNIX; in addition, one of the preferred activities of inexperienced pirates is to interchange files of keys of the systems to which they accede and to pirate them (crackear) so it is enough a person who reads our file to have in short time a colony of intruders in our system.

Aging of passwords

In almost all the present implementations of Shadow Password it is usually include the implementation for another mechanism of protection of the keys denominated aging of passwords. The basic idea of this mechanism is to protect passwords of the users given them a certain period of life: a password is going to be valid during certain time, later it will expire and the user will have to change it.

Really, the aging prevent more that problems with the key, problems with the transmission of these by the network: when we connected by means of mechanisms like telnet, FTP or rlogin to an UNIX system, any equipment between ours and the servant can read the packages that we sent by the network, including which they contain our name of user and our password (we will speak more thoroughly of this in the chapters dedicated to the security of the system of network and to the cryptography). In that way, an attacker located in an intermediate computer can obtain ours login and ours password. If the captured key is valid indefinitely, that person has an access assured to the servant at the moment that she wants; nevertheless, if the key has a period of life, the attacker will only be able to use it before the system forces to change it to us.

At first sight, he can seem that the utility of the aging of passwords is not very great; after all, the reading of packages destined to other equipment (sniffing) is not made by chance: the attacker who reads the network in search of keys and names of user is going to do it because she wants to use these data against a system.

Nevertheless, a habitual practice is to leave programs listening during days and recording the information read in files; every certain time the pirate will consult the results of such programs, and if the readed key has already expired and his proprietor has changed it by another one, the fact that he has captured will not serve for anything to the attacker.

Figure 8.5: admintool (Solaris) with options to the aging of passwords.

The periods of expiration of the keys usually are defined at the time of creating the users with the tools that each system offers for it (for example, Solaris and his admintool, shown in Figure 5.)

If we want to modify some of these periods once they are established, from those administration tools, we will be able to do it, and also from command line by means of orders like chage or usermod. As we have said before, in the file /etc/shadow is stored, together with the encode key of each user, the information necessary to implement the aging of passwords; an entrance of this file is of the toni form :LEgPN8jqSCHCg:10322:0:99999:7:::

After login and password of each user the following fields are kept:

• The days passed from the 1 of January of 1970 until the day that the key was changed for the last time.

• Days that have to pass until the user can return to change his password.

• Days after which he has to change the key.

• Days during which the user will be warned that its key is going to expire before this one does it.

• Days that the account will be working after the expiration of the key.

• Days from the 1 of January of 1970 until the account will be disabled

• Reserved field.

As we can see, when a user changes his key in the system, it prevents him to return to change during a period of time; with this one obtains that when the system forces to change the password the user does not recover his old key immediately (in this case the scheme would not serve as anything). When this period finalizes, usually it exists an interval of voluntary change: the change of password is allowed, although it is not obligatory; when finalizing this new period, password has expired and it is already obligatory to change the key. If the maximum number of days in which the user cannot change his password is greater than the number of days after which the change is obligatory, the user cannot ever change his key. If after the period of obligatory change password remains inalterable, the account is blocked.

In the older UNIX systems (until System V Release 3,2), without shadow password, all the information of aging is stored in /etc/passwd, together the field corresponding to the encoded key of each user but it is separated of this one by one comma.

In this case the first character after the comma is the maximum number of weeks before password expires; the following character is the minimum number of weeks before the user can change his key, and the third and fourth character indicates the time passed from the 1 of January of 1970 to the last change of password. All these times are indicated by means of certain characters with a special meaning, shown in Table 2. Also three special cases are contemplated in this scheme: if both first characters are `..' the user will be forced to change his key the following time that he connects to the system; the program passwd will modify then its entrance in the file so that the user does not become to see affected by the aging. Another special case happens when both last characters also are `..', situation in which the user also will be forced to change to his key the next time that he connects to the system but the aging will follow defined by two first characters . Finally, if the first character after the comma is minor who the following one, the user can never change his password, and root only can be modified through the account.

One-time Keys

The aging of passwords has two extreme cases. On the one hand, we have the classic scheme: a key is valid until voluntarily the user decides to change it (that is to say, there is no expiry of the password). The opposite side of the Aging Password is to grant a minimum time of life to each key, so that it only serves for a connection: it is what it is denominated One Time Password.

How to use passwords of only a use? In order to obtain there are different approaches; the simplest consists of assigning to the user a list in paper with the sequence of keys to use, so that whenever this one connects to the system, it eliminates of the list the password that finishes using. On the other hand, the system advances in its registry so that the next time that the user connects can use the following key. Another approach consists of using a small device that the user must take with himself, like a card or a special computer, so that when it wishes to connect the system it will indicate a sequence to him of characters to key in such device; the obtained result will be what it is had to use like password. In order to increase the security in the case of robbery of the card, before keying the number received from the machin, it is necessary to use a P.I.N. that the user must keep in private.

One of the more extended implementations of the One Time Password between the different clones from UNIX is S/KEY, available also for clients Windows and MacOS. Using this software, the key of the users never does not travel by the network, not even when executing orders like his passwd, nor either compromising information is stored(like the keys in clear) in the machine servant. When the client wishes to connect against a system generates a password one-time, that is verified in the server; in both tasks summarize functions are used MD4 or MD5. In order to make the authentication, the machine servant keeps a copy from password that receives from the client and it applies the summarize function; if the result does not agree with the copy kept in the file of passwords, the access is denied. If on the contrary the verification is correct it is updated the entrance of the user in the file of keys with one Time password that it has been received (before applying the function to him), thus advancing in the sequence of passwords. This advance decrease in one the number of executed iterations of the function, so there is a time that the user must reinitiate the accountant or in opposite case the access to the system will be denied to him; in order to do it, it executes a modified version of the order.

Other methods

The reason why the scheme of authentication of users of UNIX has been criticized is the length - for intentions of high security, too short of its keys; what it was little more than a theoretical exposition years ago, at the moment is something feasible: without not even entering subjects of dedicated hardware, surely too expensive for most of attackers, with a supercomputer is possible to break key of UNIX in less than two days.

A method that increases the security of our keys in front of attacks of intruders is the coding by means of function known bigcrypt() or crypt16(), that allows lengths for the keys and salts longer than crypt(3); nevertheless, although the security is increased of the keys, the problem that appears is the mutual incompatibility with the keys of the rest of Unices which they continue using crypt(3); this it is a common problem with other approaches that also are based on modifying the coding algorithm, and in using a new one.