When authenticating a users password, the password supplied by the user is authenticated
|
Timothy J. Shimeall, Jonathan M. Spring, in
Introduction to Information Security, 2014 The computer must store some information to match against the user-supplied password.
In the first implementations, this was simply a file with one column for the user name and one column for the matching password, in plaintext. This makes checking passwords a trivial operation—the computer just checks if the input password matches the column in the password file. However, there are some obvious problems with storing passwords in plaintext. Even if only privileged users of the system have permission to read the file, those users will know everyone’s passwords. Furthermore, if any
malicious user gains such privileges, the attacker instantly gains everyone’s password. On Linux and Unix systems there was incremental improvement. The password verification information was stored in /etc/passwd and was readable by everyone, but it was obscured. It was obscured using the Data Encryption Standard (DES), the standard algorithm at the time. The action was to obscure, not encrypt; there is a technical difference between those two
words. Encryption using DES means that the information is recoverable, or that the process is reversible, given the key. However, in the Unix password system, the user’s password was the key, and the starting text was known: a string of all zeros. To verify the user’s password, the computer would encrypt this string using the password as the key, and if the resulting string matched the contents in the /etc/passwd file, then the user was considered authentic. This is a one-way function—an attacker cannot recover the password by reversing some function of the resulting string using the “key.” If the attacker can, it doesn’t matter, because that is the password, which is the critical piece of information anyway. One-way functions are not encryption—there is no “key” in the same way. Encryption is a two-way function. One-way functions are called hash functions. Hash functions
have many uses in information security. Encryption is covered in Chapter 8; hashes are touched on in Chapter 8 as well and explored more in Chapter 14. There are severasl shortcomings with this approach, which became apparent as computing speeds increased and internetworking exposed more computers to attacks. First, due to the features of the DES algorithm, the key is only 56 bits long. This amounts to 8 ASCII
characters. Anything longer was thrown away when calculating the password match. For example, if my password were “hippopotomonstrosesquipedaliophobia,” an attacker could gain access to my account by just typing “hippopot” at the password prompt. Furthermore, password guessing became easier with faster computers. Since the /etc/passwd file was readable, anyone with system access could try to guess the password that would result in the hashed
string stored in the file. The original Unix password system took this into account. First, when hashing the password and checking user credentials, DES is actually run 25 times, instead of just once. This does not add extra randomness or further obscure the text or key. It just takes longer. This is not noticeable to a regular user—it is the difference between a couple hundred microseconds and a couple milliseconds. However, it makes it significantly harder to go through guessing millions of
passwords. Second, the passwords were salted. A salt is a number that changes the configuration of the password verification algorithm, so that two users with the same password will not produce the same hashed text. This is important, because if the obscured text is the same, then the password used to generate it is the same, and so without additional obscurity all users with the same password would know who shares their password. The salt bits are appended
in plaintext to the hashed string. They do not add security to an individual user, but to a group of users. Due to the features of the DES algorithm, there were 4,096 (212) possible salts. Therefore, if one system had fewer than 4,096 users, the system could guarantee that no two users would have the same entry in the /etc/passwd file. As will be explained in the “Attacks” section, both the 56-bit password and the 12-bit salt are too
small on modern systems, with millions of users [6] and supercomputers available for rent [7]. The mathematics behind how a password is sufficiently large is unintuitive when many users are involved, because the adversary often only needs access to one account to escalate privileges. As more users are involved, the chances that someone picked a weak password is nearly certain. Despite
modern computational shortcomings, conceptually the Unix approach to storing and checking passwords is valid. Namely, store the result of a one-way function of the password and salt the function; one adjustment though: do not allow any user to read the results. The /etc/passwd file is still in use today, but with different parameters, and different algorithms used to hash the password. The hashes are stored in /etc/shadow, which only the superuser can read
[8]. This does not mean that all systems use a robust checking or storage mechanism. Several million-user web companies were found not to have salted their password files, as described in the “Attacks” section. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597499699000079 Building and maintaining a secure networkBranden R. Williams, ... Derek Milroy, in PCI Compliance (Fourth Edition), 2015 Default passwordsDefault passwords exist with almost every operating system and application. Requirement 2.1 states that all vendor-supplied passwords must be changed before deploying a system on the network. Requirement 2.1.1 imposes the same mandate for wireless environments. Password policies and procedures are usually dictated by the organization. Although there are several alternatives for authentication like biometrics, smart cards, and tokens, most of us use the traditional user ID and password. Additionally, if your organization has a procedure for adding new users and granting them access to systems, there may be some default passwords that you haven’t thought about. If you can remember back to when you first received your user ID and password, you might recall that it was a preset generic password (does Password123 or Welcome1 sound familiar?). Before PCI DSS required otherwise, many system administrators used the same generic password for all new users. If your company has not changed its new user process globally to reflect the more stringent requirements for users with access to cardholder data, you may end up with some users that have generic passwords. For more information on this, see Chapter 6. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128015797000054 Resilience Against Physical AttacksMartin Hutle, Markus Kammerstetter, in Smart Grid Security, 2015 4.2.8.1 Timing AttacksTiming attacks (Kocher, 1996) exploit data-dependent execution time differences. Consider the password check illustrated in Listing 4.1. The password check uses the user-supplied passwordpasswd and compares it against a stored one. At the first glance the password checking routine seems to be secure if a long enough password is used to thwart password guessing attacks. However, a close look into the code reveals that the password immediately returns “false” as soon as the first character in the supplied password is different from the stored one. Instead of a conventional brute force password guessing attack, an attacker can thus measure the time between sending the password guess to the system and the response that the supplied password was wrong. However, if the first character was correct, this response will come back to the attacker a short period of time later since the loop in the password check is executed once again. Due to this timing information, the correct password can be easily guessed in comparison to a conventional brute force attack. However, as the approach needs reliable timing measurements averaging steps are often necessary so that over a higher number of measurements potential non-data-dependent timing differences can be filtered. In fact, this approach works so well that vulnerable cache-timing software implementations can be even attacked over multiple hops on the Internet (Brumley & Boney, 2003).  Listing 4.1. Password check implementation that is prone to a timing attack. Example Smart meters typically have an optical port allowing service and configuration settings to be changed. Since many values can neither be read nor written without the utility password, an attacker uses a low-cost optical interface (Figure 4.9) and measures the response timing for password guesses. Using these attacks, s/he discovers that the password check is vulnerable to timing attacks and the password can thus be easily guessed by the attacker. Figure 4.9. Optical interface connected to a smart meter for optical timing analysis testing. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9780128021224000043 File Sharing ProgramsIn Securing HP NonStop Servers in an Open Systems World, 2006 RISKIf the service specifies
a user = list in the smb.conf file and the username is specified as a group name (@ 6. If the service is a guest service, then a connection is made as the username specified by the guest account keyword in the smb.conf file, regardless of the password supplied. 7.If the requested name is found, the user's home directory is determined. 8.If a matching username is not located, Samba denies the connection and returns an error message to the client. Once the connection request is made, the Samba server (smbd) scans the smb.conf file looking for a service (stanza) that matches the one requested. On the HP NonStop implementation of Samba, the /etc/passwd file is not used. No Safeguard authentication is performed. The smbd process for a connection runs as SUPER.SUPER until it is necessary to perform some operation on behalf of the connected user. At that time, the process uid becomes the user's userid. Once the task it complete, the process switches back to SUPER.SUPER. RISKBecause the smbd server runs as SUPER.SUPER, it is difficult to determine which smbd process belongs to which user. Use the smbstatus program to display the list of connected users. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781555583446500081 Security
James McGovern, ... Sunil Mathew, in Java Web Services Architecture, 2003 DesignPrivacy for Web services and the sensitivity of the messages over the public Internet could mandate the use of encryption in your architecture. Encryption is the act of taking data (usually referred to as clear text) and a short string (the key) and producing data (cipher text). The resulting cipher text is meaningless to a third party who does not know the key. Decryption is the inverse of encryption: taking cipher text and key and producing clear text. Password encryption derives an encryption key from a user-supplied password. To make the task of discovering the key from the password more time-consuming, many implementations mix in a random variable, known as a salt, to create the key. Several industry-standard algorithms can be chosen for a custom encryption mechanism. One of the elements to consider is whether the encrypted data needs to be decrypted once encrypted. Some algorithms are appropriate for one-way encryption, typically used in login and authentication scenarios. One-way encryption prevents the data from being reversed, which is important for credentials. Two-way encryption allows for reversible encryption. A key agreement is a protocol in which two or more parties establish the same cryptographic keys without exchanging any secret information. Message authentication codes are a way for two parties to check the integrity of information stored in or transmitted over an unreliable medium and are based on a secret key. Typically, both parties have the same key, referred to as a shared secret. Using Secure Sockets Layer to access your Web service will prevent “man-in-the-middle” attacks and stop data from being read or modified in transit. As previously mentioned, SSL does require additional processing overhead if done in software. This can be alleviated by using SSL accelerator network-interface cards. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781558609006500208 Data EncryptionIn The Best Damn Exchange, SQL and IIS Book Period, 2007 Hierarchal EncryptionSQL Server 2005 uses a hierarchal encryption and key management model. Each level in the hierarchy encrypts the layer underneath. The foundation of the SQL Server 2005 encryption hierarchy depends on Data Protection API (DAPI), which is native in all Windows 2000 and newer operating systems. SQL Server 2005 relies on DAPI to create the SQL Server Service Master and Database Master Keys. Once these keys have been created, you can create database encryption keys, certificates, and pass-phrases, and use them to encrypt database data. An illustration of the hierarchal encryption model can be found in Figure 26.1. Figure 26.1. The Hierarchal Encryption Model Native SQL Server 2005 data encryption is restricted to the encryption and decryption of the varbinary data type. This encryption can be performed down to the cell level, meaning that the contents of each column within each row can be encrypted using different encryption keys, certificates, and pass-phrases. Depending on the data types currently used within your database, implementing native data encryption may require schema changes and/or data type conversions to the varbinary data type. When a SQL Server 2005 instance is started for the first time, a 128-bit 3DES symmetric Service Master Key is automatically created and encrypted, using both the active SQL Server service account credentials and the machine credentials. This way, if one becomes corrupt, SQL Server 2005 can still access the key using the other method. This Service Master Key is the single most important key within your SQL Server instance, because it is ultimately used to encrypt all other keys within the database instance. Additionally, the key is used to encrypt SQL Server-linked server passwords, connection strings, and account credentials. Immediately after starting SQL Server 2005 for the first time, you should backup the Service Master Key. To protect the Service Master Key backup file, it is encrypted using a user-supplied password. You should make sure that this password is securely stored within a password management solution and readily available, as you will not be able to restore the Service Master Key backup without it. The syntax for the BACKUP SERVICE MASTER KEY statement is as follows: BACKUP SERVICE MASTER KEY TO FILE = ‘FILE’ ENCRYPTION BY PASSWORD = ‘PASSWORD’ Here are definitions of two arguments of this syntax: ■FILE Specifies the directory path and the filename in which to create the key backup file. ■PASSWORD The password used to encrypt the Service Master Key backup file. You will need the CONTROL SERVER permission on the database server to run the BACKUP SERVICE MASTER KEY statement. The following syntax uses the BACKUP SERVER MASTER KEY statement to back up the Service Master Key, and encrypts the backup file with the user-supplied password: BACKUP SERVICE MASTER KEY TO FILE = ‘C:\backup\keys\Service_Master.key’ ENCRYPTION BY PASSWORD = ‘[email protected]&XeEl67’ It is possible that the Service Master Key may be accidentally disclosed, corrupted, or will need to be proactively recycled for security reasons. You can regenerate a new random Service Master Key using the ALTER SERVICE MASTER KEY statement. The common syntax for the ALTER SERVICE MASTER KEY statement is as follows: ALTER SERVICE MASTER KEY [FORCE] REGENERATE Let’s analyze the following arguments of this syntax: ■FORCE Regenerates the Service Master Key regardless of encountered errors. ■REGENERATE Regenerates the Service Master Key. For a listing of additional statement arguments, please see SQL Server 2005 Books Online. To execute the ALTER SERVICE MASTER KEY statement, you will need the CONTROL SERVER permission within the database server. The following syntax regenerates a new random Service Master Key: ALTER SERVICE MASTER KEY REGENERATE You can use the RESTORE SERVICE MASTER KEY statement to restore a previously backed up Service Master Key. The syntax for the RESTORE SERVICE MASTER KEY statement is as follows: RESTORE SERVICE MASTER KEY FROM FILE = ‘FILE’ DECYRPTION BY PASSWORD = ‘PASSWORD’ [FORCE] Now let’s analyze some of the arguments of this syntax: ■FILE Specifies the directory path and filename of the key to be backed up. ■PASSWORD Indicates the password used to encrypt the Service Master Key backup file. ■FORCE Replaces the Service Master Key regardless of encountered errors. You will need the CONTROL SERVER permission on the database server to run the RESTORE SERVICE MASTER KEY statement. The following syntax restores our previously backed up Service Master Key using the RESTORE SERVICE MASTER KEY statement: RESTORE SERVICE MASTER KEY FROM FILE = ‘C:\backup\keys\Service_Master.key’ DECRYPTION BY PASSWORD = ‘[email protected]&XeEl67’ Underneath the Service Master Key in the hierarchal encryption model is the Database Master Key. A Database Master Key is a 128-bit 3DES symmetric key, which is encrypted using a user-supplied password and stored within the database. Each database can have only one Database Master Key, and this key is used exclusively by SQL Server for the management of other keys. Database Master Keys are not created by default, and must be manually created in a database. To create a Database Master Key, you can use the CREATE MASTER KEY statement, which has the following syntax: CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘PASSWORD’ In this statement, PASSWORD specifies the password used to encrypt and protect the database master key. You will need the CONTROL permission within the database in order to run the CREATE MASTER KEY statement. The following syntax creates a Database Master Key and encrypts it with the user-supplied password: CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘@iLz&7%DyUio16’ When a Database Master Key is created, a backup is also performed, and is encrypted using the Service Master Key and stored within the Master database. This feature is referred to as Auto Key Management and ensures that there is a Database Master Key backup and that SQL Server can decrypt and use the Database Master Key as required, without knowing the user-supplied password. A downside to Auto Key Management is that users with sysadmin privileges can use the Service Master Key to gain access to the Database Master Key. To alter the properties of the Database Master Key, including disabling the Auto Key Management feature, you can use the ALTER MASTER KEY statement: ALTER MASTER KEY [FORCE] [REGENERATE WITH ENCRYPTION BY PASSWORD = ‘PASSWORD’| ADD ENCRYPTION BY [PASSWORD = ‘PASSWORD’ | SERVICE MASTER KEY] | DROP ENCRYPTION BY [PASSWORD = ‘PASSWORD’ | SERVICE MASTER KEY] Here are explanations of some of the arguments of this syntax: ■FORCE Regenerates the Database Master Key regardless of encountered errors. ■REGENERATE WITH ENCRYPTION BY PASSWORD Regenerates the Database Master Key and all keys that it protects. ■PASSWORD Specifies the password in which to encrypt or decrypt the Database Master Key. ■ADD ENCRYPTION BY Encrypts the Database Master Key with a user-supplied password or the Service Master Key. ■DROP ENCRYPTION BY Removes password or Service Master Key encryption applied to the Database Master Key. To execute the ALTER MASTER KEY statement you will need the CONTROL permission within the database. The following syntax regenerates a Database Master Key: ALTER MASTER KEY REGENERATE WITH ENCRYPTION BY PASSWORD = ‘9m87hU&X^6Z6%R’ Shortcut…Disabling Master Key EncryptionTurning off Master Key encryption prevents sysadmins from having global access to the keys required to decrypt data. However, SQL Server decrypts encrypted data before processing, and stores this data in memory. This data can be retrieved from memory by a system admin as required. Once encryption by Master Key is disabled, anyone needing to access the Database Master Key will need to know the password that was used to encrypt it. This includes SQL Server, which will no longer be able to load the Database Master Key at server start-up. Therefore, each time you need to use the Database Master Key, you will need to manually open and close it using the OPEN MASTER KEY and CLOSE MASTER KEY statements. You should weigh the pros and cons with disabling the Master Key encryption when determining what works best for your database systems. Even if Auto Key Management is enabled, the backup Database Master Key still resides on the server and should be backed up and stored at a secure off-site location. You can use the BACKUP MASTER KEY statement to perform a manual backup of the Database Master Key. The syntax of this statement is as follows: BACKUP MASTER KEY TO FILE = ‘FILE’ ENCRYPTION BY PASSWORD = ‘PASSWORD’ Here are definitions of the arguments of this syntax: ■FILE Specifies the directory path and the filename in which to create the backup file. ■PASSWORD Specifies the password used to encrypt the Database Master Key backup file. To execute the BACKUP MASTER KEY statement, you will need the CONTROL permission within the database. The following syntax uses the BACKUP MASTER KEY statement to back up the Database Master Key, and encrypts it with the supplied password: BACKUP MASTER KEY TO FILE = ‘C:\backup\keys\Database_Master.key’ ENCRYPTION BY PASSWORD = ‘9m87hU&X^6Z6%R’ Similar to the Service Master Key, the password used to protect the Database Master Key backup will be needed again to restore the key, so you should be sure to keep it safe. To restore your Database Master Key from backup, you can use the RESTORE MASTER KEY statement: RESTORE MASTER KEY FROM FILE = ‘FILE’ DECRYPTION BY PASSWORD = ‘PASSWORD’ ENCRYPTION BY PASSWORD = ‘PASSWORD’ [FORCE] Here are definitions of the arguments of this syntax: FILE Specifies the directory path and the filename in which to create the backup file. ■DECRYPTION BY PASSWORD Specifies the password required to decrypt the Database Master Key backup file. ■ENCRYPTION BY PASSWORD Specifies the password used to encrypt the imported Database Master Key. ■FORCE Replaces the Database Master Key regardless of encountered errors. You will need the CONTROL permission with the database to run the RESTORE MASTER KEY statement. When a Database Master Key is restored, SQL Server first decrypts all encrypted keys and then encrypts the keys with the newly created Database Master Key. If errors are encountered at any point during the associated decryption process, the entire restore process will fail. However, you can use the FORCE argument to perform the restore regardless of any encountered errors. Please note that this can result in the loss of encryption keys and associated data, so use this option with caution. The following syntax uses the RESTORE MASTER KEY statement to restore our previously backed up Database Master Key, and encrypts it with the supplied password: RESTORE MASTER KEY FROM FILE = ‘C:\backup\keys\Database_Master.key’ DECRYPTION BY PASSWORD = ‘9m87hU&X^6Z6%R’ ENCRYPTION BY PASSWORD = ‘J#yAsdl8z)f3tq’ SQL Server is intelligent and will not unnecessarily decrypt and re-encrypt data. In the preceding syntax, we restored the same Database Master Key that was present within the database. SQL Server should have returned a message stating that the old and new master keys were identical, therefore decrypting data and re-encrypting with the same Database Master Key was not required. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597492195000261 What to Do When They Ask for Your Social Security Number*Chris Hibbert, in Computerization and Controversy (Second Edition), 1996 Private OrganizationsThe guidelines for dealing with nongovernmental institutions are much more tenuous. Most of the time private organizations that request your Social Security Number can get by quite well without your number, and if you can find the right person to negotiate with, they will willingly admit it. The problem is finding that right person. The person behind the counter is often told no more than “get the customers to fill out the form completely.” Most of the time, you can convince them to use some other number. Usually the simplest way to refuse to give your Social Security Number is simply to leave the appropriate space blank. One of the times when this isn't a strong enough statement of your desire to conceal your number is when dealing with institutions that have direct contact with your employer. Most employers have no policy against revealing your Social Security Number; they apparently believe that it must be an unintentional slip when an employee doesn't provide an SSN to everyone who asks. Public utilities (gas, electric, phone, etc.) are considered to be private organizations under the laws regulating SSNs. Most of the time they ask for an SSN, and aren't prohibited from asking for it, but they will usually relent if you insist. See the other suggestions above in the section “What You Can Do To Protect Your Number” for more ideas. Lenders and Borrowers: Those Who Send Reports to the IRSBanks and credit card issuers and various others are required by the IRS to report the SSNs of account holders to whom they pay interest or from whom they collect it. If you do not tell them your number you will probably either be refused an account or be charged a penalty such as withholding of taxes on your interest. Most banks send your name, address, and SSN to a company called ChexSystem when you open an account. ChexSystem keeps a database of people whose accounts have been terminated for fraud or chronic insufficient funds in the past five years. ChexSystems is covered by the Fair Credit Reporting Act, and the bank is required to let you know if it refuses to open your account and a report from ChexSystems was a factor. You can also send a letter to ChexSystems directly (Consumer Relations, 1550 E. 79th Street, Suite 700, Minneapolis, Minnesota 55425) and request a copy of their report on you. Many banks, brokerages, and other financial institutions have started implementing automated systems to let you check your balance. All too often, they are using SSNs as the PIN that lets you get access to your personal account information. If your bank does this to you, write them a letter pointing out how common it is for the people with whom you have financial business to know your SSN. Ask them to change your PIN, and if you feel like doing a good deed, ask them to stop using the SSN as a default identifier for their other customers. Some customers will believe that there's some security in it, and be insufficiently protective of their account numbers. Sometimes banks provide for a customer-supplied password, but are reluctant to advertise it. The only way to find out is to ask if they will let you provide a password. When buying (and possibly refinancing) a house, most banks will now ask for your Social Security Number on the Deed of Trust. This is because the Federal National Mortgage Association recently started requiring it. The fine print in their regulation admits that some consumers won't want to give their number, and allows banks to leave it out when pressed. (It first recommends getting it on the loan note, but then admits that it is already on various other forms that are a required part of the package, so they already know it. The Deed is a public document, so there are good reasons to refuse to put it there, even though all parties to the agreement already have access to your number.) Insurers, Hospitals, DoctorsNo laws require private medical service providers to use your Social Security Number as an ID number. They often use it because it is convenient or because your employer uses it to identify employees to its group's health plan. In the latter case, you have to get your employer to change their policies. Often, the people who work in personnel assume that the employer or insurance company requires use of the SSN when that is not really the case. When a previous employer asked for my SSN for an insurance form, I asked them to find out if they had to use it. After a week they reported that the insurance company had gone along with my request and told me what number to use. Most insurance companies share access to old claims through the Medical Information Bureau. If your insurance company uses your SSN, other insurance companies will have a much easier time finding out about your medical history.3 If an insurance agent asks for your Social Security Number in order to “check your credit,” point out that the contract is invalid if your check bounces or your payment is late. Insurance is always prepaid, so they do not need to know what your credit is like, just whether your check cleared. Blood BanksBlood banks also ask for the number but are willing to do without if pressed on the issue. After I asked politely and persistently, the (non-Red Cross) blood bank I go to agreed that they didn't have any use for the number. They have now expunged my SSN from their database, and they seem to have taught their receptionists not to request the number. I have gotten many reports that the Red Cross has a national policy of requiring SSNs. Blood banks have changed their policies back and forth a few times in the last several years. When the AIDS epidemic first hit, they started using SSNs to identify all donors, so someone who was identified as HIV-positive at a blood bank wouldn't be able to contaminate the blood supply by donating at a different site. For a few years, they were a little looser, and though they usually asked for SSNs, some would allow you to donate if you provided proof of your identity. (I showed a driver's license, but didn't let them copy down the number.) Now the federal government has declared blood banks to be “manufacturers” of a medical product, and has imposed various quality control processes on them. The blood bank I go to now asks for SSNs, but, if you refuse, allows you to give a driver's license number. I balked at that, since I hadn't had to give it before. They let me donate, but while I was eating cookies, the director of Quality Control came down and talked to me. After a little bit of discussion, she was satisfied to have me pick an ID number that I promised to remember and provide when I visited gain. So, once again, if you want to protect your SSN and your privacy, it pays to push back when they ask. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B978012415040950141X Information GatheringCraig Wright, in The IT Regulatory and Standards Compliance Handbook, 2008 Side Issues with Gathering PasswordsPassword testing is an important ingredient in testing (esp. penetration testing and ethical hacking) and audits. Weak passwords lead to system compromise more times than not. In later chapters we look at a number of the tools associated with both password cracking and guessing including Cain & Able and Brutus respectively. The unfortunate truth is that passwords alone remain a crucial component of many security systems. Even secured access over virtual private networks (VPNs), Secure Shell, Web applications, databases and e-mail using only a username and password remains the standard for most organizations. In the ideal world, all access would be provided using two-factor methods NoteTwo-factor authentication is an expression used to denote an authentication mechanism where more than one verification method is essential to authenticate a user. The most commonly implemented method to provide two-factor authentication includes a selection of the following: ▪Something you know ▪Something you have ▪Something you are Conventional authentication methods have used the combination of a username and password to authenticate users. The level of security provided with this method is minimal due to problems as diverse as users sharing passwords to password cracking. Two-factor authentication, can still use a password. In this scheme, the password provides the “something you know” element. User Name HarvestingTo guess passwords, an attacker needs to know a username. Some usernames are easy to guess (such as the UNIX root user) and should be controlled in such a way that their access is restricted (such as no root logins over the Internet – ever) and logged. Attempts to log into any system using root accounts (or domain administrator accounts in windows or the equivalent in other systems) should be closely monitored with both successful and failed attempts treated as an incident. Nearly all modern systems allow for system logins using an unprivileged account with an escalation process to a privileges state. In UNIX, the “su” (or even sudo and others) command and in Windows the “run-as” feature provides the capability to log onto a system using an unprivileged account and subsequently to become privileged. Network equipment such as Cisco uses the “enable” functional states. In all cases, it is the exception rather than the rule that requires a privileged account for remote authentication. There is rarely an excuse for allowing privileged accounts to be used for an initial authentication to a system. When a user fails to logon to a system, an error message will generally be displayed stating the user has not succeeded in authenticating to the system. The resultant error message can supply an attacker with intelligence that they may use to harvest valid usernames. Think about the two following error messages: Configuration 1 - Correct Username but an invalid password “The password supplied is not valid for this user. Please try again”. Configuration 2 - Incorrect Username “The Username supplied is not configured on this system”. The error message specifies to an attacker if the username or password is invalid selectively. This provides the necessary information for an attacker to determine the systems user credentials. In this set-up, an attacker can resolve valid usernames through a dictionary or brute-force attack against the system. Where possible, do not allow the error messages from failed logon attempts to implicitly state whether the failure was a consequence of the username or the password. Only return an error stating that the amalgamation of the credentials is incorrect. Linux and UNIX have both integrated these techniques, but many web applications have bypassed this functionality. More on PlanningBefore any audit is started, there are a number of pre-audit activities that must be completed. These include research, the determination of scope, an agreement on an audit strategy, the creation of the checklist and subsequently, the formulation of a number of audit procedures based on the systems that have been defined in the scope. Without adequate planning, you can be assured from the start that the audit will not work. Encourage your auditors and other members of review teams to seek project management certifications. Certifications such as the PMI project management certification aid audit staff in creating a project based approach. Like projects, audits consist of a number of phases, each reliant on the last. If any of the preceding stages have not completed sufficiently and not produced the necessary input for the subsequent stages, then these will likely fail. The creation of separate milestones and target goals within the audit process is thus reliant on a stage of planning and research that cannot be overlooked. This also leads to the agreement stage. By planning the scope sufficiently, the audit team, security team and management are all likely to agree, creating a situation where the work is authorized and it is less likely that disagreements will arise. While this is being done, the audit staff should work with other members of the team to come up with a strategy for auditing the systems. While they're engaged in this process, they should start formulating a checklist seeking consensus and agreement between the different members of the team. The aim should be to meet the compliance goals, secure systems, and provide returns on the organization's investment, all at the same time. This may seem an impossible goal, but in effect, reducing costs through forward planning often provides benefits down the track. ResearchThe research stage involves basically finding the ‘how to’ of the audit. Later in the book, the chapters concerning the technical aspects of audit will cover much of the ‘how to’ section. Some of the best sources however to research include SANS and the Centre for Internet Security. These sites provide best practice guidelines and step by step guides to the securing of many systems. Based on a number of sources such as NIST and DISA, these guides provide a widely agreed framework for the provision of information security services. At the same time, it is worth instigating a program to map the various frameworks that you need to be compliant with to the control framework that is being put in place to manage your systems. Planning ScopeA scope needs to be planned out between multiple parties. The audit team needs to work with management and possibly technical people within the organization in order to define a scope that will both achieve goals needed for the organization. Generally, a statement of purpose will be provided for the audit. This initial document will be the template for deriving the scope of the audit. The secret however is communication. Good communication means going and speaking to a variety of parties and gaining a consensus view of what is needed to fulfill the initial statement of purpose for the audit. It is essential that the scope covers why. The scope definition should be realistically agreed upfront. This should be a process where management auditors get together initially and agree a scope. It should not be a dragged out process involving many meetings, and ideally it should be agreed on the initial planning meeting. If you are uncertain, clarify upfront. If you have to go back and forth asking questions, calling multiple meetings, it is unlikely that you will gain confidence and trust from the organization that you are auditing. Audit StrategyIn the preceding section we covered the ‘what’ stage. By researching the audit purpose, we answered what we needed to do. Next we need to know how. We need to create a strategy that will allow us to successfully complete the audit. Think about the information that we may need for the audit. Are we looking at baselining the system or are we looking at prolonged engagement where we monitor logs and trace counters over time? The ‘how’ needs to answer the ‘what’. What are we trying to achieve? It is important to be creative in audits. It is essential not to remain focused on checking configuration settings, but rather to investigate many alternative sources of information. The essential strategy is to understand what systems are in place at the organization you're auditing and to implement those to the best of your ability to answer the question of what is occurring on the system. In order to perform this, we need to gather a variety of information. We need to consider the tools that may be used in the engagement. We need to consider the amount of capability each of these tools has to measure the data we need to gather. Next we need to consider the personnel we need in the audit. It may be that you need to run tools such as Snort or TCP Dump to capture information across the network. In this case, the auditor without network tool experience should involve other personnel from the organization with the required expertise. Scope Also Covers TimeAll audits should be treated as a project. As was noted above, audit stages should occur as per set timelines. By working to a set timeline, the auditor can maximize their chances of achieving the goals set within a budget. Audits Are ProjectsLike projects, any audit can be broken into five stages: 1Initiating, 2Planning, 3Executing, 4Controlling and monitoring, and 5Closing. Similar to the nine knowledge areas of the project management institute, any audit requires integration management, scope management, time management, cost management, quality management, human resource management, communications management, risk management, and procurement management. The alignment between audit and project management means that many of the standard project management tools including PMBOK, Microsoft Project, UML Diagrams and even Six Sigma, may be applied to the audit process. Like any other process, audit has an element of risk and minimizing that risk is an important aspect associated with any successful compliance program. These processes may be used to measure and provide metrics on the audit process itself. Measurements may be taken against aspects such as project cost and the adherence to the audit timeframes. In looking at this, it is possible to compare audit costing against projected budgets and possible overruns as well as measuring audit timeframes and deliverables. Lastly, it is recommended that any audit project is planned with set milestones. It is recommended that the audit leader gains familiarity with the PMI system or some other similar project system that will provide the necessary results within your organization. If the project leader does not have these skills, it may be possible to bring in a project manager from other parts of the organization to help with the audit. Password ManagementBoth cost and compatibility (in particular based on legacy systems) has left the widely deployed form of user authentication as the password. Passwords are simply secret words or phrases. They are regularly compromised through: ▪Being written down or shared (hence not really being secret). ▪Password guessing as if covered in detail later in this chapter. ▪Password cracking as if covered in detail later in this chapter. ▪Passwords are commonly transmitted in (plain or) clear text or encoded using an insecure method that may be converted to clear text. ▪Passwords may be stored on a PDA, workstation, server, backup media or about any other physical medium that an attacker can access in clear text. (They can similarly be encoded using an insecure method when stored). The flaws and vulnerabilities inherent in any password scheme makes password attacks a prime method used by attackers in gaining access to systems. Many users will have multiple passwords set to protecting the access to distinct systems. Humans have limitations. It is difficult for (most) people to manage: ▪Complicated and complex passwords ▪Numerous different passwords ▪Frequently changing passwords ▪Passwords that are not used frequently Users make password management difficult. When they are not trained and made aware of the issues, they will: ▪Write their passwords on post-it notes and notepads thus limiting the security provided to that protection associated with the paper or note. ▪Try to use simple, easily compromised passwords based on things that they remember (such as family names). ▪Forget their passwords, thus increasing the cost to the organization by requiring assistance and using help desk resources. ▪Use tried and true passwords (or combinations of these) as frequently as they can. Effective password management needs to take human limitations into consideration. To defend against password guessing, hard-to-guess passwords are needed. This may be achieved by ensuring that feasible set of passwords that a user can set is too large to be searched in any reasonable amount of time. The set of possible password combinations is derived through calculating the amount of valid characters that may be selected by the user and factoring this to the power of the number to the length of the password (in characters). The number of valid password combinations that may be created are displayed in Table 5.4. Table 5.4. Password Strength
A systems password rules and the password policy needs to be designed to maximize the possible password search space. The larger this is, the more difficult it will be for an attacker. To do this, ensure either that: ▪Passwords are at least eight characters in length (and for some systems this may be longer). ▪Passwords need to consist of at least one letter, and at least one digit. ▪Where possible, passwords must contain both uppercase and lowercase letters. ▪Good passwords should also contain at least one punctuation mark or other “special” character. Never allow passwords that: ▪Are based on the user's name or logon account. ▪Are based on a dictionary word, in any language (not even Klingon). Pass PhrasesFar better than a password is a pass phrase. This is a password based on a sentence or other combination that the user can remember. For instance, the pass phrase below is far simpler than an 8 character password with all the trimming: Pass phrases are better than passwords The above pass phrase is 38 characters long and it is infeasible that it would be cracked in anyone's life time. It is not necessary to have a passphrase as long as the example, but this gives the idea. A 16–20 character pass phrase is more complex than the majority of passwords that will ever be created. Even better, adding a few minor substitution rules will increase the complexity incredibly: Incredidly difficult to crack A passphrase with the addition of a few numerical substitutions becomes far more complex and still allows the user to remember it without too much trouble. Like all security, password management is a matter of subjective risk. It is a tradeoff between cost and functionality. Do not let this be an excuse for poor practice. As a word of advice – do not use the pass phrases presented above. Password Cracking and Guessing“Password guessing” and “password cracking” are commonly used interchangeably in the security industry. These expressions hold vastly dissimilar implications and extremely different connotations in reality. It is important that both security professionals and auditors understand the difference. Password guessing often creates large volumes of logs and network traffic and may lockout accounts. An IDS (Intrusion Detection System) may record and alert on this activity. Password guessing is generally far slower than password cracking. Password cracking can be achieved with far less evidence being generated in the logs and over the network. This is not to say that evidence of the encrypted or hashed password database being taken cannot be discovered, but it will vary based on the system attacked and the means used to capture the password database. Password cracking may also be hundreds of thousands to billions of times faster than password guessing. Password GuessingPassword guessing is the process of attempting to gain access to a system through the systematic guessing of passwords (and at times also usernames) in an attempt to gain a login to a target system. This is problematic in that it will generally create voluminous amounts of both network traffic when conducted remotely and system logs. This is in effect a “brute force” or dictionary style attempt to find the proverbial needle in the haystack. The attacker or auditor as the case may be will succeed only in the event that strong passwords are not used. This is one of the reasons that password complexity controls and checks have been built into most modern operating systems. Many applications, including those deployed on the Internet, do not use these types of controls. This is where tools such as Brutus come into play. The issue with this type of test is that it can result in account lockout. This is either an accidental or intentional DoS (denial of Services) possibility when a username is tested many thousands of times in a single minute. Even using “speed bump account locking”, the username will be tested so many times that it will lock. An attacker who sees a difference between valid account login attempts and thus can determine a valid username could do this in spite for not gaining access to a system. Password guessing is slow in comparison to cracking and it is unlikely that an attacker will ever guess a “good” password with complexity and the speed bump lockout method using this method. The attempt can also create large amounts of unusual network traffic. Not only can this impact network performance, but it should be different to a standard network traffic baseline. This is another reason why the creation of network baselines is important. Speed bump account locking is a control where the lockout times and number of failed attempts are linked to catch and stop password guessing attempts whilst allowing users to try validly where they are unsure of their credentials. Ideally the application inserts a delay, such as 15 seconds, between each attempt to login to the system. Alternatively, some systems increase the delay after consecutive failed logon attempt. This method could disable the account after five incorrect attempts and reset it in 30 seconds. On a sixth failed logon attempt, the system would lock the account for a minute. This would progressively increase over time up to a maximum lockout of five to ten minutes. The Speed Bump method makes brute-forcing passwords infeasible with the added benefit of preventing long-term DoS attacks. One method of seriously reducing the effectiveness of a password guessing attempt is to implement the speed bump method of account lockout. In Microsoft Windows, the tool LockoutStatus.exe can be used to obtain information regarding accounts in Active Directory that have been locked out. The ALockout.dll tool creates a record in a text file of any application that is causing accounts to be locked. This is both useful for troubleshooting and auditing systems. Administrators should be deploying some method to alert them of an ongoing attach and develop an incident plan to account for this occurrence. Password CrackingPassword cracking involves using a copy of the hashed or encrypted password database or individual representations. These may be obtained directly from the system being attacked or through “sniffing” network traffic. The process used to crack the passwords consists of: 1Formulating an estimate of what the password could be, 2Hashing or encrypting the speculated password using the same algorithm as the system being attacked, and 3Systematically comparing the resultant encrypted or hashed guess against the real hashed or encrypted value that was captured. Whenever the hash or encrypted guess is the same as the captured hash or encrypted password is found, the password has been “cracked” and the attacker will have a valid password to authenticate with. The biggest hurdle that the attacker needs to overcome is that of obtaining the hashed or encrypted passwords to be cracked. Individual passwords may be sniffed across a network, but it is more advantageous for the attacker to steal the entire password database (as this increases the chances of discovering a poorly constructed password and offers far more chances of success). A number of cracking tools (such as Cain & Able, John the Cracker and Rainbow Crack) are detailed in later chapters. Account lockout is not a concern with respect to password cracking. Read full chapter URL: https://www.sciencedirect.com/science/article/pii/B9781597492669000059 What are the two components of an asymmetric encryption system?Asymmetric encryption uses a mathematically related pair of keys for encryption and decryption: a public key and a private key. If the public key is used for encryption, then the related private key is used for decryption. If the private key is used for encryption, then the related public key is used for decryption.
What is the difference between symmetric and asymmetric encryption?Symmetric encryption uses a single key that needs to be shared among the people who need to receive the message while asymmetric encryption uses a pair of public key and a private key to encrypt and decrypt messages when communicating.
What is asymmetric algorithm common app?The most common application of Asymmetric Encryption is confidentiality. This is achieved by sending critical information by encrypting it with the receiver's public key and decrypting it with its own private key.
How is a message integrity check MIC different from a message authentication code MAC )? Quizlet?How is a Message Integrity Check (MIC) different from a Message Authentication Code (MAC)? A MIC only hashes the message, while a MAC incorporates a secret key. A MIC can be thought of as just a checksum or hash digest of a message, while a MAC uses a shared secret to generate the checksum.
|
