Increasing Rock DB Password Requirements

There are three scenarios that could result in a compromised account.

1. An account is "brute forced" by a system rapidly trying passwords to log in to an account
2. The database holding account names and passwords is compromised/stolen
3. The account was re-using a password compromised on another website

Our efforts here today will help with scenarios 1 and 2 above. Scenario 3 is up to the user to practice good password hygiene.

Why Requirements Matter

As computer CPU power increases, faster graphics cards are created (which are re-used for cracking passwords), and as cloud services allow anyone to rent high-end super-computer levels of processing power by the minute... It becomes easier to crack passwords.

So what if they get into Ted Decker's account and see that he gave money to the church? Well... what if Ted is a group leader and they now have PII (Personal Identification Information) not only for Ted and his family, but for all his group members? Names, Addresses, Phone Numbers, Email Addresses, Family Member's Names/Info... Past addresses... maybe personal information like prayer requests, legal notes, medical notes, etc... What if they break into an ADMIN account? Now they have FULL ACCESS to THOUSANDS of attendees and their data. YIKES! Did you know this info sells on the dark web for people to open fraudulent credit cards, file fake tax returns, or even to socially engineer more advanced identity theft scenarios? Is your church liable for this? Legally... you could be sued. Could you prove you did your due-diligence to secure the data? Can your church handle the cost and public image hit / loss of trust you may incur? Do you have Cyber Insurance? ... ... ... You see how quickly this can spin out of control!

OK DEEP BREATH

Let's look at what we can do. Baby step one. Let's harden our passwords. By default, the password requirements for Rock are very simple. Users are required to have a password with the following requirements:

• 6 characters minimum
• 255 characters maximum

While this is great for keeping the average user out of another user's account, it is far too simple to actually be secure against even a lightly skilled attacker. Hackers use not only computers to try every combination of a password in rapid succession, but they also employ "dictionary attacks". Every word or phrase from a dictionary or past password breaches on other sites are loaded into a file and each of those words is used as a "single character" in this attempt. So "PuppyLove" is as easy to guess as "ab" and your plan to add numbers or characters to the end of your old password? Where FJ2h23%@kjL was breached somewhere in the past so you changed it to FJ2h23%@kjL2 for this site... that's also as easy for the computer guessing a 2 character password... like "a2". Every site should have a complex and unique password.

Obviously we can't control what passwords are known by others or reused by our users. But we can dictate what is acceptable on our end. So... what is acceptable?

What Is "Good" Enough?

In scenario 1 above, if a website doesn't limit the login attempts from a user to so many per time frame... say 5 failed attempts resulting in a one hour lockout... then the entirety of the world's computer power can be leveraged against that server to break into an account as fast as the computers can talk. However, Rock has global attributes called "Password Attempt Window" and "Max Invalid Password Attempts" that you can adjust as you see fit. They work by limiting a login to the "Max Attempts" value per "Window" and if it is exceeded, the account login is locked. So if you have the default of "Window" set to 1 (1 minute) and the "Max Attempts" to the default of 20, then 20 passwords can be tried per minute before the account is locked and requires an admin to unlock on their profile (Security tab - User Account List). This essentially kills any automated brute-forcing possible with sufficiently complex passwords in scenario 1. "Sufficiently complex you say?" Yes. If we do NOTHING here and only require 6 characters minimum... a user could in theory have a password that is a six digit number. How bad could that be if we have brute force rate limiting in place? Well... 999,999 (let's say 1,000,000 combinations) of a six digit number are possible.
- 1,000,000 / 19 tries per minute = 52,631 minutes to try them all without being locked out.
- 52,631 / 60 = 877.18333 hours
- 877.1833 / 24 = 36.55 days
... So in just over a month, you could feasibly hack a 6 digit password if they used only numbers even with the built-in rate limits. But with the requirement of 12 characters with an Uppercase/Lowercase/Number/Special Character... the possibilities increase from 999,999 to 26,963,771,415,920,784,510,976. Yeah... at 19/min, this brute force could take 513 TRILLION.... CENTURIES. Say it with me, "Resolved."

In scenario 2 above, Hive Systems is known for producing their annual "Password Table" (as of this writing, here is the latest 2022 data) where they take a look at the modern compute power of off-the-shelf hardware (graphics cards) and cloud resources (rented from companies like Amazon, Google, or Microsoft) to see how long it would take to crack passwords. To be clear, if they have your database... they likely don't need to decrypt passwords to get useful data out. Security here starts at the web server/SQL server. But let's assume they have only stolen the database tables of names/passwords and are working to break into them. They'd have to break the encryption. Rock uses a good encryption scheme known as bcrypt. Hive's table deals with scenario 2 (a stolen DB with unlimited attempts against it) to show how long modern hardware would take to crack various complexities and lengths of passwords.

For example, here is how long it takes to crack password previously stolen, using simple words, or reused between a compromised site and a non-compromised site:

Here is how long it would take to break the encryption on a Rock DB using bcrypt:

Some things to note:

• A 6 character password could be cracked instantly in 2022
• This was based on using (last gen) 8x A100 GPUs from Amazon AWS (Amazon EC2 p4d.24xlarge with 8 NVIDIA A100 SXM4 40 GB cards)
• The latest H100 GPUs are expected to be 2x faster than the A100 for hashrate operations

Let's Beef This Up

1) Rock uses a RegEx expression to determine the strength of a password. RegEx (Regular Expression) is a sequence of characters that specifies a match pattern in text. We can change what this expression is, so let's go to "Admin Tools - General Settings - Global Attributes"

2) Now locate the "Password Regular Expression" and the "Password Rules Friendly Description" fields:

The default values are:

• Password Regular Expression: \w{6,255}
• Password Rules Friendly Description: Invalid Password. Password must be at least 6 characters long and can only contain letters and/or numbers

3) We are going to change this to require at least 12 characters and contain each of the following: Uppercase, Lowercase, Number, Symbol/Special Character. Click the ROW you wish to modify and use:

• Password Regular Expression: ^(?=[\x21-\x7E]*[0-9])(?=[\x21-\x7E]*[A-Z])(?=[\x21-\x7E]*[a-z])(?=[\x21-\x7E]*[\x21-\x2F|\x3A-\x40|\x5B-\x60|\x7B-\x7E])[\x21-\x7E]{12,255}$
• Password Rules Friendly Description: Invalid Password. Password must be at least 12 characters long and contain each of the following: Uppercase, Lowercase, Number, Symbol/Special Character.

Impact of this Change

Users with existing passwords will NOT be asked to update nor will they be locked out. Database Logins with passwords already meeting the prior requirements will still be able to log in, but once they CHANGE their password or a new user signs up, they will be held to the new requirements.

Next Steps

I'm wanting to work on the following going forward, but haven't yet done so:

• Force a password change for all database accounts to ensure existing users have this requirement.
  There is a "IsPasswordChangeRequired" property on the "User Login" table that determines if they will be prompted to change their password at the next login.
• Set a deadline to change by and then remove all database logins not updated by that time
  We can use the "LastPasswordChangedDateTime" property on the "User Login" table to determine this... but I haven't worked out the SQL to do this globally and remove those not in compliance. Help here would be appreciated and I will update this recipe to include that info when/if I get it.
• Notify users with database logins via email that they need to update to modern requirements
  I'm told if we use a Workflow to change all database logins to "IsPasswordChangeRequired" we can then have it email them as well.

More Info

• Want to dive deeper into the world of passwords? Check out this GREAT article and learn about hashing, salting, cracking, and how the NIST recommended password strength can be cracked in a matter of hours:
  https://www.hivesystems.io/blog/are-your-passwords-in-the-green
• How to write/test RegEx expressions, complete with a pre-built library of various RegEx expressions to meet your needs:
  https://regexr.com
  So to test this password policy, copy/paste the regex expression from step 3 in the top bar, then start typing below it to see when your password matches. Super helpful!