A hash function is an algorithm that takes a variable-length string as the input and produces a ﬁxed-length value (hash) as the output. The challenge for a hashing algorithm is to make this process irreversible; that is, ﬁnding
a string that produces a given hash value should be very difﬁcult. It should also be difﬁcult to ﬁnd two arbitrary strings that produce the same hash value. Also called a message digest or ﬁngerprint, several one-way hash functions are in common use today. Among these are Se-cure Hashing Algorithm-1 (SHA-1) and Message Digest-5 (MD-5). The latter was invented by Ron Rivest for RSA Security, Inc. and produces a 128-bit hash value. See Table 1 for an example of output generated by MD5. SHA-1 was developed by the U.S. National Institute of Standards and Technology (NIST) and the National Security Agency (NSA) and produces 160-bit hash values. SHA-1 is generally considered more secure than MD5 due to its longer hash value.
Microsoft Windows NT uses one-way hash functions to store password information in the Security Account Manager (SAM). There are no Windows32 Applications Programming Interface (API) function calls to retrieve user passwords because the system does not store them. It stores only hash values. However, even a hash-encrypted password in a database is not entirely secure. A cracking tool can compile a list of, say, the one million most commonly used passwords and compute hash functions from all of them. Then the tool can obtain the system account database and compare the hashed passwords in the database with its own list to see what matches. This is called a “dictionary attack” (see “Password Cracking Tools”).
To make dictionary attacks more difﬁcult, often a salt is used. A salt is a random string that is concatenated with a password before it is operated on by the hashing function. The salt value is then stored in the user database, together with the result of the hash function. Using a salt makes dictionary attacks more difﬁcult, as a cracker would have to compute the hashes for all possible salt values.
A simple example of a salt would be to add the time of day; for example, if a user logs in at noon using the pass-word “pass,” the string that would be encrypted might be “1p2a0s0s.” By adding this randomness to the password, the hash will actually be different every time the user logs in (unless it is at noon every day). Whether a salt is used and what the salt actually is depends upon the operating system and the encryption algorithm being used. On a FreeBSD system, for example, there is a function called crypt that uses the DES, MD5, or Blowﬁsh algorithms to hash passwords and can also use three forms of salts.
According to Cambridge University professor of computing Roger Needham, the Cambridge Multiple Access System (CMAS), which was an integrated online–ofﬂine terminal or regular input-driven system, may have been among the earliest to implement such one-way functions. It ﬁrst went online in 1967 and incorporated password protection. According to Needham: “In 1966, we conceived the use of one-way functions to protect the password ﬁle, and this was an implemented feature from day one” (R. Needham, personal communication, April 11, 2002).
One-way hashing is still being used today, although it does not address another weakness—in a networked environment, it is difﬁcult to transmit the password securely to the server for veriﬁcation without its being captured and reused, perhaps in a replay attack. To avoid revealing passwords directly over an untrusted network, computer scientists have developed challenge–response systems. At their simplest, the server sends the user some sort of challenge, which would typically be a random string of characters called a nonce. The user then computes a response, usually some function based on both the challenge and the password. This way, even if the intruder captured a valid challenge–response pair, it would not help him or her gain access to the system, because future challenges would be different and require different responses.
These challenge-and-response systems are referred to as one-time password (OTP) systems. Bellcore’s S/KEY is one such system in which a one-time password is calculated by combining a seed with a secret password known only to the user and then applying a secure hashing algorithm a number of times equal to the sequence number. Each time the user is authenticated, the sequence number expected by the system is decremented, thus eliminating the possibility of an attacker trying a replay attack using the same password again. One-time passwords were more prevalent before secure shell (SSH) and secure sockets layer (SSL) systems came into widespread use.
PASSWORD CRACKING TOOLS
As mentioned earlier, passwords are typically stored as values hashed with SHA-1 or MD5, which are one-way functions. In other words, this entire encyclopedia could be hashed and represented as eight bytes of gibberish. There would be no way to use these eight bytes of data to obtain the original text. However, password crackers know that people do not use whole encyclopedias as their passwords. The vast majority of passwords are 4 to 12 characters. Passwords are also, in general, not just random strings of symbols. Because users need to re-member them, passwords are usually words or phrases of signiﬁcance to the user. This is an opportunity for the attacker to reduce the search space.
An attacker might steal a password ﬁle–or sniff the wire and capture the user ID/password hash pairs during logon–and then run a password-cracking tool on it. Because it is impossible to decrypt a hash back to a pass-word, these programs will try a dictionary approach ﬁrst. The program guesses a password—say, the word “Dilbert.” The program then hashes “Dilbert” and compares the hash to one of the hashed entries in the password ﬁle. If it matches, then that password hash represents the pass-word “Dilbert.” If the hash does not match, the program takes another guess. Depending on the tool, a password cracker will try all the words in a dictionary, all the names in a phone book, and so on. Again, the attacker does not need to know the original password–just a password that hashes to the same value.
This is analogous to the “birthday paradox,” which basically says, “If you get 25 people together in a room, the odds are better than 50/50 that two of them will have the same birthday.” How does this work? Imagine a person meeting another on the street and asking him his birthday. The chances of the two having the same birthday are only 1/365 (0.27%). Even if one person asks 25 people, the prob-ability is still low. But with 25 people in a room together, each of the 25 is asking the other 24 about their birth-days. Each person only has a small (less than 5%) chance of success, but trying it 25 times increases the probability signiﬁcantly.
In a room of 25 people, there are 300 possible pairs (25*24/2). Each pair has a probability of success of 1/365 = 0.27%, and a probability of failure of 1 − 0.27% = 99.726%. Calculating the probability of failure: 99.726%300 = 44%. The probability of success is then 100% − 44% = 56%. So a birthday match will actually be found ﬁve out of nine times. In a room with 42 people, the odds of ﬁnding a birthday match rise to 9 out of 10. Thus, the birthday paradox is that it is much easier to ﬁnd two values that match than it is to ﬁnd a match to some particular value.
If a wave of dictionary guesses fails to produce any passwords for the attacker, the cracking program will next try a hybrid approach of different combinations—-such as forward and backward spellings of dictionary words, additional numbers and special characters, or sequences of characters. The goal here again is to reduce the cracker’s search space by trying “likely” combinations of known words.
Only after exhausting both of these avenues will the cracking program start in on an exhaustive or brute-force attack on the entire password space. And, of course, it re-members the passwords it has already tried and will not have to recheck these either during the brute-force search.
Approaches to Retrieving Passwords
Most password-cracking programs will ﬁrst attempt to retrieve password hashes to begin their cracking processes. A sophisticated attacker will not try to guess passwords by entering them through the standard user interface because the time to do so is prohibitive, and most systems can be conﬁgured to lock a user out after too many wrong guesses.
On Microsoft Windows systems, it typically requires the “Administrator” privilege to read the password hashes from the database in which they are stored. This is usu-ally somewhere in the system registry. In order to access them, a cracking tool will attempt to dump the password hashes from the Windows registry on the local machine or over the network if the remote machine allows network registry access. The latter requires a target Windows ma-chine name or IP address.
Another method is to access the password hashes directly from the ﬁle system. On Microsoft Windows systems, this is the SAM. Because Windows locks the SAM ﬁle where the password hashes are stored in the ﬁle system with an encryption mechanism known as SYSKEY, it is impossible to read them from this ﬁle while the system is running. However, sometimes there is a backup of this ﬁle on tape, on an emergency repair disk (ERD), or in the repair directory of the system’s hard drive. Alternately, a user may boot from a ﬂoppy disk running another operating system such as MS-DOS and be able to read password hashes directly from the ﬁle system. This is why security administrators should never neglect physical security of systems. If an attacker can physically access a machine, he or she can bypass the built-in ﬁle system security mechanisms .
Todd Sabin has released a free utility called PWDUMP2 that can dump the password hashes on a local machine if the SAM has been encrypted with the SYSKEY utility that was introduced in Windows NT Service Pack 3. Once a user downloads the utility, he or she can follow the instructions on the Web page to retrieve the password hashes, load the hashes into a tool such as L0phtCrack, and begin cracking them.
Instead of capturing the system user ﬁle (SAM on Windows or /etc/passwd or /etc/shadow on Unix/Linux), an-other way of collecting user IDs and passwords is through snifﬁng network trafﬁc. Snifﬁng uses some sort of soft-ware or hardware wiretap device to eavesdrop on network communications, usually by capturing and deciphering communications packets. According to Peiter “Mudge” Zatko, who initially wrote L0phtCrack: “Snifﬁng is slang for placing a network card into promiscuous mode so that it actually looks at all of the trafﬁc coming along the line and not just the packets that are addressed to it. By doing this one can catch passwords, login names, conﬁdential information, etc” (Zatko, 1999b).
L0phtCrack offers an “SMB Packet Capture” function to capture encrypted hashes transmitted over a Windows network segment. On a switched network, a cracker will only be able to sniff sessions originating from the local machine or connecting to that machine. As server mes-sage block (SMB) session authentication messages are captured by the tool, they are displayed in the SMB Packet Capture window. The display shows the source and destination IP addresses, the user name, the SMB challenge, the encrypted LAN manager hash, and the encrypted NT LAN manager hash, if any. To crack these hashes, the tool saves the session and then works on the captured ﬁle.
Recovering Windows NT Passwords
Or, why physical security is still important. Norwegian software developer Petter Nordahl-Hagen has built a resource (“The Ofﬂine NT Password Editor”) for recovering Windows passwords on workstations. His approach by-passes the NTFS ﬁle permissions of Windows NT, 2000, and XP by using a Linux boot disk that allows one to reset the Administrator password on a system by replacing the hash stored in the SAM with a user-selected hash. His program has even been shown to work on Windows 2000 systems with SYSKEY enabled. An MS-DOS version also exists, as does a version that boots from CD-ROM instead of ﬂoppy disk.
Thus, physical access to the workstation can mean instant compromise, unless, perhaps the system BIOS set-tings are also password-protected and do not allow a user to boot from ﬂoppy or CD-ROM (however, several attacks against BIOS settings have also been published).
Types of Password-Cracking Tools
Password-cracking tools can be divided into two categories—those that attempt to retrieve system-level lo-gin passwords and those that attack the password protection mechanisms of speciﬁc applications. The ﬁrst type includes programs such as L0phtcrack, Cain & Abel, and John the Ripper. Some sites for obtaining password-cracking tools for various platforms, operating systems, and applications are included in the Further Reading section at the end of this chapter.
The Russian company ElcomSoft has a developed a range of programs that can crack passwords on Microsoft Ofﬁce encrypted ﬁles, WinZip or PKZip archived ﬁles, or Adobe Acrobat (PDF) ﬁles. The U.S. federal government charged ElcomSoft with violating the Digital Millennium Copyright Act of 1998 for selling a program that allowed people to disable encryption software from Adobe Systems that is used to protect electronic books. The case drew attention after ElcomSoft programmer Dmitry Sklyarov was arrested at the DefCon 2001 convention in July, 2001 (US. ElcomSoft & Sklyarov FAQ, n.d.).
PASSWORD SECURITY ISSUES AND
Enforcing Password Guidelines
The FBI and the Systems Administration and Networking Security (SANS) Institute released a document summarizing the “Twenty Most Critical Internet Security Vulnerabilities.” The majority of successful attacks on computer systems via the Internet can be traced to exploitation of security ﬂaws on this list. One of items on this list is “ac-counts with no passwords or weak passwords.” In general, these accounts should be removed or assigned stronger passwords. In addition, accounts with built-in or default passwords that have never been reconﬁgured create vulnerability because they usually have the same password across installations of the software. Attackers will look for these accounts, having found the commonly known passwords published on hacking Web sites or some other public forum. Therefore, any default or built-in accounts also need to be identiﬁed and removed from the system or else reconﬁgured with stronger passwords.
The list of common vulnerabilities and exposures (CVE) maintained by the MITRE Corporation (http://www.cve.mitre.org) provides a taxonomy for more than 2000 well-known attacker exploits. Among these, nearly 100 have to do with password insecurities, and another 250 having to do with passwords are “candidates” cur-rently under review for inclusion in the list. The following provides a few samples:
Some Sample Password Vulnerabilities in the CVE List CVE-1999–0366:
“In some cases, Service Pack 4 for Windows NT 4.0 can allow access to network shares using a blank password, through a problem with a null NT hash value.”
CVE-2001–0465: “TurboTax saves passwords in a temporary ﬁle when a user imports investment tax informa-tion from a ﬁnancial institution, which could allow lo-cal users to obtain sensitive information.”
CVE-2000–1187: “Buffer overﬂow in the HTML parser for Netscape 4.75 and earlier allows remote attackers to execute arbitrary commands via a long password value in a form ﬁeld.”
CVE-1999–1104: “Windows 95 uses weak encryption for the password list (.pwl) ﬁle used when password caching is enabled, which allows local users to gain privileges by decrypting the passwords.”
CVE-2000–0981: “MySQL Database Engine uses a weak authentication method which leaks information that could be used by a remote attacker to recover the pass-word.”
CVE-2000–0267: “Cisco Catalyst 5.4.x allows a user to gain
access to the ‘enable’ mode without a password.”
CVE-1999–1298: “Sysinstall in FreeBSD 2.2.1 and earlier, when conﬁguring anonymous FTP, creates the ftp user without a password and with/bin/date as the shell, which could allow attackers to gain access to certain system resources.”
CVE-1999–1316: “Passﬁlt.dll in Windows NT SP2 allows users to create a password that contains the user’s name, which could make it easier for an attacker to guess” (Common Vulnerabilities, n.d.).
SANS suggests that to determine if one’s system is vulnerable to such attacks, one needs to be cognizant of all the user accounts on the system. First, the system security administrator must inventory the accounts on the system and create a master list. This list should include even intermediate systems, such as routers and gateways, as well as any Internet-connected printers and print controllers. Second, the administrator should develop procedures for adding authorized accounts to the list and for removing accounts when they are no longer in use. The master list should be validated on a regular basis. In addition, the administrator should run some password strength-checking tool against the accounts to look for weak or nonexistent passwords. A sample of these tools is noted in the Further Reading section at the end of this chapter.
Many organizations supplement password control programs with procedural or administrative controls that en-sure that passwords are changed regularly and that old passwords are not reused. If password aging is used, the system should give users a warning and the opportunity to change their passwords before they expire. In addition, administrators should set account lockout policies, which lock out a user after a number of unsuccessful login at-tempts, and cause him or her to have his password reset.
Microsoft Windows 2000 and Windows XP include built-in password constraint options in the “Group Policy” settings. An administrator can conﬁgure the network so that user passwords must have a minimum length, a minimum and maximum age, and other constraints. It is important to require a minimum age on a password.
The following outlines the minimal criteria for selecting “strong” passwords.
Guidelines for Selecting a Good Password
The goal is to select something easily remembered but not easily guessed.
Windows systems: seven characters or longer
Unix, Linux systems: eight characters or longer
Mixture of alphabetic, numeric, and special characters
(e.g., #, @, or !)
Mixture of upper and lower case characters
No words found in a dictionary
No personal information about the user (e.g., any part of the user’s name, a family member’s name, or the user;s date of birth, Social Security number, phone number, license plate number, etc.)
No information that is easily obtained about the user, especially any part of the user ID
No commonly used proper names such as local sports
teams or celebrities
No patterns such as 12345, sssss, or qwerty
Try misspelling or abbreviating a word that has some meaning to the user (Example: “How to select a good password?” becomes “H2sagP?”)
Password Aging and Reuse
To limit the usefulness of passwords that might have been compromised, it is suggested practice to change them regularly. Many systems force users to change their pass-words when they log in for the ﬁrst time, and again if they have not changed their passwords for an extended period (say, 90 days). In addition, users should not reuse old pass-words. Some systems support this by recording the old passwords, ensuring that users cannot change their pass-words back to previously used values, and ensuring that the users’ new passwords are signiﬁcantly different from their previous passwords. Such systems usually have a ﬁ-nite memory, say the past 10 passwords, and users can circumvent the password ﬁltering controls by changing a password 10 times in a row until it is the same as the previously used password.
It is recommended that, at a predetermined period of time prior to the expiration of a password’s lifetime, the user ID it is associated with be notiﬁed by the system as having an “expired” password. A user who logs in with an ID having an expired password should be required to change the password for that user ID before further access to the system is permitted. If a password is not changed before the end of its maximum lifetime, it is recommended that the user ID it is associated with be identiﬁed by the system as “locked.” No login should be permitted to a locked user ID, but the system administrator should be able to unlock the user ID by changing the password for that user ID. After a password has been changed, the life-time period for the password should be reset to the max-imum value established by the system.
With all the advances in technology, the oldest way to at-tack a password-based security system is still the easiest: coercion, bribery, or trickery against the users of the system. Social engineering is an attack against people, rather than machines. It is an outsider’s use of psycho-logical tricks on legitimate users of a computer system, usually to gain the information (e.g., user IDs and pass-words) needed to access a system. The notorious “hacker” Kevin Mitnick, who was convicted on charges of computer and wire fraud and spent 59 months in federal prison, told a Congressional panel that he rarely used technology to gain information and used social engineering almost exclusively (Federation of American Scientists, n.d.).
According to a study by British psychologists, people often base their passwords on something obvious and easily guessed by a social engineer. Around 50% of computer users base them on the name of a family member, a partner, or a pet. Another 30% use a pop idol or sporting hero. Another 10% of users pick passwords that reﬂect some kind of fantasy, often containing some sexual reference. The study showed that only 10% use cryptic combinations that follow all the rules of “tough” passwords (Brown, 2002).
The best countermeasures to social engineering attacks are education and awareness. Users should be instructed never to tell anyone their passwords. Doing so destroys accountability, and a system administrator should never need to know it either. Also, users should never write down their passwords. A clever social engineer will ﬁnd it if it is “hidden” under a mouse pad or inside a desk drawer.
Some Examples of Social Engineering Attacks
“Appeal to Authority” Attack. This is impersonating an authority ﬁgure or else identifying a key individual as a supposed acquaintance, in order to demand information. For example: A secretary receives a phone call from some-one claiming to be the “IT Manager.” He requests her user ID and password, or gives her a value to set her password to immediately because “there has been a server crash in the computer center and we need to reset everyone’s ac-count.” Once she has complied, he now has access to a valid user ID and password to access the system.
“Fake Web Site” Attack. The same password should not be used for multiple applications. Once a frequently used password is compromised, all of the user’s accounts will be compromised. A good social engineering attack might be to put up an attractive Web site with titillating content, requiring users to register a username and password in or-der to access the “free” information. The attacker would record all passwords (even incorrect ones, which a user might have mistakenly entered thinking of another ac-count), and then use those to attack the other systems fre-quented by the user. The Web site could even solicit infor-mation from the users about their accounts—for example, what online brokerage, banking, and e-mail accounts they used. Web site operators can always keep a log of IP ad-dresses used to access the site and could go back to attack the originating system directly.
“Dumpster Diving” Attack. Many serious compromises are still caused by contractors and third parties throwing away draft instruction manuals, development notes, etc., with user IDs and passwords in them. Social engineers may employ “dumpster diving,” that is, digging through paper printouts in the trash looking for such signiﬁcant information to gain system access.
Article Will Be Continue In Next Post….
Post Credited From Encyclopedia Of Communication & Internet
Source Encyclopedia Of Internet Page 38 to 43