Although it's one of the oldest, the combination of username and password remains the industry standard mechanism for protecting access to even our most critical systems; OnBase is no exception. Even as the use of other factors (biometrics, tokens, etc.) increase in popularity, the classic username and password still stands as a model of ease of use, reliability, and security - when implemented properly.
When a user's password is created in OnBase, it's appended to a salt value. This salt value is a random chunk of data which is unique to each user. Once the salt value has been appended to the plaintext password, the entire value is put through a hashing algorithm. Hashing algorithms are cryptographic functions which are built to be mathematically impossible to reverse. When a value is pushed through a hashing algorithm, the resulting hash value is stored in the OnBase database. Overall, the process looks something like this:
The long string of green characters at the end is the hash value, the value which is stored in the OnBase database in lieu of the plaintext password. This is done so that no one will be able to read (and therefore use) the user's actual password in the event that the database is stolen, accessed by an unauthorized party, or even just by an administrator. Because OnBase passwords are stored as hash values rather than encrypted values, OnBase passwords cannot be "cracked," as it is mathematically impossible to reverse the function. For attackers to obtain the plaintext value of OnBase passwords, other attack methodologies must be employed.
The most common method of computing plaintext values from stolen hash values is through the use of hash tables. Hash tables are spreadsheets, sometimes as large as several terabytes, which contain hundreds of thousands of plaintext values which are commonly used as passwords and their corresponding hash value. With this tool, an attacker need only search his table for a hash value which matches the value from the stolen database, and he will see the corresponding plaintext value. This is why salting is so crucial. If an attacker were to find a hash value in his hash table which matched the stolen hash value from an OnBase database, it would be of no use to him. This is because the corresponding plaintext value would be both the password AND the salt value. If the attacker attempted to enter this into a password field, the application would again append the salt value before hashing, and the resulting hash value would not match the stored hash value. Therefore access would not be granted. Here's what it might look like for this scenario to be played out:
Because of how effective salting is against hash table-based attacks, the only reliable method of attack which remains is brute forcing. Using brute forcing, attackers attempt to log in to an application using every possible character permutation until one works. A strict account lockout policy will prevent this attack from being carried out live on the application. However, it will not prevent this attack from being carried out offline. In an offline brute force attack, the attacker guesses at a password, guesses at where to append the salt value (beginning, end, somewhere in the middle), and computes the hash value looking for a match. If you think this sounds time-consuming, you're absolutely correct. However, modern day password-breaking software and hardware allows attackers to make millions of guesses per second fairly cheaply. This is why strong passwords are so important.
So what makes a strong password? There are two main schools of thought on this: length and complexity. In OnBase at least, length wins every time - hands down. Complex passwords (mixed case, numbers, symbols, etc.) are difficult for humans to remember, and can make logging in tedious. However, they are very easy for computers to guess! On the other hand, if constructed properly, long passwords are very easy for humans to remember, but difficult for machines to guess. Why? As I said above, brute forcing is when a computer guesses every possible permutation until it finds a match. This means it will literally try "a," then "b," then "c" all the way through, until it gets to "z." Then it will try "aa," "ab," on and on for billions of guesses until it hits a match. So what we want to do is make a password that keeps the computer guessing for as long as possible (or at least until it's time to change our passwords!).
If I wanted to try to guess a 1-character password, I know that there are 26 different possibilities. That won't take very long for a computer to get through. If I want to guess a 2-character password, that increases the possibilities to 676, or 26². As you can see, just by adding a second character, we've significantly increased the number of guesses the computer will have to make.
What if instead of adding a second character, I simply added complexity to the single character password? So now instead of only a-z, the password could also contain a number. This brings the number of possibilities from 26 up to 36. Let's add symbols. There are 32 commonly-accessible symbols on the US keyboard. This brings our permutation possibilities up to 68. Let's add case-sensitivity. By adding capital letters as possibilities, we bring in 26 more possibilities, bringing our total to 94. We've now added 3 levels of possible complexity to our 1-character password, and we're still nowhere near the possibilities made available by our all-lower case 2-character password.
Let's look at two common password policies. The first is as follows: minimum 8 characters, at least 1 capital character, at least 1 lower case character, at least 1 number, at least 1 symbol. The possible number of permutations for a minimally-compliant password to this policy is 6,095,689,385,410,816 or 948 or nearly 6.1 quadrillion possible permutations. Seems like a lot.
The second password policy is as follows: minimum 15 characters. The possible number of permutations for a minimally compliant password to this policy is 1,677,259,342,285,725,925,376 or 2615 or just over 1.6 sextillion possible permutations. That's quite a lot more. In fact, it's 1.677253 sextillion more than the first policy.
So we've established that longer passwords are more difficult for computers to guess than complex ones. But what about us? Aren't shorter passwords easier to remember? Yes and no. Using our two policies above, let's look at what a few compliant passwords might look like:
Policy 1: onBase15! | p4ssw.rD | Logm3in() | oP{nse5ame
Policy 2: onbaseisawesome | iwanttologinnow | timetogettowork | letmeintoonbase
Which set of passwords do you think you'd find easier to remember? By utilizing passphrases, we create passwords that are easy to remember and easy to type, but extremely hard for computers to guess. To require 15-character passwords in your OnBase environment, simply turn on the "High Security" password policy in Config, or create your own with a 15-character minimum. More importantly, educate your users! Feel free to provide them with any of the material from this post, or our favorite method, link them to this webcomic which explains the concept in a hilarious, memorable way.
Thanks for reading this month's security blog. If you have any questions, feel free to post them in the Q&A section, and we'll be happy to assist. Thank you!
