DEVELOPMENT

No, all in-flight data will be encrypted on its way to TrueVault via SSL. Once your data hits the TrueVault API, it goes through TrueVault's encryption process to be individually encrypted. To learn more about this process, check out our secure infrastructure overview.

TrueVault does not limit the rate of successful requests to our servers. However, we do lock users and accounts based on number of unsuccessful attempts made within a certain time frame.

Yes we keep audit logs of all account activity in TrueVault. To request these logs, send an email to help@truevault.com. Please include the account's ID and a target date range in the email and we'll respond with the corresponding logs shortly.

Yes we support CORS. Any client can make cross-origin requests to TrueVault.

When you're building a mobile app from the ground up, there are a number of security concerns you have to account for. If you're handling sensitive data, it can be helpful to think about the various states your data will experience: In use, on the device: When your data is stored in memory on the device and is being entered/reviewed by your user, it generally is not encrypted. When you save data to permanent storage, it transitions from in use to at rest.

Start by creating the vaults and schemas in a structure that resembles what you are currently using. For example, if you are migrating from a SQL data store, be sure to mark all fields corresponding to indexed columns as indexed in your schema. Migration of data is straightforward if your product is not yet live. Query each record in your existing data store, convert it to a JSON document matching your schema in TrueVault, and upload it using the TrueVault HTTP REST API for Documents.

Images stored as BLOBs can be displayed inline using HTML5 Blobs. Download the raw BLOB bytes using XHR, and then use the window.URL.createObjectURL function to display it in an img element. Here’s an example:

It is a common use case to store a list of tags associated with a Document. For instance, you may want to tag a patient with various labels such as High Blood Pressure, and Spanish-Speaking. You may store a Document that looks like the following: { "name": "John Doe", "tags": ["High Blood Pressure", "Spanish-Speaking"] } Once stored as an array, the in filter will perform an OR search for a list of tags.

Your TrueVault end users can protect their data even when their password is stolen by enabling multi-factor authentication (MFA). If a user has enrolled in MFA, they must provide a time-based MFA code when logging in, as well as their username and password. The MFA secret is stored on a mobile device using an MFA application (Google Authenticator, Authy, etc.). Hackers will not be able to log in as a user unless they have access to the user’s mobile device, as well as the correct username and password.

Your TrueVault administrative account has extensive access to your data through the management console, so it is absolutely critical to secure the credentials to that account. We strongly recommend enabling Multi-Factor Authentication (MFA) as an additional measure to safeguard your data. This guide will walk you through the process of configuring MFA for your TrueVault Account. Before You Start: MFA App If you haven’t used MFA before, you’ll need to download a suitable TOTP token-generation app for your smartphone.

You can restrict users’ access to data stored in TrueVault with granular Group Policies. This is a critical component of the security of your application, and we recommend enforcing minimal access for every user. Read more in our Access Control Best Practices guide. Policies Policies are composed of two components: Resources: A list of resource specifiers that describe which Documents, Vaults, BLOBs, Users, or Groups the Policy grants access to.

Quick Note: If you’re trying to reset the password on your TrueVault account, you can do so in the management console. The rest of this article describes how to implement a forgot password flow for your end-users. Overview If your end-users forget their passwords, you may want to support an email-based password reset flow. TrueVault makes it easy to set this up using a Generator in the management console. Here’s what you’ll need to get started:

TrueVault provides everything you need to handle user authentication and access control. Using our login endpoint you can quickly stamp out authentication in your application with no server-side work. Better yet, you can be confident that the authentication process is secure and compliant, because that’s what we do. Logging In When a user logs into your application, they enter their username & password into your form and you make an API Call to TrueVault passing these fields and your Account ID.

You can use the user search API to search for users by TrueVault system fields (username, status, created date, and id) or by custom fields you store in user attributes. To search by your custom attributes, you need to first setup the user schema to tell TrueVault which fields to index. Searching by System Fields As soon as you create your first user you can search for that user by the TrueVault system fields: username, status, created date, and id.

Applications commonly need to contact their users outside the context of the application’s UI, like with an email or text message. However, contact information like a phone number or email address is considered personally identifying information (PII), so you don’t want to ever have that information on your servers, even if it’s only briefly while you’re sending the user an email. By storing your users’ sensitive data in TrueVault, you avoid all the headaches associated with handling that data on your own servers, and with TrueVault’s Messaging API, you can reach out to your users via SMS without ever having their PII touch your servers.

On mobile, each OS has a way to make HTTPS requests in their SDKs. Here is the documentation for iOS and Android. For web applications, any front end framework will allow you to make HTTPS requests in their own way. Click here for a short tutorial on how to make web requests using jQuery.

We recommend representing each user in your system with a unique user in TrueVault. This allows you to maximize the value you get out of our access control and audit log capabilities. It also saves you the time and effort of creating and maintaining secure authentication and user management.

There are two common patterns we see for user registration in our customers applications: self-registration and invite-only. In the self-registration flow, any user can come to your product and register for a new account. They don’t need to be invited. In the invite-only flow, some administrative user will invite new users manually and configure their access. In some applications, both flows are used simultaneously. For example, you might want self-registration for patients but invite-only for medical staff. We’ll describe both approaches here.

The best way to ensure that Users have access to only their own Documents or BLOBs is to implement Ownership. Ownership is the mechanism which allows applications to specify an owner per Document or BLOB. Once a User is assigned as a Document’s Owner, any member of a Group that has Document access with that Owner (with self, .*, or the specific Owner User ID) in the Group’s policy can access that Document.

TrueVault has several authentication mechanisms that support the main access patterns our customers use. This primer will give you a quick overview of how to authenticate in these common scenarios. End Users When your end users connect to TrueVault, they need to authenticate to access their data. We recommend you make these connections directly from your client application, not from your server side, to ensure sensitive data doesn’t pass through your servers.

For the client application to gain access to TrueVault, a User Access Token is recommended as it is time-bound. It is typical for a client to authenticate either with the application server or directly with TrueVault to acquire an User Access Token with the Login a User endpoint. Under no circumstances should an API key with access to sensitive information be hardcoded into the app, as that is not a secure storage medium.

Proper Access Control is an important part of securing your data. If your rules are too permissive, the wrong users may get access to sensitive information. The guidelines here will help steer you in the right direction. If you have further questions, don’t hesitate to ask. See also: access control basics. 1. A User for Everyone! First and foremost: make sure there is a distinct user for every person who uses your product.

Data De-Identification is the process of separating Personally Identifiable Data (PII) from the Protected Health Information (PHI) your system stores. It is the easiest way to become compliant without compromising your technical flexibility. The advantage is that you can store this de-identified data (PHI minus the PII) anywhere you want; the infrastructure and code that interacts with this data does not need to adhere to HIPAA. You have to be careful about how you de-identify the data, and you have to store the PII securely in a system like TrueVault.

Search results are paginated. By default, 100 results are returned per page, configurable via the per_page parameter. In order to request from one page to the next, a page index is specified in the search_option. The default value is 1, referring to the first page. If you want to look at the fourth page, set page to 4: { "filter": { "state": { "type": "eq", "value": "CA" } }, "page": 4 } Metadata about the entire result set is in the info field of the response.

Our API is platform-agnostic. If your application can make web requests, it can interface with TrueVault.

When you store a Document or BLOB with TrueVault, it is processed and stored using our proprietary backend. From a developer’s perspective, it functions similar to a schema-less NoSQL database. Developers are able to flexibly design Schemas that allow for searching, filtering, and sorting of your data. When a request hits our backend, the data is immediately encrypted and stored in TrueVault's secure infrastructure.

We recommend generating and doling out User Access Tokens for each User upon logging in. These User Access Tokens can be regenerated without manual intervention and expire in 24 hours. We recommend using API Keys for application servers to avoid regenerating a User Access Token every 24 hours. API Keys persist until manually rekeyed or deleted by an Administrator User.

Our User MFA endpoints make it simple to increase your application’s security by strengthening end-user authentication. To show how the integration works, we’ve created a simple JS application that uses TrueVault for user authentication and data storage. Then we implemented User MFA in a separate branch so you can see exactly what it takes to add User MFA to your existing application (see the difference here). The details may vary based on your application stack, but the flow (and of course, the TrueVault API Endpoints) will be the same.