thoughts on a Password Manager

As part of my time in University of Oxford, I was challenged with identifying some security properties associated with a password manager along with defining a high level design for a conceptual password manager, before reading just remember I spent less than 2 days reviewing such an approach, no doubt several improvements can be made. These are thoughts and concepts; having said that everything documented below is achievable.

Password Manager Security Properties

Confidentiality

Ensuring user data remains secret is a primary design principle.

Availability / Reliability

If a user ‘buys’ into a password manager, this suggests a user has many passwords to manage. Safely leaving these passwords in a secure and convenient location is an appealing idea. Having only one password to remember is a highly desirable notion, therefore such users of password management solutions can conveniently forget passwords for each individual site. Based on such a convenient idea the need for high availability is paramount to the success of such an application. Without a high degree of availability user convenience and confidence will diminish rapidly. Protecting against denial of service attacks in any form has to be considered one of the highest priorities.

Prevention / Authentication

Presenting strong levels of authentication with several options will gain user confidence, providing solutions for second factor authentication would be considered a primary feature. Preventing adversary gaining unauthorized access to user credentials or any user data especially master passwords would be considered a one of the highest priorities.

Detection

Having the ability to proactively analysis application helping to detect intrusions would be a great assist for such an application. One would have to ask the question if an application is breached would they inform application vendor? Most likely if the breach was such a breach to be replayed many times why would an adversary inform the application vendor. Therefore having the ability to analysis application to help determine intrusions would be of great assistance.

Integrity

Accuracy of all information held per user should be high priority; such a solution will be storing details relating to usernames, web site passwords and web URLs. Potential threats target at manipulating the integrity of stored data could lead to denial of service e.g. usernames are purged or amended.

Accountability

Any amendments to stored data will need to have appropriate accurate audit trails. Basic questions would need to be answered; when a user account was registered, when user updated username, added new records, updated existing record etc. Having the ability to ensure support and administration staff can not amend these records without user knowledge would be a very desirable requirement.


High Level Design

Due to the nature of a password manager application, a primary design consideration is ensuring secrecy and confidentiality of users data, including master password and individual users web site credentials. Having thought of different methods for design and data storage; it became apparent that ensuring administrators of the application would not have access to master passwords and users web site details was a primary objective. This allows the application to be protected against both outside and inside adversaries (e.g. admin staff). Rather than just being able to say data is encrypted on the cloud database servers; it can be said data is stored encrypted and even administration staff cannot decrypt the data. An alternative approach (and possible simpler design) might be to store a hashed master password, encrypted web site credentials and symmetric encryption keys on the cloud database servers and just encrypt data on the cloud database servers, this is possible a simpler design approach but opens up the possibility for administration staff to gain access to encrypted data and possible outside attack if database is compromised. A more challenging approach is to try and ensure even administration staff cannot access encrypted data by preventing the symmetric key from being stored on the cloud database servers. This therefore leads to a number of design issues with respect storage of master password and the symmetric key for encryption.

A user has the ability to add devices, a device maybe a mobile or desktop application, in addition a user would be given the ability to view all devices registered using a web UI to the cloud database servers. This means the cloud database servers stores details related to each individual devices registered by the user. The primary objective for the cloud database server is synchronization and allowing the user revoke access to individual registered devices. This password manager does not provide additional features like auto form filling or auto password storage options. This does mean more manual processing from a user point of view, but also reduces the attack surface. To use application the user would enter master password and then select which site they require a password for. All traffic communication registration, synchronization etc. would be protected over TLS/SSL with HTTP protocol i.e. HTTPS.

To review the most important areas of the design, the following sections are discussed in more detail.

  • The Data
  • Registration
  • Data Storage
  • New device registration & initial data synchronization

The Data

The application requires the following data to function, this section is not concerned with data storage it just explains the data.

Username

This will be a users email address. Email address is chosen due to nature of uniqueness.

Master Password

The only password the user must remember. This password will go through an appropriate password policy-cleansing phase before being accepted.

Individual web site credentials

This includes the web site URL, the password to access and the username for the web site.

Mobile number

Used for 2nd factor authentication.

Device description

Allows user to identify different devices, each time a device is registered user must provide a descriptor. This will later allow the user to ‘disconnect’ a device if the need arises.

Registration

A user registers either for the first time or registers additional devices. During the registration phrase, the data is collected and verified. The validation process concentrates on verifying email address and mobile number. By simply ensuring they are valid and the user has access to both; along with ensuring it is unique to the application. The user’s password goes through a password policy certification process ensuring password in question is strong enough to prevent dictionary style brute force attacks. A suggested password policy would be

Ensuring minimum

  • Length 8 characters
  • 1 numeric base 10 digit
  • 1 upper case character
  • 1 special style character e.g. @ ! # * etc.

In addition verifying the password does not contain any black listed style passwords, typically this blacklist would include the top 1,000 poor password strings e.g. ‘password’, ‘password123’ etc.

Data Storage

For a password manager this section of the application / design is most important. Primary objective is ensuring user content is kept confidential and away from adversaries both inside and from outside. Data is stored both on the client side and in the cloud servers. More data is store on the client side than in the cloud database servers. Outlined in table below is what data is stored and where.

Data on Client Side
Username - Yes
Master password - No
Individual web site credentials - Yes
Symmetric private key - No
Mobile Number - No
Device Description - No
Device ID - Yes
Web UI Password - No

Data in Cloud Database
Username - Yes
Master password - No
Individual web site credentials - Yes
Symmetric private key - No
Mobile Number - Yes
Device Description - Yes
Device ID - Yes
Web UI Password - Yes

Objective for the cloud database servers is to facilitate synchronization between devices and help disable a device for being able to synchronize. Below takes each data element and explains how each is stored on both the client and cloud servers.

Username

This is the users email address and forms part of the authentication credentials. In order to prevent username enumeration and help protect against outside adversaries getting a hold of usernames (e.g. Injection via SQL); storing this element in hashed form will help prevent such a threat, a total compromise of the database will also help prevent username enumeration i.e. its not possible to list the users of this application by simply selecting usernames from a database table. This does not protect the application from administration staff wanting access to usernames, most likely administrations will have access to email servers or SMS services therefore it is still possible for administrators to determine all users of the application as part of the registration process issues emails, therefore a trail of emails will be available.

    PRNG salt + (Sha1-256 (username + PRNG Salt))

The addition of salt in this case is provided to help prevent a reverse rainbow table lookup. The salt stored is prefixed to the hash result of username and salt. Again, the generation of the salt is via secure random number generators i.e. (CSPRNG)

Master Password

This password is the only password a user must remember. It is only stored on the client side, as there is no need to store on the server side. Storage of this password will use the following formula, again it is using hash algorithm as its cryptographic basis.

securePassword = username as salt || Sha1-256((plaintextPassword|| Username as Salt)

The hash algorithm at a minimum is Sha-1; this could be upgraded to Sha-2. For future proofing it would be recommended to prefix the password with a version number therefore allowing passwords to be upgraded to future stronger hash algorithms.

securePassword =    passwordVersion || 
        username as salt || Sha1-256((plaintextPassword||Username as Salt)

Individual Web Site Credentials

This data is stored on both the client and cloud database server. As part of the design of this password manager, this data is to be encrypted; therefore generation of the symmetric key for encryption is important. AES-256 would be the recommended symmetric encryption algorithm running in CBC (cipher block chaining) mode. As a user may add additional devices, determining the symmetric key must therefore be based on a formula; storing this private key in the cloud is not part of the design for this password manager. By not storing the private key in the cloud ensures administration staff will not have access to these details. To derive a private key; a deterministic key derivation function will be used. A typical key derivation function is PBKDF. This function takes the following parameters

PBKDF (salt, password, iteration count, key length)

In this password manager the following values are used for the formula.

Salt users email address (username).
Password master password
Iteration 1,000 (recommended minimum [6] )
Key length 32 Bytes (as AES 256 bit is used.)

Once this symmetric key is derived, all web site credentials are encrypted before transmitting to the cloud servers.

User derived Symmetric private key

By using the formula above, this private does not need to be stored as it is based on being derived. It only needs to be stored in memory; therefore this private key is not stored on client or on cloud server. It should be noted performance of the application might be slightly impacted, as the key needs to be derived each time it is needed.

Mobile Number

Mobile number is to form part of the process for adding additional devices and helps with 2nd factor authentication for the web UI authentication. This mobile number is stored in the cloud database servers encrypted.

The symmetric key used in this case is derived by the server side as server side code needs access for 2nd factor authentication. Storage of this private key is held externally to the database and recommended to be stored on an additional secure server.

Device Description & Device ID

A description for each device registered by the user. This will allow the user revoke access to any particular device from synching encrypted data if compromised. Each device on first registration is issued with a device ID, this device ID on client side is encrypted with the same user derived symmetric key above, on the server side this device id is encrypted with the same key used to encrypt the mobile number. The device id is encrypted at rest; during transmission it is only protected using HTTPS.

Web UI Password

With the addition of a web UI allowing the user to view devices registered with the ability to revoke adds one additional issue with respect to credentials for web access. What password should be used to access the web UI? The objective is the user only has to remember one password and one of the primary design objectives is to ensure the master password is not stored on the cloud database servers. When the user registers for the first time; a password for the web UI must also be generated. As part of the design the master password is not stored in the cloud database servers, this therefore causes an issue for authentication to the web UI. As part of registration a new password is generated for the user. On the client side the following formula is used, the resulting encrypted password is sent to the cloud database servers.

(Master Password) user derived symmetric private key

In addition to access the Web UI, 2nd Factor authentication is implemented. During web UI authentication, client side code can request the master password, then derive the users symmetric private key, encrypt the master password and send to the cloud server to compare encrypted values.


User Interface

Three UI’s are provided, web, browser extension and mobile application. Both web and browser extension code would share same code base most likely written in JavaScript, while the mobile application would be native to base OS, in this case Android and Java or Objective C / Swift for Apple based devices. It could be argued not to write native code for Android and IOS and instead write all code in JavaScript utilizing local storage. There is nothing in this design preventing all software from being written in JavaScript.


New device registration & initial data synchronization

An example of an expected flow of data for a new device registration and initial data synchronization. At this point the user has already registered having a record on the server side. Objective is to register new device, get web credentials and issue a device ID, for subsequent data synchronizations.

Scyther Model [1]


In addition to security properties and a high level design, other areas included identifying possible attacks and then documenting some mitigating measures.


[1]Cas Cremers http://www.cs.ox.ac.uk/people/cas.cremers/scyther/