Personal Password Peppering/Secret Salting

A pepper or secret salt in cryptographic terms means “a secret added to an input such as a password during hashing with a cryptographic function” that is not stored with the hash itself.

Phani Karen wrote an article recently advocating using this method (which he refers to as “double-blind” and “horcruxing” for some reason) to increase the security of passwords stored in a password manager.

Karen’s recommendation goes something like this.

  1. Select an arbitrary (ideally random) short word or phrase. Let’s use kraken, for example.
  2. When you set up a password on an account, the password takes the form of passwordkraken (where password is a randomly generated password or passphrase).
  3. In your password manager, you only store password.
  4. So when you revisit the site, you copy password and then manually append -kraken

The claimed advantage of doing this is that if your password manager is ever compromised, your accounts are still safe unless someone is able to guess the -kraken password stem that is not stored in the password manager.

Karan refers to this as implementing a defense in depth approach, where multiple security layers are used to mitigate damage.

I would not recommend this approach for a number of reasons.

First, it increases the pieces of information you need to know to use your password manager. Currently, I need to know my username and password to access my accounts using Bitwarden. A system like this adds a third piece of information I need to memorize.

Maybe for the intended audience, that’s not a big deal, but given how many people struggle to understand and use a password manager in the first place, anything that adds more friction to that process is to be avoided.

Second, this is exacerbated by the fact that it would likely prove difficult to keep the secret salt secret for very long.

Currently, I have about 300 accounts stored in Bitwarden, all with unique passwords. Suppose I had been adding a secret salt to my passwords for the last 5 years. In that time, about 6 of the accounts that I have were part of public breaches.

I quickly changed those passwords once I was aware of the breach. Still, if I had been using a secret salt, anyone who breached my Bitwarden account would easily be able to go back and find one of those outdated, unused passwords and quickly see a secret salt pattern in there.

The only way to guarantee my secret salt stayed secret would be to change that salt every time I was aware of a public breach, which would mean updating hundreds of uncompromised accounts, which turns my password system’s complexity up to 11.


DiceKeys reminds me a lot of Diceware. The user gets a set of special dice, in this case, which they roll into a box.


The user then closes the box, preserving their DiceKeys pattern indefinitely. The result of the dice roll is then used to seed a hash algorithm that, in turn, generates application-specific passwords and even U2F tokens.


DiceKeys also comes with an app that can assemble the master password automatically by scanning the dice (including their orientation, which the app uses to generate further entropy), and the QR code-like symbols on the top and bottom of the dice.

DiceKeys are backup security keys with 196 bits of security made of 25 custom dice and a rugged holder, built to last a lifetime. . . . As password managers add support for DiceKeys, you’ll also be able to use your DiceKey in place of a `master’ password. . . .

Use the open source DiceKeys app to quickly read your DiceKey from a device. Our API allows apps and services to derive their own private secrets from your DiceKey without those apps seeing the key itself.

Our reference implementation runs in most modern web browsers, allowing it to work on an incredibly diverse range of devices. While built with web-based technologies (TypeScript & WebAssembly), it runs entirely locally on your device.

We are also developing Android and iOS versions to provide a richer experience on those devices.

The cost for a set of DiceKeys looks to run about US$25.

Enpass Password Manager

The other day I saw a thread where people were debating the best password manager, and someone mentioned they had switched to Enpass.

Enpass looks like a closed source Keypass style solution. All data is always stored locally on devices, and then merely synced to devices using services such as Dropbox, Nextcloud, or whatever the customer prefers to use. As Enpass titled once of its blog posts about the service, Enpass servers never interact with user data in any way.

The pricing model is also attractive. Enpass is free except for mobile devices. Using Enpass on a mobile device costs $11.99 to $23.99/year (looks like they are doing a 50% off the first year, then full price the next). There is also an option for a one-time lifetime purchase for $55.99.

I’m sticking with Bitwarden as I like the idea of being able to self-host my password management solution if I wanted to. It is good, though, to see people have more options.

LostPass Phishing Attack Against LastPass

Every few months, someone comes out with a clever attack on LastPass. In January, for example, Sean Cassidy released his LostPass phishing attack that “allows an attacker to steal a LastPass user’s email, password, and even two-factor auth code, giving full access to all passwords and documents stored in LastPass.”

LostPass is a clever phishing attack. Essentially an attacker creates a fake notice that a user’s LastPass session has expired and asks them to log in. The fake version is visually identical to the actual notice LastPass uses, and even technical users would be unable to distinguish between the real notice and a phishing attempt.

LastPass responded by removing the button in its session expiration notices (so users will, presumably, be able to better distinguish fake versions which would need to have some sort of “login” button). LastPass also now requires users to go through an email-based process to approve logins from any previously unknown device or IP address.

LastPass also points the finger at Google, saying it identified these sorts of problems with the way Chrome displays notifications, but that its complaints fell on deaf ears,

A point that was only briefly raised in Cassidy’s research was the role that the browser itself plays in this attack. LastPass has encouraged Google for years to provide a way to avoid using the browser viewport for notifications. As a true solution to this threat, Google should release infobars in Chrome that give extensions the capability to do proper notifications outside the DOM. You can see our plea for this back in January 2012 with still no resolution; please star this issue to help us raise awareness.

It is good that people like Cassidy are out there looking for ways to get around LastPass’ security, and also good that LastPass generally responds to these sort of attacks much more quickly and effectively than a lot of companies. Every time a vulnerability in LastPass is found, people I know ask me whether they should still use LastPass, and my answer so far has always been “yes.”

So far the vulnerabilities that have been found in LastPass are of the sort that I still feel far more secure using it to manage my passwords than using some other password manager or (even worse) some other method for creating and managing the passwords to the dozens of services I have credentials for.

Web-Based Password Managers

I mentioned the open source KeePass password manager the other day, but apparently there are a number of web-based password managers, including PassPack,and Clipperz. Clipperz also has an open source version of its software that you can download and then install on your own server.

I still think it’s easier and probably more secure just to use KeePass and keep the master password database on an FTP server so you can access it anywhere. Put the URL in your browser and KeePad will load it.