Network Security: Passwords and Human Error

A past IBM cyber security intelligence index report concluded that 95% of security breaches are caused by human error. Human error definitely includes password choices by users. It also includes password requirements and password storage by systems administrators. Passwords are a large part of network security. Hackers can use a technique called "password guessing" in which they manually enter passwords at a log-in prompt to gain access to an account when they have a valid user name. There are tools to automate this guessing process, known as an online attack, including Medusa, Ncrack, and Hydra.

These tools were built to help companies secure their networks as security specialists can test hosts and networking devices for poor passwords. These tools are used to audit devices as well. Online attacks can also be used to check that your firewalls, IDSs, and IPSs detect when a server gets bombarded with unsuccessful log-in attempts and that accounts lock in a short period when this happens. Password guessing through manual or automated means is obviously very noisy, so hackers need a better way to do it. Passwords should never be stored in plain text in databases. Storing passwords in plain text allows them to be used immediately after they're stolen. Passwords should be stored in a strong hash format since hashing is a one-way function. 

In many of the data breaches of recent years, stolen password databases contain passwords that were either stored in plain text or hashed with weak algorithms like MD5 or SHA-1. The current standards of hashing include SHA-256 and SHA-512, both forms of SHA-2.

On Linux systems, password hashes are stored in the etc/shadow file. Most Linux distros use SHA-512 with something called "SALT".

On Windows systems, password hashes are stored in the SAM file located at C:windows\system32\config\SAM. Some Microsoft documentation expands SAM to Security Account Manager while other Microsoft documentation expands SAM to Security Accounts Manager. On Windows domain controllers running Active Directory, password hashes are stored in the NTDS.dit file located at C:windows\NTDS\NTDS.dit. The Windows NTLM, Lan Manager Protocol Suite, actually uses MD4 without SALT for storing Windows hashes.

Websites that we log into store passwords in a backend database likely using the MySQL relational database management system. If a hacker enters the stolen hash into the password field, the hash itself would be hashed, so the attacker won't do that. What happens when a database containing hashed passwords are stolen? The hackers have three attack options after they steal the hashed password database. The first is called a "brute force attack" which uses a tool that generates a file containing all possibilities of letters, numbers, and symbols given a minimum and maximum length. The second is a dictionary attack which uses common words and their variations instead of trying all possibilities like a brute force attack does. The third is a rainbow table attack which requires more processing but less storage than a dictionary attack.

Introduction to Cyber Security - Attacking passwords

The obvious ways that attackers can find or steal passwords, such as looking over your shoulder when you’re using an ATM or credit card machine or trying obvious passwords such as ‘abc123’ and ‘password’, are familiar to us.

Almost as long as there have been passwords there have been people attempting to break passwords. One of the oldest methods of automatically breaking into computers is to perform a dictionary attack. As its name suggests, a computer will attempt to log into an account by working its way through one or more dictionaries – each entry in the dictionary is one possible password and if it doesn’t work, the computer moves on to the next.



Dictionaries need not be the familiar A–Z references that we are familiar with: a concerted dictionary attack will also include more specialised reference works such as atlases, lists of astronomical bodies and characters from literature, as well as lists of the most commonly used passwords and lists of stolen passwords that are in widespread circulation.

Dictionary attacks can also be performed on the hashed values of words; they may take a little longer, but they will work. Some system administrators might set up dictionary attacks on their own users’ passwords to try to identify weak passwords that should be changed.

An alternative, simple attack is a brute force attack where a computer will methodically work through all possible passwords (so beginning with ‘A’, then ‘AA’, ‘AB’ and so on …) trying each in turn until it stumbles upon an actual password.

Dictionary and brute force attacks can be foiled by having computers watch for unsuccessful attempts to log in to accounts. Almost all computer systems restrict the number of unsuccessful log-ins after which the account is locked and can only be accessed after the intervention of an administrator.

Another type of attack on passwords is based on the incorrect configuration of the hashing technique used to store the passwords on the server, which is discussed in the next step.

 

Salt to protect
The security of stored passwords can be increased by a process known as salting – in which a random value (called the salt) is added to the plaintext password before the hashing process.

This greatly increases the number of possible hash values for the password and means that even if two people choose identical passwords, their hashed passwords have completely different values.

The hashed password and the relevant salt are stored by the password server. When the user attempts to log in to the computer, their password and the salt are added together, hashed and compared to the stored, hashed value.

Salting is only effective if:

• truly random salts are used for each password (some systems have either used a single salt for all passwords, or have only changed the salt when the computer is restarted)
• the salt is long enough that, when added to a password, it will create enough possible hashed values that an attacker cannot generate a table containing all possible hashes from a salted dictionary. For instance, the passwords used by UNIX in the early 1970s were restricted to eight characters and used a 12-bit salt. When released this was secure enough – it was not feasible to generate the hashes for every possible password each of which had been salted with all 4096 possible salts. However, the rapid advance in computer power and storage capacity meant that longer salts are required. A typical piece of advice is that the salt should be the same length as the output of the hashing function – so if your hashing function generates 256-bit hashes, a 256-bit salt should be used.

 

Case study: LinkedIn
In the middle of 2012, the hugely successful social networking site LinkedIn was attacked by Russian hackers. The passwords to some 6.5 million accounts were stolen, but although they were stored as hashed values, the passwords had not been salted.

The hashing had been performed using the relatively old SHA-1 hashing algorithm which can be performed at very high speed (a desktop computer can calculate several tens of millions of SHA-1 hashes per second).

It was therefore not surprising that within a day, decrypted passwords were being published on the internet and LinkedIn was forced to ask all users to change their passwords.

Preventing the attacks described above depends on the online service taking steps to encrypt the transmission and storage of passwords. As users, we can help in this protection by choosing passwords that are difficult to attack.