How to choose a password manager - LINDDUN threat model analysis

Follow along with this LINDDUN threat model analysis of password managing software. The pick of the most secure options comes down to two options.

Linkability

• can lead to identifiability
• identifiability can make the vault more detectable
• email address must be anonymous & private
• minimization: avoid favicons; URLs are a security feature but a privacy risk
• anonymous payment method necessary
• gibberish information (noise) instead of real info

Identifiability

• can make the vault detectable at different service providers

-> email provider receives a confirmation email

-> login notifications sent in plain text (over TLS) but providers can still see what devices are used for logins

-> login notifications are a security feature

Non-repudiation

• Deniability of password vault essential (e.g. when border crossing)
• Access to unlocked/unencrypted storage will reveal password vaults and existence of protected data
• Is hidden (deniable) encryption possible?

Remedies

• not storing sensitive content on person
• not tying cloud storage to one's identity
• not keeping storage credentials on person (i.e. memorized credentials)
• traffic anonymization necessary (Tor; VPN)
• purchasing records can reveal usage of a service

Detectability

Disclosure of Information

• full security threat model analysis - Microsoft STRIDE

https://www.linddun.org/disclosure-of-information

Information disclosure of data store

Information disclosure of a data store can occur, similar to the data flow, when the data store itself is insufficiently protected against unauthorized access and/or when the data itself is not kept confidential.

When both the database protection scheme can be bypassed (because of a canonicalization failure, weak or no protection, or other consumers next to this application) and the data is intelligible as it is unencrypted or an authorized user can be spoofed, information disclosure at the data store is possible. Also side channels which reveal information, and extra-monitor access are a threat to data confidentiality. Finally, storage management can fail: what happens when the application undoes or recovers an operation? How is sensitive data erased or hidden (occluded data)? Storage might also be incorrectly initialized or cleared.

Information disclosure of process

A process can disclose information when it is not sufficiently protected against side channels or when it is corrupted by an input validation failure or memory access. Also, in case the user who has access to the process can be spoofed, information can be disclosed.

Spoofing, tampering & elevation of privilege

An entity can be spoofed by either obtaining legitimate credentials from an existing user or falsifying credentials. When an insufficient authentication system is present, the entity can also be easily spoofed. Questions that need to be asked regarding credentials are: How are the credentials protected at storage? How are credentials transmitted? How secure is the protocol to update credentials? How complex is the credentials: is it easy to guess, can multiple credentials be treated as the same, are accounts with no password (null credentials) supported? Also the authentication scheme should be examined: does the application support an older, less-secure scheme? Can the user access more than he should?

A misactor can tamper with the data flow if either the channel or the message has insufficient integrity measures. The analyst should verify whether the dataflow is defended against replay attacks and collisions with e.g. time stamps or counters. When no of weak message or channel integrity is present, tampering also becomes possible. Finally, the channel can also be violated through man-in-the-middle (MITM) attacks.

Tampering of the data store can occur when, similar to information disclosure threats, the data store itself is insufficiently protected against unauthorized access or when the access checks can be bypassed. Other threats are related to overcapacity failures.

Concerning the protection scheme: Why is there no protection scheme? Is this by design? Does any code rely on a name, such as a file name, to determine access? If yes, make sure the code looks for only valid names and does not filter out illegal names (canonicalization failure). Also, look at the permissions on all objects to determine whether they offer the correct level of protection.

The monitor can also be bypassed, for example by extra-monitor access (when you can access the data store without following the process governing access), or there might not even be a monitor present. Finally, overcapacity failures can result in a tampering threat. Verify what happens when the data store is full: is data discarded? is data written to the beginning of the data store (wraparound)? is data dropped and not written to the store or does the application crash (other failure mode)?

Process tampering threats include corrupting the process, or providing false credentials to gain access to the process. Also, when a subprocess is tampered with, the entire process itself is corrupted as well. To avoid a corrupted state, one should examine whether all input is verified for correctness. Also, the internal state (memory) should be tamper-proof. Concerning the call chain, it is important that you both trust the code that calls your code and the code that you call.

Elevation of privilege indicates that a misactor can gain access to a process and/or information when he does not have the sufficient access rights. This can occur when an entity (with more privileges than the misactor) is spoofed, en there is an insufficient authorization system caused by cross-domain issues or call-chain issues, when the process is corrupted by means of input validation failure or access to memory.

Unawareness

• how transparent is the service?
• privacy controls user friendly?
• vendor lock-in?
• data erasure possible?
• consents about data policies insufficiently accounted for

Non-compliance

• Disproportionate data collection
• unlawful/disproportionate data processing
• automation in decision making (accounts cancelled without human review)
• disproportionate storage & retention

Mitigation strategies

Privacy techniques

• anonymous credentials
• anonymous payment method
• metadata minimization
• no identity verification
• optional logging opt out
• traffic anonymization allowed (VPN; Tor)
• interoperability or transferability
• deniable storage - safe removal from local storage on demand OR deniable encryption
• clear privacy policy with limit collection and no unnecessary retention (watch out for business models)
• optional opt out of password checks (number of passwords check exposed)

Security parameters

• client-side encryption
• salting and hashing of passwords
• complex credentials allowed
• optional opt in to password checks (number of passwords check exposed)
• Rate limiting implemented on vault access
• optional logging opt in
• all traffic encrypted
• default-deny access controls
• native applications; avoid dynamic web clients
• strong client verification - PGP signed executables or checksum verification
• Encrypted storage for the password database file

Bitwarden

https://bitwarden.com/help/what-encryption-is-used/

SHA-256 is used to derive the encryption key from your master password. Bitwarden salts and hashes your master password with your email address locally, before transmission to our servers. Once a Bitwarden server receives the hashed password, it is salted again with a cryptographically secure random value, hashed again, and stored in our database.

The utilized hash functions are one-way hashes, meaning they cannot be reverse engineered by anyone at Bitwarden to reveal your master password. Even if Bitwarden were to be hacked, there would be no method by which your master password could be obtained.

Bitwarden does not write any cryptographic code. Bitwarden only invokes crypto from popular and reputable crypto libraries that are written and maintained by cryptography experts. The following crypto libraries are used:

• JavaScript (Web Vault, Browser Extension, Desktop, and CLI)
  Web Crypto
  Node.js Crypto
  Forge
• C# (Mobile)
  CommonCrypto (iOS, Apple)
  Javax.Crypto (Android, Oracle)
  BouncyCastle (Android)

https://bitwarden.com/help/vault-data/

Vault data that is encrypted includes, but is not limited to:

• Names of Folders, Collections, Items, & Attachments
• All Login information (including usernames, passwords, URIs, TOTPs, etc.)
• All Card information (including cardholder name, number, brand, expiration, security codes, etc.)
• All Identity information (including names, email, phone, passport numbers, license numbers, SSNs, addresses, etc.)
• All Secure Notes and notes connected to a Login, Card, or Identity
• All Custom Field name/value combinations

https://bitwarden.com/help/bitwarden-security-white-paper/

Bitwarden always encrypts and/or hashes your data on your local device before it is sent to the cloud servers for syncing. The Bitwarden servers are only used for storing and synchronizing encrypted Vault data. It is not possible to get your unencrypted data from the Bitwarden cloud servers. Specifically, Bitwarden uses AES 256-bit encryption as well as PBKDF-SHA256 to secure your data.

All information (Logins, Cards, Identities, Notes) associated with your stored Vault data is protected with end-to-end encryption. Items that you choose to store in your Bitwarden Vault are first stored with an item called a Cipher object. Cipher objects are encrypted with your Generated Symmetric Key, which can only be known by decrypting your protected Symmetric Key using your Stretched Master Key. This encryption and decryption are done entirely on the Bitwarden Client because your Master Password or Stretched Master Key is never stored on or transmitted to Bitwarden servers.

https://bitwarden.com/privacy/

Collection

When you use the Site or communicate with us (e.g. via email) you will provide, and Bitwarden will collect certain Personal Information such as

• Name
• Business name and address
• Business telephone number
• Email address
• IP-address and other online identifiers
• Any customer testimonial you have given us consent to share.
• Information you provide to the Site's Interactive Areas, such as fillable forms or text boxes, training, webinars or event registration.
• Information about the device you are using, comprising the hardware model, operating system and version, unique device identifiers, network information, IP address, and/or Bitwarden Service information when interacting with the Site.
• If you interact with the Bitwarden Community or training, or registered for an exam or event, we may collect biographical information and the content that you share.
• Information gathered via cookies, pixel tags, logs, or other similar technologies.

We use data for analytics and measurement to understand how our the Site and Bitwarden Service are used. For example, we analyze data about your visits to our Site to do things like optimize product design. We use a variety of tools to do this, including Google Analytics. When you visit the Site using Google Analytics, we and Google may link information about your activity from that site with activity from other sites that use Google Analytics services.

Bitwarden may also share your Personal Information with our subsidiaries, affiliates, and partners, to facilitate our global operations and in accordance with applicable laws, and our agreements with customers or service providers.

We may also provide your Personal Information to a third party in connection with a merger or acquisition of Bitwarden

Strictly Necessary cookies such as CloudFlare's cookies help us identify malicious visitors to the Site. They provide necessary security settings or help you use our Site's features and the Bitwarden Services as expected (including remembering your cookie consent preferences).

Google Analytics which tracks user behavior on the Site, which helps us better understand how users are using the Site. Learn more at https://www.google.com/policies/privacy, and to opt out, visit http://tools.google.com/dlpage/gaoptout

Keepass

KeePass database files are encrypted. KeePass encrypts the whole database, i.e. not only your passwords, but also your user names, URLs, notes, etc.

KeePass 2.x:

AlgorithmKey SizeStd. / Ref.Advanced Encryption Standard (AES / Rijndael)256 bitsNIST FIPS 197ChaCha20256 bitsRFC 7539There exist various plugins that provide support for additional encryption algorithms, including but not limited to Twofish, Serpent and GOST.

The block ciphers are used in the Cipher Block Chaining (CBC) block cipher mode. In CBC mode, plaintext patterns are concealed.

SHA-256 is used for compressing the components of the master key (consisting of a master password, a key file, a Windows user account key and/or a key provided by a plugin) to a 256-bit key K.

KeePass features a protection against dictionary and guessing attacks.

For this, the key K derived from the user's master key (see above) is transformed using a key derivation function with a random salt. This prevents a precomputation of keys and adds a work factor that the user can make as large as desired to increase the computational effort of a dictionary or guessing attack.

Multiple key derivation functions are supported. In the database settings dialog, you can select one and specify certain parameters for it.

Supported key derivation functions:

• On Windows Vista and higher, KeePass can use Windows' CNG/BCrypt API for the key transformation, which is about 50% faster than the key transformation code built-in to KeePass.AES-KDF (KeePass 1.x and 2.x):
  This key derivation function is based on iterating AES.In the database settings dialog, you can change the number of iterations. The more iterations, the harder are dictionary and guessing attacks, but also database loading/saving takes more time (linearly).
• Argon2 (KeePass 2.x only):
  Argon2 is the winner of the Password Hashing Competition. The main advantage of Argon2 over AES-KDF is that it provides a better resistance against GPU/ASIC attacks (due to being a memory-hard function).

While KeePass is running, sensitive data is stored encryptedly in the process memory. This means that even if you would dump the KeePass process memory to disk, you could not find any sensitive data. For performance reasons, the process memory protection only applies to sensitive data; sensitive data here includes for instance the master key and entry passwords, but not user names, notes and file attachments. Note that this has nothing to do with the encryption of database files; in database files, all data (including user names, etc.) is encrypted.

Furthermore, KeePass erases all security-critical memory (if possible) when it is not needed anymore, i.e. it overwrites these memory areas before releasing them.

When locking the workspace, KeePass closes the database file and only remembers its path and certain view parameters.

This provides maximum security: unlocking the workspace is as hard as opening the database file the normal way. Also, it prevents data loss (the computer can crash while KeePass is locked, without doing any damage

All security features in KeePass protect against generic threats like keyloggers, clipboard monitors, password control monitors, etc. (and against non-runtime attacks on the database, memory dump analyzers, ...).

Password strength

https://en.wikipedia.org/wiki/Password_strength

According to one study involving half a million users, the average password entropy was estimated at 40.54 bits.[11]

Thus, in one analysis of over 3 million eight-character passwords, the letter "e" was used over 1.5 million times, while the letter "f" was used only 250,000 times. A uniform distribution would have had each character being used about 900,000 times. The most common number used is "1", whereas the most common letters are a, e, o, and r.[12]

Users rarely make full use of larger character sets in forming passwords. For example, hacking results obtained from a MySpace phishing scheme in 2006 revealed 34,000 passwords, of which only 8.3% used mixed case, numbers, and symbols.[13]

If patterned choices are required, humans are likely to use them in predictable ways, such as capitalizing a letter, adding one or two numbers, and a special character. This predictability means that the increase in password strength is minor when compared to random passwords.

If key stretching is not used, passwords with more entropy are needed.