Since 1999

 

8 minutes estimated reading time.

Account Protection Policies to Cover Business Assets

The compromise of a staff user account credentials is a critical step in the kill chain of many data breaches. This compromise may be accomplished in many ways, including a staff user falling victim to a:

  • credential stuffing attack when email and passwords in outside breaches are used to authenticate with work systems (because people reuse the same passwords frequently)
  • targeted spear-phishing campaign to intercept valid credentials via a spoofed login form
  • business e-mail compromise via a convincingly forged e-mail supposedly from a supervisor or the CEO

There are a few levels of staff credentials to address, those with access to:

  1. legitimate business e-mail
  2. the administrative portal/customer service via a web interface
  3. development resources and testing environments
  4. production resources like cloud providers and the domain name configuration

Traditional information security practice calls for the separation of duties between developers and those with production access. However, often only the most sophisticated, established organizations have the dedicated resources to do that. For everyone else, the developers usually have access to all these resources.

Today’s Threat Environment

Credential theft is a huge risk. For example, Uber failed to require 2FA for its GitHub user accounts and a compromise of a staff member’s GitHub credential contributed to its 2016 breach that compromised information on 57 million passengers and drivers (theregister.co.uk).

For a broader picture of where this currently fits into the threat landscape, the 2019 Verizon Data Breach Investigations Report (enterprise.verizon.com) found that:

  • 32% of breaches involved phishing
  • 29% of breaches involved the use of stolen credentials
  • 33% of breaches included social engineering

Importantly, 96% of breaches did not involve the use of physical access. Critical resources are attacker over the Internet. Specifically

  1. there are no borders or firewall to keep unauthorized people out;
  2. your staffs' e-mail address (which is not secret) and password is the security linchpin keeping anyone in the world from your company data; and
  3. your staff are composed of regular people, who will:
    • Pick common weak passwords that are easily cracked
    • Reuse their favorite passwords for many different websites, not just your company
  4. Despite years of advice never to write passwords down, there is frequently the need to share passwords with employees and contractors to conduct business and manage online resources

Examples of Most Critical Services to Protect

The most critical services to protect are:

  • Business E-mail
  • Domain Name Registrar
    • protects the crown jewels of the organization
    • for startups, can often be managed by the founders' personal account with a weak password
  • Cloud Service Accounts where your virtual servers and databases are hosted
    • Amazon AWS, Azure, Google Cloud Services, etc
  • Backups
  • Log Aggregation and Error Tracking Services
    • Your log and error tracking services receives log data from your applications that can contain very sensitive PII such as session cookies and form data when an error happens
    • For more on this aspect, see my recent article on Are You Accidentally Storing Private Data in Plain Text?
  • Source Code Repository
  • Project Management Tools
    • services like GitHub Issues, Jira, or Pivotal Tracker
    • have sensitive business data, possibly some customer personal information (such as customer issues that have been raised to the level of having a developer look at them)

How to Protect Your Resources

When Passwords Must be Shared, Use a Password Manager

For decades, the advice on passwords was to never write them down and never share them with anyone. However, the modern company on the Internet has dozens or hundreds of service providers each with their own password. This password then must be shared within the organization to those employees and contractors who need access to do their job, like update the domain registration.

When passwords must be shared, don’t create a document on the shared drive with the list of accounts and definately don’t e-mail the credentials. Instead use a password manager with sharing capabilities, like LastPass or 1Password.

For a purely open source solution, you can consider KeePass Multi-User.

With a good password manager in place, you can use unique-per-site, truly non-rememberable random passwords like: ‘iUSm9PorFiWUXvTvDjfaA8EJNE1Zr15UiEwe’. Then your people just have to practice maintaining one really good passpharse to protect their copy of the password vault.

Train Staff to Choose Passphrases Instead of Passwords

Two big holdups from the past that limit the security of passwords are:

  1. people focus on the “word” part and forget that punctuation, including spaces provide great entropy
  2. too many systems arbitrarily limit password length to crazy short lengths less than 20 characters

The key to password security, is to have a password with sufficient entropy to be hard to guess and to not be among the top million or so short passwords that people commonly use. Entropy can be added by crazy gobblygook or even better by increased length. The best way to remember long passwords of 32+ characters is to make them a phrase.

Instead of trying to remember “theb3st1nBr33d!”, one can have much better results with “The truly best in Breed construction techniques applied for our customers!”

Adding additional punctuation helps even further.

The SANS Security Awareness newsletter has good recommendations on Passphrases (sans.org).

Require Two Factor Authentication (2FA)

In addition to training your users to choose passphrases, it is imperative to implement two factor authentication. With 2FA, you greatly reduce the opportunity for unauthorized third parties to login to your business resources using the credentials of one of staff.

Yubikey Security Tokens at Rietta Image: Yubikey FIDO U2F security tokens used by the Rietta team. Google’s data shows that these stop 100% of automated, bulk, and targeted phishing attacks (security.googleblog.com).

The most common forms of 2FA available on the open Internet, in order from most secure to least secure, are:

  1. USB Fido U2F Security Keys, such as the YubiKey
  2. One time code generated by a time-based one-time password smartphone app like Authy and Google Authenticator.
  3. One time code e-mailed to a user
  4. One time code text messaged to a cell phone over SMS

SMS-based 2FA should only be used as a very last result because the phone system is not secure. It is insecure against targeted attacks where the adversary may have access to the phone system (like nation states) or can pretext a phone company into routing text messages to them.

Two factor authentication does not protect you from all forms of phishing, especially the forms where your user enters the 2FA code along with the password to login. The attacker can simply relay the second factor and gain access. The USB-based tokens are the best and include NFC support for some smartphones. Google uses Yubikeys internally so its worth a consideration.

Implement NIST standards Inside Your Application

If your company’s web applications implemented password security more than two years ago or copied from how some other big company was doing things, then you’re probably doing it wrong!

The U.S. National Institutes of Standards and Technology released the NIST 800–63b Federal Standard for password verifiers (nist.gov) in June 2017. It challenges many of the recommendations you might have come across for password security.

For example making users change their password every 90 days is specifically not recommended. One thing that is strongly recommended is to use multi-factor authentication, the most common form of which is Two Factor Authentication (2FA).

Additionally, it recommends disallowing passwords that are known-to-be-compromised in public data breaches. One way to do so is by validating leaked passwords with k-Anonymity (blog.cloudflare.com), which does not reveal your users' passwords to any remote server.

Be sure that your business analyst and developers are familiar with the NIST 800-63b and incorporate the guidance into your own system.

Conclusion

Many security breaches start with the compromise of just one user account. That is why it is so important to make sure that user accounts – especially accounts with elevated privileges — are strongly protected. The best protection is to train your staff to choose really long and strong passhprases instead of passwords and require the use of 2FA. These are the best tools available to enhance the security of your credentials. Finally, for those times you must share a password for a third party service, do so in as secure a way as possible with a purpose built password manager rather than adhoc shared documents and insecure e-mailed copies.

If anyone in your organization is concerned about staff password security, please show them this article. If I can be of any assistance, I’m happy to do so. I do not have any direct financial stake in any of the companies mentioned here except incidental holdings through mutual funds. I am a happy user who uses YubiKey and other products mentioned here extensively for my company and for our clients.