As the ongoing industry investigation continues, into what has widely become known as Solarigate, it’s worthwhile going back to some base concepts.
There’s an argument to be had that an organization’s privileged accounts should be considered information assets. There is a value associated with each of these assets as well as the risk associated with these assets being known and used by unauthorized parties. If they are used by unauthorized parties then there is also an impact associated with their unauthorized use. There are many methods you can use to categorize, determine the value of the assets and establish the risk and impact associated with unauthorized use.
Microsoft have recently published the final update on their Solarigate investigation and it makes for interesting reading. Two key points stand out as background to this week’s blog (taken word-for-word from the Microsoft report);
- The search terms used by the actor indicate the expected focus on attempting to find secrets, and
- The cybersecurity industry has long been aware that sophisticated and well-funded actors were theoretically capable of advanced techniques, patience, and operating below the radar, but this incident has proven that it isn’t just theoretical. For us, the attacks have reinforced two key learnings that we want to emphasize —embracing a Zero Trust mindset and protecting privileged credentials.
And lastly, they state that Protecting credentials is essential. The full article can be found at https://msrc-blog.microsoft.com/2021/02/18/microsoft-internal-solorigate-investigation-final-update/
Working on the above, it’s essential for an organization to treat their privileged credentials as information assets, protect them and ensure that the passwords used are strong. We’ll be covering Password Strength and Generator Policies next week, so this week we’ll cover off on Bad Passwords, Pwned Accounts and Passwords, and how to minimize the risk of both moving forward.
What are Bad Passwords?
Bad passwords are typically those that are based on words, a sequential series of numbers, or a basic combination of both. These passwords are susceptible to dictionary and brute force attacks and are easily cracked. Examples of bad passwords are;
- Password
- Password111
- 12345678
- 234567890
- Linkedin1
- Vikings
If users have the ability to use Bad Passwords then you’re making it that much easier for bad actors to execute an attack that will successfully hack a user’s account.
How do I know if I’ve been pwned?
Troy Hunt developed the HIBP (Have I Been Pwned) website to allow anyone to quickly assess if they’ve been put at risk as a result of their account having been compromised (pwned) due to a data breach. Users can look-up their email account to see if it’s been previously captured in a data breach here https://haveibeenpwned.com/
The site also provides API (Application Programming Interface) access so that passwords can be checked against the greater than 613 Million real world passwords previously exposed in data breaches. The premise is that if a password has been exposed then it’s unsuitable for ongoing use. Passwordstate provides integration with the HIBP repository via the published API.
How to prevent the use of Bad Passwords?
Passwordstate offers a couple of options to limit the use of Bad Passwords. The first is using the built-in customizable Bad Password Database. This is based on a dictionary style list of common words and sequential numbers. Please note that there are words included in the list that some people may find offensive. They’re included as they’ve proven to be used in or as part of the most common passwords. If you do not want these included in the database you can delete them.
The Bad Passwords configuration is located under Administration->Bad Passwords->Bad Passwords Database as shown below;
This database can be built on within your organization by adding specifics words that you want to prohibit the use of, for example the name of your company. To add a new Bad Password simply click on Add at the bottom of the Bad Passwords Grid and enter the word you wish to add to the database. The example below shows adding the password “clickstudios” to the database,
The second option is to select the Have I Been Pwned API from Administration->Bad Passwords->Bad Passwords Database.
This will reference the HIBP database via the published API from the Add and Edit Password screens. Please note that with Version 8 of Passwordstate you can only select the Custom Database or the Have I Been Pwned API. With V9 of Passwordstate you can elect to use both at the same time.
By using the Bad Passwords feature you are removing one avenue of weakness by ensuring that your user’s passwords are not easily cracked and aren’t the same as those exposed in previous breaches.
As always, we welcome your feedback via support@clickstudios.com.au.