Introduction To Authentication(英文）

/ns/wz/sys/data/20010824213326.htm

Introduction To Authentication
By David Corcoran
5/26/2000 9:21

In this feature, David Corcoran, founder of the Linux SmartCard Project, describes Unix passwords, their insecurities, RSA, and using RSA PAM authentication and possible attacks.

Introduction:
~~~~~~~~~~~~~

Unix security has been an impacting issue to system administrators for many years. Unix is widely adopted as a core operating system for use on networks. It is a multi-user environment, which allows users to have different needs and task requirements to co-exist simultaneously under one environment. Each user must have separation and protection from other users, which may or may not be trusted on the system. For example, a manager of a company may hold projected salary increases in a file located in his or her home directory. It is unlikely that the manager would like the employees to be able to have access to this file. This could be valuable to someone, which might want to use this information to allow competitors to grant competitive salaries and steal employees from this company. The manager might also have proprietary information, which is still under patent approval that an unwanted guest might have a strong motive to obtain. To battle this, Unix provides separation of users and access privileges to protect others from gaining or altering information that does not belong to them. Users gain access to their files by authenticating themselves to the operating system. Once they have authenticated, or provided credentials proving their identity, they must now be authorized to perform a specific task.

Authentication is usually done by providing a login name and a password, which the system shares secretly with the user. This guarantees that the person attempting to authenticate knows the login and the password but this does not mean that the person is who the system believes it is. It is common for users to release their login and password to other users for many reasons. One reason is that another user may have had their account revoked and need access to the system so they ask their friend or co-worker if they can borrow theirs. This is not the only way in which another user might be an imposter for a particular user. The imposter might also try guessing the password.

Login names are commonly public information and many times users choose passwords that are affiliated with some aspect of their lifestyle. Sometimes this might be as simple as their address, maiden name, dog's name, or telephone number. These are typically good guesses for the attempting imposter, now known as the attacker. Another possibility is to try a list of commonly used passwords taken from polls such as: jesus, sex, password, and baseball. If this fails the attacker might choose a list of words from a dictionary and combine them and add numeric values and transpose characters and cases until they are granted access. Unfortunately, for the attacker many systems allow a maximum of bad tries before revoking the account. For this reason the attacker must either use their keen judgment on which passwords to try or they might try other methods.

Methods for Gaining Access:
~~~~~~~~~~~~~~~~~~~~~~~~~~~

One common method for gaining access to user's accounts protected by passwords is to actually obtain the password file itself. In early operating systems the passwords were sometimes stored in clear text so the attacker could very easily obtain a password for each user simply by getting this file. This might take a bit of social engineering (sometimes the easiest form of hacking) such as delivering a pizza to a company and loading the password on a disk while an employee has gone to the break room to eat. In most cases it is still not this easy. Modern operating systems have made it even more difficult to get user's passwords by using encryption to store an encrypted password in the password file. It works by running the known true password through a one-way hashing function that returns a ciphertext, which is stored with an associated login name in a password file. Being one-way the ciphertext cannot be reversed through the function to obtain the password. When an attempting user tries to gain access to the operating system it runs their attempted password through the one-way hashing function and then compares it's ciphertext to the ciphertext that is stored in the password file. If the ciphertexts match the user is granted access to the machine. To overcome this the attacker must then obtain this one-way hashing function and try values through it and try to match ciphertext from the function with ciphertext in the password file. Luckily for the attacker, several freely available pieces of software are available on the internet that do this in remarkably little time such as Crack 5.0, John the Ripper, and others.

This became a nightmare for system administrators everywhere. Passwords were easily cracked by even novice hackers through publicly available software. The password files could be obtained by using anonymous FTP programs or exploiting buffer overflows or even debugging modes in popular mail transfer daemons. Passwords could be obtained in little time merely by using some spare CPU cycles while the hacker was fast asleep. The only defense for the system administrator was to somehow make the password file much more difficult to obtain. To do this the shadow password file was created. In this paradigm the password file still exists but it only contains a login and some associated information. The encrypted password is now stored in a separate file that is only readable by the system administrator (root). This keeps the average user from copying the password file simply because it is world readable. This is simply not enough! The Unix operating system is based solely on the C programming language that provides no bounds for memory addressing. A root run process might simply copy memory using a standard memcpy() command, but since an invalid input was given to it - it tries to copy more memory than it really should. This results in a buffer overflow. The attacker can still use this to gain access to a shadow password file since the process, which has the overflow, is run under root privileges.

There are also many other known attacks that a user could perform such as embedding a trojan horse in their home directory and tricking the system administrator to run it with administrator privileges. By some means the attacker will be able to obtain the password file. Since most Unix passwords have an 8 character maximum length - even the strongest password (one that uses a random mixture of alphanumeric characters of mixed case) still can be cracked with a maximum of 2^64 tries worst case. This is quite a large number but with significant distributed computing power this can still be cracked in a matter of hours or days. Since passwords are the easiest and mostly used point of attack they are the greatest vulnerability on most systems today. Increasing the size of the password might be one possibility - making a maximum of 32 characters for a password and causing the worst case of tries to be 2^256. Unfortunately, you cannot force the users who have complete control over their passwords to use 32 character passwords - they will still use 4 character passwords! Another method, which will be discussed for the remainder of the paper, uses public key cryptography.

Public Key Cryptography:
~~~~~~~~~~~~~~~~~~~~~~~~~

Public key cryptography has been in practice for many years to help protect information for a particular user or group. Like the name implies there is a public and a private component to this method. Two keys are generated that have a unique mathematical relationship with each other. One key is given to the public (public key) and the other key is held by the user (private key). One key can encrypt a particular text and the other must be used to decrypt it. In most cases, a user who wants to deliver a document to a recipient takes the public key. The user chooses the recipient's public key and encrypts the document and proceeds to transmit the encrypted document to the recipient. The recipient then uses their private key to decrypt the encrypted document and the transmission was performed successfully. As can be seen in Fig 1.
[img]http://www.linuxsecurity.com/images/publickey1.gif[/img]


Fig 1: Basic model for public key encryption.

Digital Signatures:
~~~~~~~~~~~~~~~~~~~

A digital signature can also be used in public and private key exchange, in which the digital signature has the effect of a real signature. This is important in authenticating the user, because it is a mark only the sender can make. This way the recipients are assured of the authenticity of the sender as being genuine. Digital signatures have to meet four criteria.

Unforgeable: If person P signs message M with signature S(P,M), it is impossible for anyone else to produce the pair [M, S(P,M)]
Authentic: If a person R receives the pair [M,S(P,M)] purportedly from P, R can check hat the signature is really from P. Only P could have created this signature, and the signature is really from P. Only P could have created this signature, and the signature is firmly attached to M. (Pleeger, 141).
Digital signatures must be not alterable and not reusable. A digital signature is just a reassurance to the recipient that a document came from whom it claims. The sender must encrypt the sent message with the recipient's public key. This guarantees that the recipient is the only reader of this document but not that the sender is who they claim to be. A digital signature is a usage of the sender's private key against some challenge. This is generally a hash of the message, which will guarantee the integrity of it during transmission. On the receiving end the receiver takes the senders public key and decrypts the hash and runs the same hashing algorithm on the message to see if the hashes match. If they match the message was either unaltered or altered so that the hash was not affected. The problem here is that the recipient must trust that the public key that they have received is actually the real senders public key. If the public key has come from a trusted domain such as a Verisign or Entrust certificate authority and is signed by a trusted party then the recipient has pretty good assurance of its authenticity.

[img]http://www.linuxsecurity.com/images/publickey2.gif[/img]


Fig 2: Basic model for digital signatures.