The modern web is a major pain to use without a password manager app. However, using such a service requires you to entrust your precious secrets to a third party. They could also be compromised, then you really are in trouble. You could manage passwords with local software or even a notebook, but that adds cognitive load. You could use the same password across multiple sites to reduce the load, but that would be unwise. Now, however, with the HIPPO system, there is another way.
HIPPO is implemented as a browser extension paired with a central server. The idea is not to store any password anywhere, but to compute them on the fly from a set of secrets. One secret at the server end, and one the user supplies as a passphrase. This works via an oblivious pseudorandom function (OPRF) protocol. Details from the linked site are sparse, but we think we’ve figured it out from other sources.
First, the user-supplied master password is hashed with the site identifier (i.e., the domain), blinded with a random number, and then processed using an OPRF, likely built on an elliptic-curve cryptographic scheme. This ensures the server never receives the raw password. Next, the server applies its own secret key via a Pseudorandom Function (PRF) and sends it back to the client. Obviously, its private key is also never sent raw. Next, the client removes the blinding factor (using the same random number it used when sending) from the original key, producing a site-specific high-entropy secret value that the extension passes to a Key Derivation Function (KDF), which formats it into a suitable form for use as a password. Finally, the extension auto-fills the password into the website form, ready to send to the site you want to access. This password is still unique per site and deterministic, which is how this whole scheme can replace a password database. Neat stuff!
This advantage to this whole scheme means there’s no vault to compromise, no storage requirements, and it generates a strong password for each unique site, meaning no password reuse and a low chance of brute-force cracking. The obvious flaw is that it creates a single point of failure (the HIPPO service) and shifts the risk of compromise from vault cracking the master password, infiltrating the server, or compromising its secret key. It’s an interesting idea for sure, but it doesn’t directly manage 2FA, which is a layer you’d want adding on top to ensure adequate security overall, and of course, it’s not a real, live service yet, but when (or if) it becomes one, we’ll be sure to report back.
Confused by all this? Why not dig into this article first? Or maybe you fancy a DIYable hardware solution?
