Here at GoSimple our clients are all other businesses, and our product is SAAS. Designing a piece of software for other businesses rather than consumers comes with a unique set of requirements imposed at the will of your clients. One of the big differences between consumer oriented software, and business oriented software is a focus on password security policies to match what each companies’ IT department imposes.
Today we’ll be focusing on how we handle password policies, security, and storage.
Arbitrary Password Policies
Let’s say that your company
BigFoodManufacturer wants to ensure your employees don’t choose an easily guessable password, so IT implements a company wide arbitrary policy which says all password must have: an eight character minimum and contain upper case, lower case, numbers, and special characters
Now lets see how that policy applies to two passwords which are at opposite ends of the spectrum.
Passw0rd! – This password was chosen to get around an arbitrary policy
5fa83b7e1r39xfa8hmiz0 – This was randomly generated using lowercase alphanumeric
Password #1 meets all of the rules in the policy and passes with flying colors. Password #2 does not contain upper case, or special characters, and thus the policy fails this password.
Was password #1 actually more secure than password #2 by any metric? That would be a hard argument to make.
In fact, password #1 is likely to be cracked quite quickly.
password is one of the top passwords in all password lists an attacker is likely to try using a rule based dictionary attack. If the attacker knows that our policy requires: eight character minimum, upper case, lower case, numbers, and special characters they will then use rules like
l33t substitution, and
suffix/prefix special characters to augment their dictionary list for the attack.
It’s quite likely password #1 would fall to an attacker even in a rate limited online attack.
Password #2, while not allowed by our hypothetical policy, is only susceptible to a brute force attack (if a secure hashing algorithm is used).
Effective Password Policies
We have developed and open sourced a library called
- common dates
- common years
- spacial patterns (qwerty)
- repeating characters (okkkkkkkkk)
- repeating sets of characters (abababab)
- alphabetic sequences (hijklmnop)
- exact and fuzzy matching to word lists
We look at all parts of the password for any of these types of
matches. Each of the types of
match is assigned a specific scoring algorithm. Once we find every
match within a password, we run them through an algorithm to find the set of matches which will compose the entire password and provide the lowest score.
This score is a reasonably accurate
problem search space (entropy) that an attacker would have to work through before being able to compromise your password.
In some cases, a picture is worth a thousand words… here is what that analysis looks like in text form for the password:
How GoSimple Implements Effective Policies
Nbvcxz again helps us enforce minimum password strength. We allow each of our clients to specify a minimum time to crack in their settings. That minimum time to crack is converted to an
entropy value by
Nbvcxz and is used as a minimum. All passwords for users able to log into that client’s instance must meet that minimum. If a user is able to log into multiple clients (such as brokers), their password must exceed the highest minimum allowed by all clients they have access to.
When users are creating their passwords, we then run them through
Nbvcxz and show feedback to the user provided by the library. If their password doesn’t meet the minimum, the library offers suggestions for how to improve it. The suggestions change based on what type of password it detects. We also show a percentage of how good their password is compared to the minimum. Again, a picture is worth a thousand words:
We primarily suggest our users utilize passphrases rather than passwords, but because of how we validate password strength, as long as it meets the minimum, users can utilize any type of passwords they wish. This will hopefully ease user frustration. Being too limiting on password policies can lead to your users writing them down on a sticky note next to their monitor, or any other manner of insecure ways to remember their password. I think we can all agree that is not something we want users to have to do just to remember.
I ran across a quote that I thought fit this situation very well:
Security at the expense of usability comes at the expense of security.
— Avi Douglen
We utilize Postgres for our database, and available with it is the very useful extension
pgcrypto. Immediately after a user enters a password in any form in our application, it is run through a secure hash function:
bcrypt using 12 iterations of hashing. A secure hash function must be used to ensure even with the hash value, it takes a significant amount of time to compute the hash. Fast hash functions like
md5 are not suitable for password storage. From there, we compare that hash value to the current hash value stored in the database. We never store any password in plain text, so even GoSimple employees would not be able to see what a user’s password was.
Using proper security procedures when it comes to dealing with passwords is important because users often re-use passwords. The most “secure” password is only actually secure if it’s unknown by others. If a user utilizes the same password on many websites, then when any of those sites do not take proper precautions — such as store the password in plain text or utilize an insecure hashing function — that data can get leaked; meaning, that password is now not secure for any other site where it’s currently in use..