Upon account creation, the server collects minimal identifying information such as first name, last name, username, Date of Birth, and email address. The server stores of this identifiable account information in a back-end database distinct from the one that stores the study data. Currently, the Bridge server uses a commercial authentication system provided by Stormpath to store and manage such user account data. Stormpath is one of the leading providers of user management and authentication services, with experience in securing user accounts using start-of-the art security technologies and practices (see Stormpath's Security and Availability documentation for a description of their system). Using a third-party service specializing in user management and authentication allows us to achieve solid security around users’ personal account data and ensure a clean separation between personal account data and the de-identified study data that can be used for research. This way, in the rare event that either database is compromised, the connection between a person and her/his health data will remain protected.
Mobile or web clients do not communicate directly with Stormpath, but instead with the Bridge API backed by the Bridge server running on Heroku. In our current implementation, the Bridge server acts as a proxy to Stormpath for management of user account data. Although we have identified no concerns with hosting user account information in Stormpath, our architecture is such that, if needed, we can move to a different service, or even to an in-house implementation.
The identifying information collected by the server in a participant's account is needed to create a record of informed consent, tied to a person's identity, and to facilitate recontacting of study participants by the original research term when permitted by the study protocol. Most account data is stored as encrypted key value pairs in Stormpath, and the Bridge server encrypts / decrypts user data as it is stored / retrieved from Stormpath, using a key generated and controlled by Sage Bionetworks. The exception to this is user email which is managed securely by Stormpath, but not separately encrypted by the Bridge server. This allows Stormpath to take on some aspects of user account management such as email validation and password resets.
When the Bridge server makes calls to Stormpath, we supply an API key provided by Stormpath so they can authenticate call coming to our instance. The Bridge server uses standard HTTPS to communicate with Stormpath, thus we use standard certificate authorities to authenticate Stormpath to ourselves. At the time of this being written, the Stormpath certificate is issued by DigiCert High Assurance EV CA-1. As we are using Stormpath's Java SDK library, the communication is handled by Java 7 runtime. The DigiCert's certificate is included in the Java 7's trust store. The connection uses TLS 1.2. It is encrypted using AES_128_GCM and uses ECDHE_RSA as the key exchange mechanism.