Skip to main content

SecureAuth Profile Data Encryption Using Advanced Encryption



This article explains the SecureAuth method for storing and protecting Profile Data using Advanced Encryption.


The SecureAuth Identity Provider can require different or multiple authentication methods to access or enroll access into protected resources.

Among these options for establishing identity are out-of-band methods listed here:

  • Voice telephone call

  • SMS message

  • Knowledge Based Methods such as questions and answers

At times, this information can be sensitive. The data may be considered sensitive and should not be viewable by anyone other than the end-user. This may be personal or information used during multi-factor authentication (e.g. KBA answers, personal mobile phone number, PIN, personal email addresses, etc.).

SecureAuth does not maintain a directory or datastore of its own; profile information is stored in the enterprise directory or datastore. Since SecureAuth cannot prevent the data from being accessed once it is written to the directory or datastore, SecureAuth prevents the compromise of a user's profile information by encrypting the data before writing it to a field in the user's directory profile.

The encryption methodology implemented by SecureAuth is designed to do the following:

  • Work with a cluster of SecureAuth servers

  • Be computationally efficient

  • Protect the integrity and confidentiality of user data

  • Resist attack

Example of a KBA Encryption


How SecureAuth Achieves these Goals

Working with a cluster of SecureAuth Server

SecureAuth uses encryption in a number of its operations, so a variety of options are available in the design of the profile data encryption. In order to work with a group of synchronized SecureAuth servers, a common key is required that all members of the group can use to access data in the shared database/directory. SecureAuth already uses a common key when grouped for redundancy for other encryption operations, such as signing SAML artifacts, in the form of x509 identity certificates.

Computational Efficiency

Using an asymmetric-key cipher is not computationally efficient for large amounts of data. Therefore, not all of the data written to the user's profile attribute are encrypted with the x509 certificate, which provides an asymmetric RSA public/private key-pair. Symmetric-keyed ciphers are much more efficient, but require a stored key.

Protecting User Data

Therefore, each time SecureAuth writes a user's profile data to the directory a new, random key is generated to use with the AES (symmetric-keyed) algorithm, which is then encrypted by the x509 certificate of the SecureAuth server or group of servers. This familiar model for protecting blocks of data with essentially an asymmetric key-pair has two benefits:

  • Prevents a key from being stored in the configuration of the SecureAuth server

  • Prevents the compromise of the key used to encrypt a user's profile data from exposing all user profile data

Resistant to Attacks

This means that each user's profile data set is encrypted with a unique key with the AES algorithm. In the case that the key for one user's profile entry is compromised, possibly through a brute force attack, the key revealed will only decrypt the current data set and no others. Additionally, since the key is generated each time data is written, the compromise of a key only affects a specific entry until one of the following occurs:

  • A user updates the user's profile data, which would rewrite the data for that individual’s profile; or

  • An administrator may possibly initiate a programmatic method that could roll groups of user data to new keys by rewriting the data.

Once the random key is generated and used to encrypt the user's profile data, it is encrypted by the SecureAuth x509 certificate; therefore only a holder of the private key associated with the certificate, a SecureAuth server or group, can reverse the encryption and reveal the key.

SecureAuth IdP User Profile Data Encryption

The encrypted key data and the encrypted user's profile data are then concatenated as a single, large, text blob that can be written to a field in the directory or datastore and bounded with a human-readable description and version information.