QuickBooks Desktop: Passwords, Encryption, Decryption... Part 2

by

In Part 1 of his two-part miniseries, Murph examined the fundamental design of QuickBooks files and the concepts used in safeguarding your data. He took a close look at the principles of encryption and decryption, and looked at how user accounts and their passwords are created and stored in QuickBooks.

According to the "QuickBooks help" reference, users are to use the QuickBooks Login window to open a password-protected company file. If the Login window only asks for a password, the administrator password should be entered.

If the Login window asks for both a user name and a password, users should enter their user name and password that was setup in the file. Help goes on to say that, "user names and passwords are created for company files, not for the QuickBooks application itself."

As we discussed last time, when a password is entered, it's hashed and compared to the verification value. If both values are equal, the user is logged in to the application and the Company file.

Let me say that there are number of SQL procedures stored in various "system tables" that are used to control and modify some aspects of login (like "LoginProc").

Stored procedures like this are why, if you have set a password, but have not created any other users, QuickBooks displays a login window that only provides for password entry, not User and Password entry.

Despite what you may think, even though QuickBooks uses internal access control methods (like highly-granular security based user roles in Enterprise and far more simplistic user rights in Pro and Premier), as far as Sybase SQL Anywhere is concerned, all users have equal access rights. 

Neither the database nor the database server "give a hoot" as to what data an individual should or should not be accessing. The QuickBooks application is the exclusive monitor of conformity with the internal access controls, based upon the permissions tables contained within the Company file.

It is here that I want to shift our attention to the loss of the Admin password and Intuit's mechanism for resetting the QuickBooks Admin password. 

Prior to QuickBooks 2011 R6 and QuickBooks 2010 R12, if you lost your Admin password, you had to contact QuickBooks Support and either download or garner their assistance with the QuickBooks Password Reset Tool.

Since those versions QuickBooks has contained a built in (internal) Password Reset tool, you no longer need to download the utility. Both the old downloaded tool and the internal tool require a "security token" that's generated by Intuit’s servers based upon the registered QuickBooks license number:

Back in 2010 and 2011, I wrote extensively about the various security risks posed with this technology. I said that anyone with a QuickBooks license essentially could get a token to open any "file" since there's no real link between files and licensing.

That really has never changed.

What makes this password reset technology possible via a simple "token" essentially is a "backdoor feature" built into every QuickBooks file. And that backdoor is our old friend the “ABMC_TSAFE” table. We learned about the importance of this table in Part 1 of this series.

The "token" downloaded from Intuit is a decryption key that in effect "wipes clean" this secure information, thus making all other security measures pointless. Unfortunately, the token, even though it's related to the license number is reliant upon a constant encryption key that's consistent in QuickBooks.

This actually poses a serious security risk, because anyone who ever takes the time (to actually perform the necessary compute cycles) to decrypt the encryption key essentially could reset QuickBooks files without Intuit tokens being issued. 

Getting back to the topic of the use of encryption and decryption within QuickBooks files, it's well known that a common problem in QuickBooks, especially since 2014, has been encryption and decryption errors. 

Corruptions of QuickBooks user accounts and their related master keys has been very disruptive. 

Problems of this nature can impact both non-Admin users as well as the Admin user account, but the user level of security is not the only data that is encrypted in QuickBooks. 

As mentioned in Part 1, other "sensitive data" such as customer credit card numbers, employee social security numbers, vendor tax ID numbers, employer identification numbers and bank account numbers are encrypted and subject to the decryption corruption issues:

As shown in this example excerpted from a QBWin.log file, a specific user’s encryption key has failed, an employee social security number is corrupted and several banking account identities also are corrupted:

To understand how such a diversity of sensitive data is impacted, we must understand how sensitive data is encrypted in QuickBooks.

Each sensitive data element is protected with an encryption that can only be unlocked by applying the appropriate "master key." Master keys are stored within several different tables in each QuickBooks file.

One master key is based upon the Admin user’s password, here's an example of the ABMC_ADMIN_MASTER_KEY table holding the "Admin" master keys:

Another master key is based upon each Non-Admin user's password. That data is stored in the ABMC_MASTER_KEY table:

This means that each user has a different key, which must be used to unlock each piece of sensitive data.

The actual keys necessary to decrypt each sensitive data element are stored in the table called ABMC_KEY_PERMISSIONS, which defines not only the keys but the specific information type for which the key is the access:

So, either the Admin user or any "other user" with appropriate access (established by the QB roles or permissions) to the area containing sensitive data attempts to user their key to open encrypted data, their key must either match or "pair-to-match" the actual keys necessary to decrypt the protected records:

Only when the required "pairing" and "matching" occurs does QuickBooks decrypt the data and allow access. When you think about it, this process is similar to a safety deposit box at the bank.

Before you rent the box, the bank holds two keys. They are like the Admin user in QuickBooks. They can open the box by using both keys to unlock both locks.

After you rent the box, the bank has one key and you have the other. You go to the bank, show your ID and they give you access to the safety deposit boxes.

Next, someone from the bank and brings in the bank key to you. Only when both keys have been used can you open the box.

You can’t open the box without the bank’s key, and the bank can’t open the box without your key.

The concepts of "payment card" industry standards for sensitive data encryption pretty much follow this pattern. And that makes sense when you consider that really the "payment card industry" is made up of "big banks" that have been doing it this way with safety deposit boxes for eons.

This system was designed to provide security, yet flexibility by allowing users (with permissions) to access their own master key in order to access a unique copy of the sensitive data key for each piece of sensitive data. It also means that any user password change only requires one record in the appropriate master key table to be updated

At the same time, this mechanism allows the Admin user to access all master keys, so that a users’ copies of sensitive data key can be replaced, changed or deleted, and/or to replace user passwords along with the related copies of encrypted master keys

Unfortunately, as most of us have learned, there are a number of bugs associated with this system of encryption/decryption, and from an internal or structural standpoint the redundant extra tables pose risks compromising security.

The safety mechanisms within QuickBooks make it possible for credit card numbers or other sensitive data to report as being corrupted under one QuickBooks user's account, while another QuickBooks user can access the very same credit card number without experiencing any indications of corruption:

The corruption lies not in the encrypted data, but in the user’s master key for accessing that data. So, even though they have permissions in QuickBooks to access the data, if there is a problem with their master key encryption or decryption, the data will appear garbled because it still is encrypted for them.

Fortunately, with the right tools, it's possible for data specialists to recover or replace corrupted encryption keys and even encrypted data keys and data. But that's a topic for another article.

Despite last year's enhancements to Password requirements for QuickBooks, and the recent changes that somewhat "roll back" some of those security changes, the fundamental design of the internal password and sensitive data security is consistent with the information we have outlined in this two-part series. 

Intuit still has not taken steps to associate individual QuickBooks files with individual QuickBooks license numbers. This means that even now, anyone who can get their hands on a Company file can open that Company file using the Admin Password Reset function within a licensed version of QuickBooks for which they have a license number, and the corresponding registration-related telephone number and zip code.

This flaw continues to pose a substantial risk to users of QuickBooks desktop, despite the sophistication of the encryption and decryption procedures associated with the QuickBooks Desktop application.