We offer a bug bounty to anyone who can perform a man-in-the-middle attack against our online accounting system when given the SSL private key and the user's email address and password.
Sounds easy, right? For most online systems, releasing either the SSL private key or user email and password would blow a huge security hole in the system, but our online accounting software has an extra layer of protection.
Most web apps and other online systems send the user's email address and password over an encrypted TLS/SSL connection, then perform authentication on the server. But this model is susceptible to three types of threats:
To counter these threats many systems will add features such as rate-limiting login attempts, maintaining IP whitelists, frequent updates to underlying software modules, disallowing dictionary passwords, etc. Such features improve security, but only to a limited extent. We want to do better.
The goal of our security model is simple: An attacker who gains complete control over our online servers should be unable to access any user data. Here's how it works:
The user logs in by supplying a user ID and password, but instead of an email address the 'user ID' field is actually comprised of three parts:
The user's first name
A random 'client-side salt' generated when the account was created
A code which uniquely identifies the user account to the server - i.e. the 'real user ID'
Here's an example of the login fields for Solar Accounts:
The client stores this multi-part user ID on its hard drive, so the user normally only has to type the password to log in. Note that the first name is included in the user ID field mainly for convenience - it allows the user to easily choose an ID from the drop list.
When the user clicks 'Log In', the client creates a strong password by concatenating the user's password, first name and client-side salt. It then authenticates the user by passing the real user ID, the strong password and a server-side salt into the Secure Remote Password algorithm. Once authenticated, the client encrypts all user data with a cryptographic key which is derived from the strong password and another server-side salt. We use Scrypt as the key derivation function.
This model effectively protects against the three threats listed above because an attacker needs both the user's password and the client-side salt in order to be authenticated or decrypt the server data, and a brute-force approach is not feasible.
The key used to encrypt user data is itself encrypted with a customer-support public key and stored on the server. If the user forgets the password our support staff will copy this encrypted key from the server to an offline device which contains the customer-support private key - this device decrypts the user's key and generates a password reset code.
For operational reasons the server does have the ability to decrypt emails sent using Solar Accounts. However, this is only done in memory while the email is being sent - all user data is encrypted in the database which greatly limits the scope of a potential breach of email data.
Compared to the standard model, this extra security has two usability drawbacks:
The User ID field cannot be memorised, so when switching to a new computer the user must copy it from the login window on the old computer (or write it down before switching).
Resetting a password requires physical access to an offline device, so if the user forgets their password or loses the User ID there may be a relatively long delay before the user receives the password reset code.
Is this a big problem for users? We think that most users will be affected by these issues only rarely, and that for sensitive sites this is a cost worth paying for better security.
Many other organisations with sensitive data also require complex user ID when logging in. Banks will often require an account number or bank-issued PIN code. The UK tax authorities issue a User ID with 12 random digits. In these cases users seem to accept the need for login credentials that cannot be memorised.
Two-Factor Authentication would protect against Threats 1 and 2 described above, but not against Threat 3. Most 2FA implementations store the unique random seed associated with the token on the server, so an attacker who gains access to the server may be able to find the random seed and then decrypt user data using a list of common passwords. In addition, requiring a second factor for all users would make it more difficult for users to sign up for an account.
However, Two-Factor Authentication does protect against other types of threats, so we may offer it as an option for users who want even more security.
In order to test the extra security layer described above you must first first bypass the standard SSL encryption used by the Solar Accounts client. To trick it into communicating with your man-in-the-middle proxy do the following:
Download and install the alpha version of Solar Accounts online
Set the proxy for your operating system to point to your MITM server
Configure your MITM server to replace the certificate provided by alpha.solaraccounts.co.uk. Here's a java keystore file which can be used for this purpose (the keystore password is 'password').
Replace the client trusted certificate file used by the Solar Accounts client with a version that accepts the certificate generated by MITM server. This file is named 'cacerts' and is located in the jre/lib/security folder of the client installation directory. Here's a cacerts file which will accept the certificates provided by the sample keystore file in step 3.
If you find a security bug in Solar Accounts, please report it as described in our bug bounty page.
Note that our bug bounty program isn't restricted to the extra security layer described above - please report any significant security flaws which affect the integrity or privacy of user data. Here are a few situations which would be susceptible to such flaws:
When a user creates a new account
When a user logs in
When a user requests a password reset
When a user shares a business with another user
When the client automatically downloads and installs a new version of itself
