Grover, your notes:
The answer is that our mitigation plans depend on the systems he is using and intends to share with us. If he's using something like Xero or SalesForce, then we follow industry best practises, which include his businesses ability to shut us off/out at any time if he felt that a breach had occurred.
We also don't store usernames or passwords (those used during setting up the integration), those systems (Xero/SF) assign us temporary credentials that only our system can use, so if those were leaked (which is highly unlikely), we'd still not be sharing usernames or passwords and no other application (or login page) would be able to use the temporary credentials.
That help at all?
This is what Sales uses now:
Integrations and Security
We store various pieces of information for client integrations. Two major styles exist for getting access to a third party integration: OAuth and credential-based.
Most integrations to third party services use OAuth. With OAuth, Results.com directs the user to the third-party service (for example, Google) where the third party prompts the user for their credentials. Once the third party validates the user credentials, the third party presents the user with a screen prompting them to authorize Results.com for access to read relevant data. If the user grants access, the third party service returns a set of tokens giving Results.com the ability to read their data. With ©©OAuth, the user always remains in control of the authorization and can revoke Results.com from accessing their data at any time.
Directly Supplied Credentials
There are some integrations where OAuth is not available and we ask the user for their credentials directly. For example, when connecting to a SQL database, we need to know the database's IP address or hostname, username, and password. For these integrations, we recommend setting up specific accounts for Results.com to provide the minimum necessary level of access, which is read-only access only to the data we query.
Encrypted Credential Storage
In either case, we store credentials identically: using 256-bit AES encryption. AES is the global standard for encryption and every web browser uses it for connecting securely to banks and other sensitive sites. We uniquely generated the encryption keys per instance of each integration for each client, so no two integrations share the same encryption details. All securely encrypt all credential information we gather prior to storage, whether directly from users or supplied by the third-party service. We never store plaintext values for any credentials.
KPI Parameter Storage
When setting up a Goal in Results.com, we often gather additional information in relation to integrations in the form of KPI parameters. Examples of KPI parameters:
Date range selections (eg: "year to date", "last 90 days", "next quarter", etc.)
Identifiers of specific users or other objects (eg: "user ID 1234" or "project ID 6789") the user selects via dropdown controls or manual input fields
Checkbox selections (eg: whether or not to include closed opportunities)
Without the encrypted information around the credentials, these parameters are not useful. All this data is stored securely in our SQL database.
Whether we're storing encrypted credential values in our SQL database or storing user-selected KPI parameters, we store all this information in our SQL database. Microsoft Azure stores our database in their secure, enterprise-grade data centers. More information about Microsoft's security practices can be found at: https://www.microsoft.com/en-us/TrustCenter/Security/default.aspx
Microsoft recently released support for transparent data encryption within SQL databases on Azure, adding an additional layer of encryption on top of our existing encryption. We are currently testing this and will be rolling this out for an additional layer of protection.
We have put a lot of thought into how we store client data, particularly sensitive information around credentials. We are continuing to refine our security practices to ensure that we continue to provide the best security around the data clients entrust to us.
These are old notes from Blake:
Yep, for most integrations we use OAuth which is a fancy way of requesting access to Google and the user enters their username and password directly on Google's site. The only information we get back is a randomly generated access token (we have no way of even knowing the user's email address from that) that enables us to pull data from their account. These access tokens are strongly encrypted within our database, btw. At any time, a user can login to Google and revoke the access token that Google provided to us. This immediately invalidates the access token and it's worthless.
The above applies to any OAuth provider which includes Quickbooks and Zendesk as well. There are only certain integrations where we directly ask the user for their username and password, and this is due to limitations in the third party. We hate doing that for the simple reason that the user may change their password and the integration stops working, whereas with access tokens the user can change their password as much as they want and the access token remains valid (until revoked or it naturally expires). Regardless, for the few integrations that we ask username and password for, that is securely encrypted in our database just the same.