||Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
|(slightly skeptical) Educational society promoting "Back to basics" movement against IT overcomplexity and bastardization of classic Unix|
|News||Authentication and Accounts Security||Notes on Passwords Policy||Selected PAM Modules||Writing Passwords Down||Reference|
|PAM wheel||SecurID||Stanford 2004 Compromise||History||Humor||Etc|
"After Snowden" world means that some of sophisticated methods used by NSA will inevitably trickle down to criminals. There is a terrible rule of war: whatever new weapon that you introduce onto the battlefield, your adversary will eventually acquire it as well. That means that now there is a bigger danger for our financial accounts and such as wee as real necessity in two factor authentication in corporate environment. Actually even in our private lives banks and other financial institutions that do not use two factor authentication for their Web portals are better to be avoided.
There are multiple useful techniques of generating strong passwords, but limiting IP space from which user can login to the account is probably the more productive security measure then too much zeal in in ensuring strong password policy. Another key measure that can defeats password cracking attempts is limiting the number of unsuccessful logins allowed. Don't set it too low (seven is OK, three is way too low and for a large organization might produce avalanche of helpdesk tickets).
As for useful set of ideas about strong password see for example Microsoft recommendations in Strong Passwords. In the most cases that simply means: length > 6, no dictionary word, combination of letters and numbers, combination of upper and lower case and at least one punctuation mark. In other words using 100 symbols dictionary instead of 34 (24+10) which would be if only lowercase letters (a-z) and digits(0-9) only are used. And there is a big difference between 328 and 1008
But even weak passwords such as common dictionary words require for cracking several attempts which make that trick very difficult, if not impossible without stealing the password file, the feat that requires root access on modern Unix computers. This is because number of tries for login in most case is limited to single digits. If you add to this protection by IP them even weak passwords are strong enough. For example, Fidelity did not went out of business despite the fact that they use purely numeric passwords for the accounts (to make possible to use them when calling by phone). Many other "second rate" (technology wise) firms disallow using delimiters in passwords in thier Web portals. Actually the state of authentiation security of many financial Web portals is cause of some concern.
Another important fact is that power and usefulness of password crackers are greatly over hyped. First of all if password is checked for strength by OS (and in the most simple case that means, length > 6, no dictionary word, combination of letters and numbers, combination of upper and lower case and at least one punctuation mark) without some additional information to crack it on regular computers requires too much time making it next to impossible if number attempts is limited to say 7.
Before Snowden, I used a pretty simple 6 symbol password on most systems. Still cracking it without some knowledge of the composition requires years of work: 6100 is a pretty big number, bigger then classic 264 (of famous chess fable fame). But now I am paranoid and try to use AOL-style passwords of considerable length, different for each server.
Let me stress it again -- unless you manage to steal the shadow file from some server, it's impossible to apply cracker to the system: in most modern system stream of unsuccessful login attempts will be detected; most systems also block account after five, seven, or eleven or so attempts (although it might be better to block IP from which attempts are coming). Of course many just Web portal implementation do not use Unix scheme and store passwords explicitly but that's another problem. Any system in which authentication is written in a right way should not store the real password only an encryption with this password of some predefined string (and, due to this password can't be restored, only reset to anew randomly generated one, if reset is done authomatically).
If reset is done automatically it relies of the set of questions and this is considerable weakness as people ten to be truthful in this replies on those question. that means that such information can often be deducted from their Facebook page or other social media sites. And it is not easy to instruct user not to give "truthful" answers and pretend that they are other person (for which answers are true -- one level of indirection)
In Unix environment in order to read shadow file you usually need to be root or to have a physical access to the server (and a possibility to reboot it). In such case the only way cracking passwords can be useful is the fact that many users use the same password on multiple sites. In after Snowden world this is big no-no.
At first sight it's look like a pure idiotism to reuse cracked accounts for attacking other servers. But it is not. Users and sysadmins often have the same password on multiple servers; and in "after Snowden" world this is a very bad idea -- you need to have some algorithm of individualization of passwords for each account you have -- no more any two identical passwords can be used. Now this is a must.
|Users and sysadmins now should never use the same password on multiple servers; in "after Snowden" world this is a very bad idea -- you need to have some algorithm of individualization of passwords for each account. This is a must in "After Snowden" world. On Unix servers recommended minimum password length now should be no less then 10 or even 12, which of course if achievable only by adopting of "binary-words" AOL-style scheme of creation passwords or something similar.|
The primary legitimate purpose of Unix password crackers is to detect and eliminate weak user passwords but even this task is dubious: if system is configured to disable account, say for an hour after seven unsuccessful attempts, then even weak password can withstand most of the attacks. But still due diligence is not a bad strategy.
It's important to understand that "realistic" cracking scenario requires access to the password hashes and a very fast computer or better a computer farm. In most modern Unix systems (HP-UX is a notable exception) shadow files that contain password hashes are readable only by the root user. In a way, the introduction of shadow file devalued the importance of crackers. Still if hashes can be intercepted (for example if NIS is used) crackers can be used against them.
Length of password is now a very important parameter that by-and-large determine the security of your account (and difficulty of cracking): longer passwords can be constructed only as multiword (phase) passwords, and they usually cannot be cracked in a reasonable amount of time even if all words are dictionary words. Passwords that consist of more then one word also defeat the optimization in which all the dictionary in "pre-encoded" using the given algorithms and salt and then simple comparison is used to determining if this word was encoded on not. Also many systems do not use salt -- such systems can be attacked more effectively.
That means' that it is extremely important ot adopt so called AOL scheme of creation of passwords "AOL scheme": two short words connected with some delimiter (:, -, /, etc). Like faKe43-secuR55 or [email protected]
|Length of password is now a very important parameter that by-and-large determine the security of your account (and difficulty of cracking): longer passwords usually cannot be cracked in a reasonable time. That means' that it is extremely important ot adopt so called AOL scheme of creation of passords "AOL scheme": two short words connected with some delimiter (:, -, /, etc). Like faKe43-secuR55 or [email protected]|
Brute force attack on password longer then 6 characters is rarely successful (unless done in three letter agency), especially if AOL scheme of generating long password using two short words with one or several delimiters between them. That's why it makes sense to enforce practices that help to create stronger passwords and first of all to limit the minimal password the length to at least 8. But even more important is to check the complexity of the password. As I mentioned above the simplest complexity ensuring scheme checks for the following five criteria of strong password:
This is especially important for root passwords. See also Writing Passwords Down for additional recommendations
It is very important to mix upper and lower cases in password: that's measure alone doubles the size of alphabet and for the 8 character passwords makes brute force attack approximately 256 times longer (2^8).
Enforcing usage of at least one digit and delimited rises the size of alphabet to almost a hundred making password with the length of 8 or more characters immune to brute force attack (1008=1080 which is more then 2240). So cracking in this case is an interesting theme for theoretical discussion, not so much for practice.
So the typical for enterprise environment drive for strong passwords should be navigated with extreme caution. It is very easy to go overboard with this and excessive zeal backfires. Naive Unix administrators who after reading some superficial security book try to enforce a Draconian schemes on unsuspecting users (random passwords or too complex password schemes) usually weaken the security due to unanticipated side effects of such actions.
If you need military grade security smart card or SecurID is a better way then torturing your users with unreasonable or outright silly demands. For the same reason changing password is less then 90 days is not recommended. If you need shorter periods SecurID or SmartCard is your friends but please do not enforce of users stupid paranoid measures just because you don't understand their consequences. Again limiting IP space for login is much better security measure that should be implemented first.
If it's the administrator (root) password that is lost, there's almost always a way to bypass OS security by booting from CD and change it after mounting the filesystem (the exact details are depends on Unix flavor. For Solaris the procedure can be found at Solaris root password recovery.)
If you're looking for a way to recover a lost password, in encrypted file the situation is usually pretty grim. . A typical situation is when the archive (zip or rar) or Microsoft document or spreadsheet is encrypted and password is lost. Here you need to work two ways:
Old Unixes use DEC-based hashing and password are limited to just 8 characters, which is a major disadvantage. Better, MD5-based hashes that permits passwords longer then 8 characters originated in FreeBSD are now also used in Linux and Solaris 10. In this case it is strongly recommended that users switched to "AOL scheme": two short words connected with some delimiter (:, -, /, etc). Like faKe43-secuR55 or [email protected]
From the USENET: "A password should be like a toothbrush. Change it regularly; and DON'T share it with friends." Elements of good password policy include
Passwords are your main defense against intruders. To protect your system and your data, you must select good passwords, and you must protect them carefully.
Once you've been authenticated, the system uses your ID (and the security information associated with it) to determine what you're allowed to do in the system. The system uses this information to make access decisions. For example, if you try to modify a sensitive file, the system checks your authenticated user ID against the list of IDs representing users who are authorized to read and write the data in that file. Only if your ID appears in that list will the system allow you to access the file. (File access is discussed in "Data Access: Protecting Your Data" later in this chapter.)
Secure systems use your ID to maintain individual accountability–in other words, to keep track of what you're doing in a system, particularly if you're affecting security in any way. If Jack Hacke repeatedly tries to access files he's not authorized to view, the system will know! (The discussion of auditing in Chapter 6, Inside the Orange Book, describes how this tracking works.)
At one time, a system cracker would have to try to guess your password, one password attempt at a time (a so-called brute force attack). Like everything else, this process has been automated. Crackers now use computers to do the guessing. In theory, the longer the password, the longer it takes to try every combination of characters. For example, with a password containing eight random characters, there are 2,800,000,000,000 combinations; even with a computer capable of guessing one million passwords per second (a lot faster than the machine your average cracker is likely to be using!), figuring out the right combination would take an average of forty-five years.
The problem is, users don't select random, or even decently secure passwords, and a cracker doesn't need to figure out your password–any password will do. Unfortunately, users typically pick passwords that are laughably easy to guess–their initials, their childrens' names, their license plates, etc. Studies indicate that a very large percentage of users' passwords can easily be guessed. With the help of online dictionaries of common passwords (English words, names of people, animals, cars, fictional characters, places, and so on), crackers are quite likely to be able to guess a good many of the passwords most people are likely to choose. But if you select a good password (see the hints in the inset), an intruder shouldn't be able to guess it–with or without a dictionary.
If you're allowed to choose your own password, pick passwords that are hard to guess. Here are some suggestions:
The best passwords contain mixed uppercase and lowercase letters, as well as at least one number and/or special character. The password you pick doesn't need to be gibberish. In fact, if it is, you'll be tempted to write it down, defeating the purpose of your careful selection. Some suggestions are:
Your ID is associated with all of the processes you create. In many systems, you can effectively change your identity to that of another user; in traditional, untrusted UNIX systems, for example, you do this with the su command. When you change identity, the system may lose its ability to keep track of who's doing what. In secure systems, the system may still allow you to change identity, but it typically keeps track of your original identity as well, so processes you create are still stamped with your "real" ID.
Systems typically maintain a file containing information about your privileges and characteristics; in some systems, this is called a security profile, an authentication profile, or a user list. Your profile might tell the system what your clearance is (e.g., SECRET), whether you're allowed to change your own password, whether you can log in on weekends, whether you can run backup programs and other privileged programs, and a myriad of other information. In some cases, your profile is in the same file as the password list; in other cases, the information might be kept in separate files. In any case, it's vital that your system protect this information; any compromise can jeopardize the security of the entire system.
One of the important pieces of information that appears in your authentication profile or user list is an indication of what kind of user you are. Most systems support several categories of users, or roles; a typical set includes regular users, a system administrator, and an operator. Highly secure systems may define a security officer as a separate category. Each category of user has specific privileges and responsibilities–for example, specific programs the user can run. The system administrator, for example, may effectively be able to do anything in the system, including overriding or circumventing security requirements. The power of the system administrator is a major issue in secure systems; see the discussion of administrative controls and least privilege in Chapter 5, Secure System Planning and Administration.
Access decisions are the heart of system security, and access decisions are based on passwords, so it's vital that your system protect its passwords and other login information.
Most systems protect passwords in two important ways: they make passwords hard to guess and login controls hard to crack, and they protect the file in which passwords are stored.
Most vendors offer a whole smorgasbord of login controls and password management features that the system administrator can mix and match to provide optimal protection of a particular system. Because these security features are commercially attractive and relatively easy to implement, most systems tend to have a lot of them.
|System messages||Most systems display welcome and announcement messages before and/or after you successfully log in. Some systems allow the system administrator to suppress these messages, because they may provide a clue to an observer as to the type of system being accessed. If an intruder dials in and finds out he's talking to a VMS system, for example, that's a valuable clue.|
|Limited attempts||After a certain number of unsuccessful tries at logging into the system (the number can be specified by the system administrator), the system locks you out and prevents you from attempting to log in from that terminal. Some systems lock you out without informing you that this has happened. This allows for the possibility of taking evasive action–identifying the account as a suspicious one without letting you know you're under investigation.|
|Limited time periods||Certain users or terminals may be limited to logging in during business hours or other specified times.|
|Last login message||When you log in, the system may display the date and time of your last login. Many systems also display the number of unsuccessful login attempts since the time of your last successful login. This may give you a chance to discover that your account was accessed by someone else–for example, by noticing a login in the middle of the night or by noticing a pattern of repeated attempts to log in. If you weren't responsible for these attempts, notify your system administrator right away.|
|User-changeable passwords||In many systems, you're allowed to change your own password at any time after its initial assignment by the system administrator.|
|System-generated passwords||Some systems require you to use passwords generated randomly by the system, rather than relying on your own selection of a difficult-to-guess password. The VAX/VMS Version 4.3 system, and many other systems, ensure that these passwords are pronounceable. Some systems let you view several random choices from which you can pick one you think you'll be able to remember. A danger of system-generated passwords is that they're often so hard to remember that users may tend to write them down. Another danger is that if the algorithm for generating these passwords becomes known, your entire system is in jeopardy.|
|Password aging and expiration||When a specified time is reached–for example, the end of the month–all passwords in the system
may expire. The new passwords usually must not be identical to the old passwords. The system should
give reasonable notice before requiring you to change your password; if you have to pick a password
quickly, you're likely to pick a poor one.
In some systems, the system administrator can respond to a security breach by forcing a particular password, or all passwords, to expire immediately. This controls further access to the system until the damage can be assessed.
The system may keep track of your passwords for an extended period to make sure you don't reuse one that might have been guessed.
|Minimum length||Because short passwords are easier to guess than long ones, some systems require that passwords be a certain length, usually six to eight characters.|
|Password locks||Locks allow the system administrator to restrict certain users from logging in or to lock login accounts that haven't been used for an extended period of time.|
|System passwords||System passwords control access to particular terminals that might be targets for unauthorized use. Usually a system password must be entered before you enter your individual password.|
|Primary and secondary passwords||Some systems require that two users, each with a valid password, be present to log in successfully to certain extremely sensitive accounts.|
|Dial-in password||Some systems require that special passwords be used to access dial-in lines.|
Every system needs to maintain its authentication data. Typically, valid passwords are stored in a password file. This file typically is accessed only under certain limited circumstances–when a new user is registered, when you change your password, or when you log in and need to be authenticated.
Protection of passwords is extremely critical to system security. Systems commonly use both encryption and access controls to protect password data.
Most systems encrypt the data stored in the system's password file. Encryption (described in Chapter 7) transforms original information into altered information that usually has the appearance of random text. Encryption ensures that even if file security is somehow breached, the intruder won't be able to read the passwords in the file; they'll look like gibberish.
Most systems perform one-way encryption of passwords. One-way encryption means that the password is never decrypted–that is, deciphered into its original form. When the system administrator supplies you with your initial password, it's encrypted before it's stored in the password file. The original password is not preserved, not even in memory. Each time you log in and enter your password, the system encrypts the password you enter and compares the encrypted version with the encrypted password stored in the password file to be sure you've entered a valid password. Remember too that the password is never displayed on the terminal screen.
Even encrypted passwords might be able to be cracked by a determined foe. Many systems store encrypted password data in files known as shadow password files, which have the most restrictive protection available in the system. In most systems, access is limited to the system administrator, usually by specifying only the administrator's ID in an access control list (ACL) on the file. (See the discussion of access control lists in the next section.)