In reality, the weakest link in password security is the user. From weak passwords, to passwords that can be inferred (think birthday, spouse or children’s names), to sticky notes left on screens, to susceptibility to social engineering – in many cases, it is easier for hackers to obtain system passwords directly from the user rather than some type of hack.

Unfortunately, no matter what you do from a system perspective you need to continually educate and remind your users of their responsibilities and to be on the lookout for the various means that could be used to obtain system passwords.

Social Engineering is a common tactic because it is easy to exploit since it is human nature to trust. Common types of social engineering include:

• Phishing attempts where some type of communications appears to come from a legitimate source such as a business or institution. Phishing attempts many times ask for help, ask you to verify information or notify you that you are a winner of some sort an get you to divulge personal information that can be used by the hacker.
• Response to a question that you never asked. In this scenario what appears to be a legitimate business that you use responds to a question you did not ask. When you respond your authentication is subsequently used by the scammer.
• Free or too good to be true offers. Free downloads may be infected with malicious software that can cause more harm or your payments never result in a delivered product.
• Email from a friend whose account has been hacked. A link or download in this email can infect your machine with malware potentially giving access to everything on it to the hacker.
• Hackers just ask! In a very simplistic approach hackers will merely call a user and tell her some story for which they need a password and/or personal information. Again, trusting the caller, the user gives the hacker all the information they need.

There are other common techniques including:

• Shoulder Surfing – looking over a user’s shoulder or reading sticky notes attached to the user’s monitor
• Inference – Using personal information such as family names or birth dates to guess passwords

The user is usually the weakest link in any system security. Train your users to spot attacks and respond appropriately.

Securing Server Access

August 15th, 2016

With the wide availability of access to servers for startups, it can be easy to skip some very important steps in planning for and implementing server security.

In an earlier post, I talked about password strength. However, even with the strongest password there is always the chance that it could be guessed on the first attempt. Therefore, it is imperative that admin access to servers be secured more thoroughly. Usually, this is done through the use of Multi-factor authentication (MFA). Wikipedia, defines Multi-factor authentication as:
Multi-factor authentication (MFA) is a method of computer access control in which a user is granted access only after successfully presenting several separate pieces of evidence to an authentication mechanism – typically at least two of the following categories: knowledge (something they know), possession (something they have), and inherence (something they are).

For Cloud computing, MFA usually boils down to something you know and something you have.

Many Cloud providers include the use of public key SSH authentication as part of the server setup. This involves using a public and private key. However, using this basic method is only as secure as the device on which the private key is stored. Therefore to implement MFA you need to generate the SSH keys with a strong passphrase. In this case, you can only access the server with something you have (the private key usually stored on a device) and something you know – a strong passphrase). The key here is to always generate the SSH keys with a passphrase.

Another method gaining acceptance is to use something similar to Google Authenticator (Note: I will use Google Authenticator as a generic term for an application that uses a Time-based One-time Password (TOTP)). Google Authenticator makes available a 6- to 8- digit password that is essentially a shared secret between the user and the server that changes every 30 seconds or so.

The user logs in using a strong password and is then asked for the Google Authenticator shared secret. The user can only access the server with something they have (the Authenticator generated shared secret) and something they know – the strong password. Again, since the device on which Google Authenticator runs (usually a smart phone) can be lost, it is essential that a strong password is also used.

Finally, as an added security measure for admin server access in the cloud it is a very good idea to restrict SSH access (port 22) to just the ip range of your administrators.

The bottom line is that you need to secure server access with more than just a strong password. MFA and ip restricted access go a long way in achieving that.

Password Security

June 8th, 2016

Password Strength and Your Password Security Policy

Much has been written about the strength of passwords and what your organization’s password security policy should be. Instead of a one-size-fits-all solution, I think each individual situation needs to be looked at in context AND looked at from the perspective of the user who, in the end, may be the weakest link in the security chain.

To get started, we need to understand password strength. Wikipedia defines Password strength as a measure of the effectiveness of a password to withstand guessing or brute-force-attacks. It estimates the number of guesses required, on average, to identify the password of a user. Password strength then is a function of length, complexity and unpredictability.

Password strength is usually measured in bits of entropy. Entropy is the base-2 logarithm number of guesses needed to find, with certainty, a password. As an example, a password with 10 bits of entropy would require 210 attempts to exhaust all possibilities using a brute force attack. Adding one bit of entropy doubles the number of guesses required. However, on average, it only takes half of the possible guesses to obtain the password.

A mathematical formula can be used to calculate the bits of entropy, per symbol, based on the symbol set used.

For example, here is a chart from: http://study.ncmco.us/password-entropy-chart, licensed under https://creativecommons.org/licenses/by/3.0/ and shows the bits of entropy, per symbol, of varying symbol sets.

Using this chart, we can see that a 10 symbol length password using Case insensitive Latin alphabet will have 47 bits of entropy (4.7 x 10).

Size Matters – When I look at this, the point I take away is that the length of a password is more important than the character set. In fact, the draft specification for Special Publication 800-63-3: Digital Authentication Guidelines recommends a minimum of 8 characters and should allow a maximum of 64. A common approach is to use passphrases, allowing all common punctuation and any language to improve usability and increase complexity. Georgia Tech researchers, in a 2010 report, recommended use of a 12-character password, which in using Case insensitive Latin alphabet would give 56 bits of entropy.

Rate of Guessing Matters More – However, the rate at which an attacker can submit guessed passwords to the system is probably the most important factor in determining system security. In an offline environment, computer clusters such as a specialized five-server system using virtualization software and 25 AMD Radeon graphics cards can achieve 350 billion guesses per second. . Yet, that is not the model you will normally see in a web environment. In a web or server environment you could see 1, 10, 100 or maybe 1000 guesses a second. At 1000 guesses per second, the guaranteed time of password crack for 38 bits of entropy would be 8.7 years or an average time of crack of 4.4 years as can be seen in this chart.

This corresponds to an 8 character lowercase password. Increasing the minimum length to 10 characters would increase the guaranteed time to crack to 8.7 millennia (of course, on the other hand, a lucky guess could result in the correct password on the first try).

There are different techniques used in off-line password cracking of encrypted passwords. I haven’t covered those here, but I will cover some additional security measures system administrators should take to improve security to prevent access to the set of encrypted passwords in a later post.

When attempting to secure systems from brute-force attacks, the take-aways are that longer passwords and rate limited systems are the methods that significantly decrease password cracking vulnerability. Even more secure are the systems that impose some sort of time-out after a given number of failed attempts. If you can implement these, you’ve taken great first steps to secure against brute-force attacks.