Swear jars and other ways to protect your content services platform

December, 2009. A social network app maker disclosed it experienced a breach. The worst part? This app creator had committed the cardinal sin of password storage – the company had stored user passwords in a completely unencrypted state inside their database.

Their plight went from bad to worse when it was revealed that they had been storing passwords for other third-party apps as well. Now the bad guys had user passwords for the app creator’s site, social media account passwords, and more. When you factor in that far too many end users select the same password for multiple services, this was truly a treasure trove of intelligence for the bad guys to use maliciously.

In the days that followed, hackers made the full list of credentials available. A text file, containing all the passwords, was soon available for free download on hacker forums across the internet and dark web. The cat was out of the bag. Now the bad guys could take every single one of the 14,344,391 passwords that were exposed in the breach and generate hashes for future dictionary attacks.

However, the Information Security community took note as well. Many InfoSec professionals used this as motivation to implement “password blacklisting.” When you implement blacklisting, users are forbidden from creating a password if it appears on the blacklist.

Does your platform need blacklisting?

Over the course of last year, I had the opportunity to meet with many OnBase end users and System Administrators. On occasion, they would ask why our content services platform does not implement password blacklisting.

My response: The OnBase password policies that are installed by default already prevent the use of a majority of the (weak) passwords that appear on most password blacklists, and I can prove it.

Hyland’s application security team has long known that length trumps complexity when it comes to choosing a strong password. It’s the reason our Medium Security Password Policy, which is installed and selected by default in every OnBase installation, requires that users select a password that is at least eight characters long.

It’s also why our High Security Password Policy, which is also available should administrators wish to use it, increases that requirement to 15 characters. In response to questions about password blacklists, I have always been able to say with confidence that OnBase can protect against the use of bad passwords.

However, whenever we were asked for metrics about how many bad, well-known passwords we can prevent from use, I didn’t have an answer … until now.


At this year’s annual meeting, Bill Priemer, our President and CEO, set this year’s theme for the company: Lead.

All day long, our leadership team spoke about the importance of maintaining our edge and continuing to innovate. These were not hollow words, as we designated the day after the annual meeting as a day of innovation, and we encouraged all R&D employees to put aside their work and create something.

I decided to test my team’s theory on passwords. I built an application that took all 14 million+ passwords in the hacked text file and tested if they would be allowed under the OnBase High Security Password Policy.

This security policy, which is available to Administrators in OnBase, requires that passwords:

  1. Contain a maximum of two repeated consecutive characters.
  2. Are a minimum length of 15 characters.

Additionally, the policy requires that there not be embedded usernames (passJOHNSMITHword, etc.), that the password be rotated frequently, and that the user is locked out after five failed logins or 60 days of no activity. For the purposes of this exercise, I focused on the character requirements above.

When we finally ran the code, I was happy with what I saw. Our hunch turned out to be accurate. Here are some of the things we learned:

  • 97.2 percent of the passwords in the text file did not meet the 15-character length requirement.
  • 33.49 percent of the passwords on the list could have been eliminated by the requirement that there be no more than two consecutive repeating characters.
  • When both rules are applied, 98.6 percent of the passwords in the file would not meet the requirements of the OnBase High Security Password Policy.

Length trumps complexity

Long passwords are strong passwords. The main reason for this is that long passwords are incredibly difficult for attackers to try and crack using computers. For instance, the password “password123” would take one month to crack using a computer. The password “Ican’tremembermypassword,” in contrast, would take 213 septillion years to crack.

The other added benefit of long passwords? They’re less likely to appear on text lists like the one exposed in the breach, since so few people create strong passwords. Thus, choosing a long password protects you from two types of attacks:

  1. A “dictionary” attack, where the attacker uses a “dictionary” of known passwords (like the text file from the breach) to generate hashes in an attempt to determine if your password matches one of them.
  2. A “brute-force” attack where an attacker attempts to guess EVERY possible password that could be used given the alphabet and special characters available to the end user.

The message is clear: Length trumps complexity. The best way to protect your system from the types of password attacks that hackers use is to add more characters to your password.

Clevelandthecityofchampions is a stronger password than Br0wnsO&16. And I’m not just saying that because it makes me feel better about being a Cleveland sports fan.

Down with the 1%!

Some of you “mathletes” out there may have deduced that 1.4 percent of 14 million+ is still hundreds of thousands of passwords from the list that would be allowed in OnBase. This is true! The length and repeating consecutive character requirements are not enough to stop 206,917 passwords from making the cut in OnBase.

The good news is that we at Hyland are strong proponents of defense in depth – multiple layers of defense. Here are some other layers of authentication defense within OnBase:

  • Other requirements in our high security password policy require users to rotate their passwords every 180 days.
  • Each password is salted and hashed 30,000 times using the secure PBKDF2 hash algorithm before being stored in the database. (Non-mathletes: It would take a hacker an exponential amount of human lifetimes to crack these password hashes in the event that he/she somehow accessed your OnBase database. That brute-force attack I mentioned earlier? Grab a Snickers, it’s going to be awhile.)
  • Support for multi-factor authentication, through the use of federation, so obtaining your password isn’t enough for a hacker to gain access. No code, RSA SecurID, or Yubikey? No access.
  • The ability to allow administrators to create custom password policies with complexity requirements and content quotas. For example, a policy could require that passwords be 17 characters long, including one capital letter, one number, and one special character.

So, as Warren on our security team would say, “Consider your threat model.”

What kind of attack are you trying to protect against?

Even if a user were to choose one of those 206,000+ passwords, there are still protections you put in place to defend against dictionary and brute force attacks.

I solemnly swear

Having shown that length trumps complexity, I set a New Year’s resolution for 2018. Starting at publication of this blog post, I’m no longer going to say “password.” I’m replacing it with “passphrase.” We know that long equals strong, and a phrase is longer than a word.

While there are fancy, long words like “alphabetization” or “logarithmically” I could use, it’s easier to remember a passphrase instead of a password. At least for me, a phrase like “StairwayToHeavenGuitarSolo” (perhaps the best of all time, I might add) is much easier to remember than the 15 character word “anthropologists.”

Either of these is better than “LetMe1n.” So take your pick, or let a website generate a secure passphrase for you, or better yet, use a password manager to handle it for you.

On my desk now sits my new “swear jar,” carefully placed to police my word choices in the New Year. Just like the Cleveland Browns 2017 wins column, it is currently empty. Each time I accidentally say “password” instead of “passphrase,” it will cost me 25 cents. At the end of the year, I’ll take the money and spend it on something nice.

I’d like to think that there will be enough money to treat my team to ice cream, or something else in that price range. However, I am human, so I may end up with enough money to buy a keg of beer at the end of the year, just in time for a Cleveland Browns Super Bowl party in 2019.

Dare to dream, my friends! Securely.

Josh Gatka has worked in Hyland’s Quality Assurance department for four years. In 2016, he assumed the role of Hyland’s Security Evangelist. His mission is to train and educate industry professionals on how to protect themselves and their organization from today’s advanced cyberthreats.
Josh Gatka

Josh Gatka

Josh Gatka has worked in Hyland’s Quality Assurance department for four years. In 2016, he assumed the role of Hyland’s Security Evangelist. His mission is to train and educate industry... read more about: Josh Gatka