Context: I'm trying to design an SRS solution for your personal secrets - "Anki for passwords." (This is mostly a learning-exercise, to help me develop my intuition for writing secure(-ish?) code, and to explore the problem-space - I don't have high hopes for my own ability to implement this all that effectively …)

In particular, spending some time thinking through the problem, I've decided it's best to focus on the niche not serviced by existing password-managers like 1Password — they're very, very good at what they do, and I don't think I can improve on them!

However, password-managers exist at a very specific position on the 'convenience vs security' spectrum:

  1. They store information in the cloud,
  2. and they store information 'reversibly', i.e. you can get out the plaintext of the secrets that you put in.

My plan is to invert these two, and provide a tool that's specifically oriented towards secrets you don't feel comfortable compromising the above two points on. (For example, let's say you want to keep your e-mail password specifically "in your head only"; and never store it retrievably in the cloud. Or, of course, one of the primary uses for this would be the 'master password' for your password-manager itself …)

So, my question: the baseline way to accomplish the above, would be to locally store a little database of hashes-of-passwords-you've-memorized on a single computer's local filesystem. (Get notified you need to review your memorized password; go to that computer; attempt to enter the password, be told whether you got it right. Easy.)

However, to do better, I felt it'd be really nice to have the secrets stored on an HSM, not on the filesystem - specifically, the kind of HSM that lots of users already have: the consumer ones like a Yubikey or NitroKey. (Failing that, the built-in modern isolated-computing-mechanisms, like Apple's TouchID or the TPM?)

I looked around the documentation a little, but I haven't had much luck finding anything other than OTP- or keypair-style 'you don't get to dictate the specific secrets' options and configurations.

tl;dr: Is there any well-known protocol or method for storing something you dictate on a consumer HSM? Failing that, is there a secure method I'm missing for 'mixing in' the security of the HSM into the filesystem-storage method, such that the filesystem information is worthless without the HSM?

(and, of course, since this is SSE, definitely poke any holes in my overall idea that you can. I'd love the feedback, or any tips.)

I know very little about security (well, I'm a "security nerd", but I don't work in the field; and I recognize how tiny-little I actually know ;_;), but I know enough that threat-modeling is important. For the above question, let's make some assumptions:

  1. Since this isn't a web-app, and only the end-user will be storing their own secrets, I'm not worried about zero-knowledge stuff

  2. I am worried about data stored on the local filesystem, and possibly secrets in RAM: the entire point of this is to sit beside something like 1Password; and one of the only cases where 1Password 'isn't already enough' is someone gaining physical access to your machine while it's unlocked, for instance.

    (or to put that another way - this project isn't interesting/a good learning exercise, if i don't try to store the data securely at-rest ...)

1 Answer 1


Serious answer:

Yubikey supports OpenPGP which supports asymmetric encryption. Standard answer here is to encrypt the database with a symmetric key and then encrypt the symmetric key with asymmetric encryption.

So a password manager could be built in this way using OpenPGP to encrypt/decrypt the database encryption key with any commodity HSM supporting OpenPGP.

With a streaming cipher, one can decrypt the minimum portion of a database. Wipe the key from RAM as soon as it's no longer actively needed. Should minimize exposure.

Now for the fun answer after the serious answer:

I don't think most of these commodity HSMs want to store Hashes, there's not really a solid reason to put a hash in an HSM. So I don't think there's a standard way to do this.

BUT, it does store Hash sized things. Luckily, ECC keys are often Hash sized. Even better, private ECC keys are just random numbers and hashes are statistically random.

SO, hash a password, store it in an ECC key slot. When the user is to verify their password, hash their entry, use the hash as the private key and derive the public key. Sign something with the yubikey and see if the public derived from the user input validates it correctly. If it does, the user must have entered the right password.

I've never seen this done anywhere so take it with healthy skepticism. It also requires a key slot for every password hash memorized. Not sure how many slots Yubikeys have but Purism and Nitrokey both have fewer than 5 slots on affordable models.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .