Dashlane Security Whitepaper

November 2011
Protection of User Data in Dashlane

Protection of User Data in Dashlane relies on 3 separate secrets:
The User Master Password
Never stored locally nor remotely. Never transmitted over a network.
Used to generate a key to cipher user data.
A unique User Device Key for each device enabled by a user
Auto generated for each device.
Used for authentication
A Dashlane Secret Key
Used to secure communication between the Dashlane application and the browser plugins.

Local access to User Data

As User Data is stored locally, the first step in the authentication process is to access locally to the
users data.
Accessing User Data requires using the User Master Password which is only known by the user. It is
used to generate the symmetric AES 256 bits key for ciphering and deciphering the User Data on the
users device.
The User Data ciphering and deciphering is performed using OpenSSL:
A 32 bytes salt is generated using the OpenSSL RAND_bytes function (ciphering) or reading
it from the AES file (deciphering)
The User Master Password is used, with the salt, to generate the AES 256 bit key that will be
used for (de)ciphering. This generation is performed using the OpenSSL
PKCS5_PBKDF2_HMAC_SHA1 function, using more than 10000 iterations
The 32 bytes initialization vector is generated with OpenSSL EVP_BytesToKey function
using SHA1
Then, the data is (de)ciphered using CBC mode.
When ciphering, the salt is written in the AES file
The User Master Password is never stored anywhere:
It is never stored on Dashlane Servers
It is not stored locally on any of the user devices. We simply use it to (de)cipher the local files
containing the user data
In addition, the User Master Password never transits over the Internet


Authentication

As some of Dashlanes services are cloud based (data synchronization between multiple devices for
instance) there is a need to authenticate the user on Dashlane servers.
Authentication of the user on Dashlane servers is based on the User Device Key and has no
relationship with the User Master Password.
When a user creates an account or adds a new device to synchronize his data, a new User Device Key
is generated. The User Device Key is composed of two parts:
A first part, which is a predictable part based on some Hardware and Software characteristics
of the users device
A second part, of 38 characters (lower letters, capital letters, and numbers) generated using
the OpenSSL RAND_byte function.
This User Device Key is then stored locally in the user data, ciphered as all other user data as
explained earlier, and sent to our servers. When a user has gained access to his data using his Master
Password, Dashlane is able to access his User Device Key to authenticate him on our servers without
any user interaction.
As a result, Dashlane does not have to store the User Master Password to perform authentication.
Communication

All communications between the Dashlane application and the Dashlane servers are secured with
HTTPS. HTTPS connections on the client side are performed using OpenSSL. On the server side, we
use a DigiCert High Assurance CA-3 certificate
1
.
The HTTPS communications between Dashlane application and Dashlanes servers are using SSLv3,
TLS_RSA_WITH_AES_256_CBC_SHA connections.
SSL protocol main steps are as follows:
The client and the server negotiate to choose the best cipher and hash algorithm available on
both side
The server sends his digital certificate
The client verifies the certificate by contacting a Certificate Authority
The client encrypts a random number with the servers public key, and sends it to the server.
The server decrypts this number, and both sides use this number to generate a symmetric
key, used to encrypt and decrypt data

1
Key Length: 2048 bit, Signature algorithm = SHA1 + RSA.
Finally, communication between the Dashlane Browser Plugin and the Dashlane Application is
secured using with AES 256 with the OpenSSL library:
A 32 bytes salt is generated using the OpenSSL RAND_bytes function (ciphering) or reading
it from the inter process message (deciphering)
The Dashlane Private Key is used, with the salt, to generate the AES 256 bit key that will be
used for (de)ciphering. This generation is performed using the OpenSSL EVP_BytesToKey,
using SHA1, with 5 iterations
The 32 bytes initialization vector is generated with the OpenSSL EVP_BytesToKey function,
using SHA1
Then, the data is (de)ciphered using CBC mode.
When ciphering, the salt is written on inter process message

Figure 1: Use of Authentication Mechanisms in Dashlane
Anti-Click Jacking Provisions

In order to protect Dashlane users from rogue websites that would attempt to use Click Jacking
tactics or other JavaScript based attacks to extract data from the Dashlane Application, we have
made sure none of the webpage-based interactions involving user data unrelated to this website use
JavaScript.
Instead, all the interactions
2
involving user data have been written in C++ and this compiled code has
seen the use of various packing and protection methods to further complicate reverse engineering

2
The only exception being interactions where data specific to the website is provided like the automatic login
where we do not create any additional risk by using JavaScript
attempts and make Click-Jacking and others Javascript attacks extremely difficult to perform. This of
course wont be relevant if the users computer has been compromised by a rogue program.
For example, the popups used to trigger form-filling on a webpage are C++ popups, and so are
external from the Javascript. As a result, a rogue website cannot trigger a click that would cause
Dashlane to believe that the user has actually clicked, and therefore, cannot extract information
unless the user explicitly clicks in the field.
Impact on Potential Attack Scenarios

Today, cloud based services make various choices to encrypt their user data. These choices have
certain important consequences in terms of security.
Minimal Security Architecture
Cloud Services can use a single private secret, usually under their control, to encrypt all user data.
This is obviously a simpler choice from an implementation standpoint, plus it offers the advantage of
facilitating deduplication of data which can provide important economic benefits when the user data
volume is important. Obviously, this is not an optimal scenario from a security standpoint as, if the
key is compromised (hacker attack or rogue employee), all user data is exposed.


Most Common Security Architecture
A better alternative is to use a different key for each user. The most common practice is to ask the
user to provide a (strong) Master Password and to derive the encryption key for each user from his
Master Password. However, to keep things simple for the user, many services or applications tend to
also use the users Master Password as an authentication key for the connection to their services.
This implies that they have to store some kind of hash of the users Master Password on their
servers, which makes them potentially subject to certain attack scenarios (Rainbow Table).


Dashlane Security Architecture
In order to make this attack scenario impossible, we have made the decision to separate the key
used for User Data encryption and the key used for server based authentication (See Figure 2: Limits
on Attack potential with Dashlane's security Architecture). The User Data is encrypted with a key
which is a derivative of the User Master Password. A separate User Device Key (unique to each
device-user pair) is used to perform authentication on Dashlane Servers. This User Device Key is
automatically generated by Dashlane. As a result:
Encryption keys for User Data is not stored anywhere
No Dashlane Employee can ever access User Data
User Data is protected even if Dashlane Servers are compromised

Figure 2: Limits on Attack potential with Dashlane's security Architecture

Even if this scenario happens, a rogue employee or an external hacker would have a very hard time
executing a brute force or a dictionary attack on the AES user data files, as we the use of the PBKDF2
algorithm, used with more than 10,000 iterations. As the user data are encrypted using a key which
is a derivate of their User Master Password, an immediately large scale attack is of course impossible.

As an example, this is a benchmark of attempts to decipher AES files using a Xeon 1.87GHz (4 cores):

Time to get the password on a Xeon 1.87 GHz (4
cores)
Type of brute force attack

AES 256
AES 256 with PBKDF2-SHA1 with
10000 iterations
4 million terms dictionary
2,8
seconds 21 hours
Alphanumerical(small caps + digits) password of
7 characters
15,7
hours 48,6 years
Alphanumerical(small caps + digits) password of
8 characters
23,6
days 1751,3 years

This table represents the time it would take on a Xeon 1.87 GHz (4 cores) to break a password used
to protect Dashlane user data. Without using PBKDF2, those numbers show that even with a strong
password, an attacker would be able to crack the user password within less than a month.
Using PBKDF2, and given that Dashlane enforces reasonably strong password requirements
3
(and so
user Master Passwords are not contained in a dictionary), an attack would be impractical
Obviously there is a limit to any security architecture. If the users computer is physically
compromised and an attacker is able to install a key logger allowing him to capture all keystrokes,
then no password based security system will prevent data theft or piracy. This is why the end user
still remains responsible for physically protecting his computer from non-authorized access and for
making sure he is not installing potentially infected software. Our point is that in any event, a
Dashlane user is no matter what significantly more secure than if he stores sensitive personal data in
Word or Excel documents, or passwords in the cache of his browsers.


3
At least one upper case, one lower case, 1 digit and at least 8 characters

Details on Authentication Flow
The initial registration for a user follows the flow described in Figure 3: Authentication flow during
registration.

Figure 3: Authentication flow during registration

As can be seen in Figure 3, the User Master Password is never user to perform Server Authentication,
and the only keys stored on our servers are the User Device keys.


Figure 4: Authentication when adding a new device
When adding a second device, the important point is that Dashlane needs to make sure the user
adding the additional device is indeed the legitimate owner of the account. This is to gain additional
protection in the event the user Master Password has been compromised and an attacker who does
not have access to his already enabled device is trying to access the account from another device.
As shown on Figure 4, when a user is attempting to connect to a Dashlane account on a device that
has not yet been authorized for this account, Dashlane generates a One-Time Password (a Token)
that is being sent to the user either to the email address used to create the Dashlane account
initially, or by text message to the users mobile phone if the user has chosen to provide his mobile
phone number.
In order to enable the new device, the user has to enter both his User Master Password and the
Token. Only after this Two-Factor authentication has been performed will Dashlane servers start
synchronizing the user data on the new device. All communication is handled with HTTPS and the
user data only travels in AES-256 encrypted form. Please note again that the user Master Password
never transits on the Internet.

Keeping the User Experience simple

All along, our goal is to keep the user experience simple and to hide all this complexity from the user.
Security is growing more and more important for users of Cloud services but they are not necessarily
ready to sacrifice convenience for more security.

Even though what goes on in the background during the
initial registration steps is complex (See Figure 3) and
highly secure, the perception by the user could not be
simpler. All he has to do is to pick a (strong) User Master
Password. All the other keys are generated by the
application without user intervention.



When adding an additional device, the process is
equally simple, while remaining highly secure
through the use of Two-Factor authentication
described in Figure 4.