Encryption of Database Password
When using DB2e as persistence, you can make use of encrypted DB2e installation files. This requires the use of a password to connect to the database instance.
Normally MI uses a default password and the encoded format of this password is stored internally. However the users can specify their own password and then the encoded format of this password is stored in the MobileEngine.config file.
In order to further protect this encoded password from the eyes of unauthorized users, Secure Storage functionality can be used. Secure Storage is a mechanism of storing the encrypted database password in a more secure manner, and the database password is removed from the MobileEngine.config file which anyone can access.
For information on
configuring encryption, see
Setting Up Secure
Storage.
If the database password encryption is activated it affects the following areas:
Multiple users cannot be created at the same time on the client. After a user has been created the information must be synchronized. Once this has been done, the next user can be created. The synchronization completes the initialization of the created user and a keystore is created with the user’s local logon password. Once the keystore has been initialized, it is possible to create more users.
When the server is accessed during synchronization a connection to the keystore is created to read the key. The key is used to decrypt the database password. This password is then used to create the connection to the database. The different types of synchronization can be defined as follows:
● Mobile device initialization
During the first synchronization, the server initializes the mobile device and provides it with a device ID. The server generates a symmetrical key and sends it to the mobile device. The user is then initialized, a keystore is created, and the database password is encrypted.
● Standard synchronization
The server selects the symmetrical key that is assigned to the mobile device and sends this to the mobile device, together with the data to be synchronized. The symmetrical key is required to decrypt the database password.
● Where the mobile device is used by multiple users (without Single Sign-On)
After the user has logged onto the client the keystore is opened. If the user was initialized correctly, his or her keystore contains a symmetrical key, which is required to access the database password.
● Where the mobile device is used by multiple users (with Single Sign-On)
If the user has logged on using Single Sign-On, the keystore is not opened. Instead, the connection to the database is formed using the symmetrical key sent by the server. In this case, the keystore is not used.
● Where the mobile device is used by one user (with logon)
If the user authenticates his- or herself on the client with the user and local logon password, the keystore is accessed in the same way as described in Where the mobile device is used by multiple users.
● Where the mobile device is used by one user (bypass option)
If the user authenticates his- or herself using the system logon (bypass option), it is not possible to protect the keystore because the user does not have to authenticate themselves on the client directly. In this case, the user’s keystore is protected by a hard-coded password. This solution is not, however, as secure as the encryption of the local logon password in the keystore. It is to be considered as more of a workaround.
● Change of local logon password
If the user changes his or her local logon password that was already stored as encrypted data in the keystore, the existing keystore is deleted and replaced by a new one.
● Resetting the local logon password
If the user has forgotten his or her password and resets it, a new keystore is created and filled with the symmetrical key sent by the server. The old keystore, whose access requires the old password, is deleted.
An online connection to the server is required to reset the logon password.