Data Loading...
Security Whitepaper V2 Flipbook PDF
Dashlane Security Whitepaper November 2014 Protection of User Data in Dashlane Protection of User Data in Dashlane relie
138 Views
57 Downloads
FLIP PDF 1.86MB
Dashlane Security Whitepaper November 2014 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’s data is stored locally. The first step in the authentication process is to access locally to the user’s data. User’s 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’s personal data on the user’s device. The user’s 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
By default, the User Master Password is never stored anywhere: • • • •
It is never stored on Dashlane Servers By default, 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 It is stored locally upon user request when enabling the feature “remember my Master Password” In addition, the user Master Password never transits over the Internet
Use of Google Authenticator to increase user’s data safety At any time, a user can link his account to a Google Authenticator application on his mobile. All of his data, both the data stored locally, and the data sent to Dashlane servers for synchronization purposes are then ciphered with a new key, which is generated by a combination of the User Master Password and a randomly generated key called User Secondary Key stored on Dashlane server, as described in the following steps: • • • • •
The user links his Dashlane account with his Google Authenticator application Dashlane servers generate and store a User Secondary Key, which is sent to the user’s client application All personal data are ciphered with a new symmetric AES 256 bits generated client side with both the User Master Password and the User Secondary Key. The User Secondary Key is never stored locally The next time the user tries to log into Dashlane, he will be asked by Dashlane servers to provide a One-Time Password generated by the Google Authenticator application. Upon receiving and verifying this One-Time Password, Dashlane servers will send the User Secondary Key to the client application, allowing the user to decipher his data
Doing so, user’s data can be deciphered only by having in the same time the User Master Password, and the Google Authenticator application linked to the user’s account.
Authentication As some of Dashlane’s 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 user’s 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 certificate1. The HTTPS communications between Dashlane application and Dashlane’s 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 server’s 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
Finally, communication between the Dashlane Browser Plugin and the Dashlane Application is secured using with AES 256 with the OpenSSL library: • •
• • •
1
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
Key Length: 2048 bit, Signature algorithm = SHA1 + RSA
Figure 1: Use of Authentication Mechanisms in Dashlane
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 this not an optimal scenario from a security standpoint since 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 user’s 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 user’s 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 couple device-user 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 15,7 7 characters hours
48,6 years
Alphanumerical(small caps + digits) password of 23,6 8 characters 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 requirements2 (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 user’s computer is physically compromised and an attacker is able to install a keylogger 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 stores sensitive personal data in Word or Excel documents, or passwords in the cache of his browsers.
2
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 user’s 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 Master Password and the Token. Only once 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.
“Use of Google Authenticator to secure the connection to a new device” At any time, a user can link his Dashlane account to a Google Authenticator application on his mobile. When he attempts to connect into a new device, instead of sending him a One-Time Password by email or by text message, Dashlane asks the user to provide a One-Time password generated by the Google Authenticator application. After receiving and verifying the One-Time Password provided by the user, Dashlane servers will store the User Device Key generated by the client application, as described in Figure 6.
Keeping the User Experience simple All along, our goal is to keep the user experience simple and to hide all the 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 as (strong) 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.
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 interactions3 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 attempts and make Click-Jacking and others Javascript attacks extremely difficult to perform. This of course won’t be relevant if the user’s computer has been compromised by 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
3
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
Dashlane to believe that the user has actually clicked, and therefore, cannot extract information unless the user explicitly clicks in the field.
Same-origin policy Dashlane automatically logs users into websites. In order to avoid providing user’s information to rogue websites, the same-origin policy is always respected. First, a credential saved by Dashlane when it has been used on a website with a Url of the form mysubdomain.mydomain.com will not be automatically filled on another website with a Url of the form myothersubdomain.mydomain.com. This prevents a credential of a specific website from being provided to another website which would share the same top level domain name. Also, a credential saved by Dashlane when it has been used on a website with a Url beginning by https will not be automatically filled on another website with a Url beginning by http.
Using Password Changer to further increase the User security The “Password Changer” feature of Dashlane offers a 1-click experience to change a password for a particular website. This makes changing passwords for compromised websites easier. Furthermore, it provides users a convenient way to regularly update their passwords without going through the hassle of manually updating passwords for websites they have. Password Changer makes such a very important security practice, which is rarely followed, a lot easier. To change a password for a particular website, a Dashlane’s client sends current saved password to Dashlane's servers along with a new strong password generated on the client. This communication is done using secure websockets (Websockets over SSL/TLS – the SSL termination is done using AWS Elastic Load Balancers as for any other Dashlane webservices) to prevent Man-in-The-Middle attacks. The servers try to login to the targeted website and change the user’s password using either a browser navigation or a call to an API depending on the website. Dashlane prompts the user for additional information if needed (e.g. security question) using the same secure websocket connection. At the end of the operation, it notifies the user with the result. In case of success, the client updates the password locally. The servers (AWS EC2 instances) that are used to provide Password Changer are separated from the rest of the Dashlane's server infrastructure (dedicated instances and distinct AWS security groups). Additionally, on the server side, sensitive information (e.g. logins and passwords) is stored in RAM only. It’s removed from RAM right after the result is sent back to the client (the password change takes 45 seconds in average), or after five minutes in case of a client disconnection.