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?
I haven’t had enough coffee yet to truly wrap my head around this, but unless I’m mistaken this creates a fixed, unchangeable password per site. If the site gets a leak and the password gets compromised (which happens several times a month these days), this system is unable to do anything about it. In addition it means that changing your master password will involve invalidating every password in the system.
This makes it unsuitable for general use on the current internet.
It’s exactly like making a password as: echo “myownpassword+hackaday.com” | sha256sum and using that as the password for the site. All of the crypto mumbling serves nothing except trying to drown the fish. The “central server” is just a random generator, and is completely useless burden. So yeah, better than “passwordhackaday” but not much.
Or use a password manager that runs locally. KeePass comes to mind, but there are others that run strictly locally and don’t send your secrets anywhere.
I don’t mean this at a diss of Hippo; more at a protest against lazy assumptions like ‘password managers all run in the cloud!’
Also seems like there’d be a problem if there was any change in the domain name (the chosen “site identifier”), as the resulting password would be different.
I don’t get why one needs a server to do that. Apps like Master Password/Spectre have existed for years running locally without need of a third party
i dont trust any password solution that requires a cloud service. the more stuff you put on the internet the more security you need.
The drawback of having to reset everything if/when you change your master does feel like the nail in the coffin for this, but maybe there are workarounds. Either way, I’m sick of logging into stuff, sick of password managers, and sick of OAuth being the way around it giving Google knowledge of all the things I use.
I have options to recommend, but by your phrasing I assume that you’ll just say you’re sick of them, too. Especially if “logging into stuff” is the first thing off the table.
I’ve actually done some of the work and research around the solutions here, and might even be partly responsible for one or more of the things you’re already sick of.
There’s a balance between making it simple enough to prove your identity while also difficult enough so that others can’t impersonate you. Especially if you object to tying your online identity too tightly to anything, including trusted parties, personal knowledge, or physical keys. Like, if you object to literally everything then you’re not leaving me anything to work with.
There are even technical solutions that solve the problem mathematically and categorically, but then you run face-first into the human problem with “someone stole my key” or “I forgot my unlock code” or whatever. Which means you HAVE TO design some backdoor into the mathematically pristine solution otherwise it’s real-life unusable by normal people.
It’s like, FFS there always has to be a compromise made because humans are humans and can’t accept any solution categorically. So then like, if you refuse to pick your poison then at least be willing to mix your own. Right? Right??? Am I the crazy one here?
Interesting idea, but how does one deal with archaic sites that have character restrictions on either length or forbidden chars? Those sites are excruciating even with a fully customizeable password generator.
You’d also needed to manage some per-site seed input to rotate passwords because unique per domain would give you exactly 1 password and no changes.
Love the split-secret storage model idea, but feels like deterministic passwords could be very limiting in the real world where too many sites still employ garbage password rules.
I’m surprised most people don’t use the method my son suggested to me for keeping passwords: A mental algorithm that seems random but can be easily recreated from memory.
It’s very simple. You develop an algorithm that you can do in your head that incorporates the site’s name and some other info. This technique generates a unique password for each site, but you don’t have to remember the password; just remember the method you used to to create the password. As a bonus, the generated password can be lengthy and have seemingly random letters and numbers. The only drawback is you still have to manually enter a bunch of otherwise random characters when you enter your password.
When developing your own personal algorithm, you can use song lyrics, bible verses, sports team names, or anything that you are likely to remember. I started doing this several years ago, and I rarely have a problem logging on to rarely used sites now.
So, for example: Here’s an algorithm based on the the song “Lucy in the sky with diamonds” and Babe Ruth’s lifetime batting average. But I replace the word “sky” with 3 capital letters from the site’s name. So my password on Hack-a-Day is “LitHACwd.342”
Oh, I once met someone with a strong password and for each site and individual annex. The password of one site was pwnd. So all other passwords needed to be replaced, fast. Your idea is merely slightly different from that. So, a bad idea.
And to complete it: the obligatory xkcd: https://xkcd.com/936/
That’s not an algorithm.
It’s just a fixed universal password (constructed however you like) plus a site/service specific addition somewhere in there.
It’s quite common. I read about it probably >10 years ago in a computer magazine.
some variants, like placing the site specific addition “dynamically” (position derived from the addition) may be called an algorithm but to me that’s a stretch.
IT IS an algorithm….
This, and by the looks of it the hippo discussed in the article, fall down when a site demands different special characters, or demands you change your password (every 6m, or due to them having a hack, etc).
Yeah that gets in the way of all my attempts to have reasonable passwords. I pick the password i want and then append 1!A to it until it’s accepted.
what happened when website is number?
cool… and then a year later, you visit that site again, it asks you to enter a new password for security reasons, so you just add !1 to the end. But then “algorithm” is no longer the same and remembering becomes a bit more complicated. So you’ll go for the “always works” solution, you write it down and stick the note under your keyboard or monitor. Security… chances that somebody hacks the server of the website are most likely larger than the chance that somebody breaks into your apartment searching for password notes under the keyboard.
PS: as a security feature, I collect typewriters and keyboards, so guess under which keyboard I stuck the note.
Correct horse battery staple
If you don’t know the reference, it’ll be the first hit on any search. If you see a stick-figure comic image from xkcd, then you’ve hit the right place.
His point being that shortening the passphrase to just the first letters is counterproductive. Just type the whole thing out.
Randall is a stickler for math, and when calculating password entropy he even took into account the idea that his technique would be subject to dictionary attacks if it became popular. So his estimate on password strength already takes into account the best possible way to attack it.
So, we’re back to one password for everything? I think I know where this is going…
3rd party browser extension connected to the server is already red flag. May be harmless during install, but who knows what next update can do.
A browser plugin is great… for the desktop.
I’ve been using Keepass for a few years. Specifically KeepassXC on the desktop and “Keepass2Android Password Safe” on my phone. I have them syncing to a database file on my own server.
The phone has been a constant PITA. When it works it is great! If you have recently (within some configurable number of minutes) logged into the password app then whenever you get to a password screen it just pops the login info in for you. If you haven’t used it in a while then it makes you type the last 3 digits of your login app password or if it has been even longer then the whole thing.
But it rarely works anymore. I don’t think it’s the app or it’s author’s fault. Every time Google or Samsung pushes an update I think they make it harder for 3rd party password managers to do their job. And so I am always having to switch keyboards and manually search the db for the right entry then hit the username and password buttons.. or in some apps I can’t even do that and have to copy/paste from the keepass app.
Google or Samsung… I think they really want me to use THEIR password manager. The more they want me to the more I don’t want that. What exactly do they want my passwords for so badly?!?
Now, back at the desktop I am getting messages from my package manager that KeepassXC is about to get dropped because it is stuck on QT5. Seriously?!? There is another Keepass program for the desktop, Just Keepass without the XC. But its integration is a lot clunkier. Much of the functionality is in plugins that you have to go find, download and drop into a folder to use and then manage updates yourself. And it kind of looks like something from the Windows 3.1 days. I guess I will have to download the KeepassXC app image.. and manually update it.
Well, anyway.. I am not sure the idea presented here is secure enough. But even if it is… I’m sure if it takes off it will hit all of the same resistance. It’s so sad that we cannot have nice things.
Try keepassdx because it’s more actively maintained. Your app of choice was last updated on 26th of November 2025.
It certainly looks nice but it says it’s only for a “local” db. I use 2 desktops and a phone and it’s not odd for me to add entries from more than one of them in the same day. I’m not sinking that thing by hand. I also don’t want to use Google Drive, Dropbox or anything like that because that would totally defeat the purpose of not just going with an easy to use “normal” cloud based app.
Do you really think 6 months without updates is a long time for a “finished” program to go without updates?
Syncthing would be another option. No cloud storage at all, just direct sync between devices.
I do the same thing with Keepass. I also use a key file that is on my phone and on my desktop but not on my server. I would never trust any file manager that is attached to the browser. Note: KeepassXC is available as a flatpak so even if it is not available in your software manager it is available from flathub. I am assuming you are running Linux.
I don’t really buy the premise that it’s hard to live without a password manager integrated into the browser. I do have a password manager of sorts that i manage manually…but for the browser itself, for everything except my bank, i login once and then use cookies. Cookies, man.
Creates a readily targeted single point of failure.
Denying someone access is almost equivalent to taking control of their account under the right circumstances. Often used for random attacks for instance.
I wish people would stop professing once and for all solutions that just shift the problem around.
So instead of unique passwords for every website, HIPPO would use one master password to generate the same site specific password every time so you don’t have to “save them” based on its algorithm. This would mean if someone was on your PC between the time the master password was entered and the timeout period (assuming there is local caching or a timeout period), or if they knew your master password, they could get into every single one your websites Also a master password with no encryption key or salt equivalent would open this to brute forcing if a malicious user knew you used HIPPO….I’ll stay with 1Password thanks.
this is wrong. in fact HIPPO – which is probably based on the SPHINX protocol (they share a co-author) – is in fact resistant to offline bruteforce attacks! that means every guess you make must be used as a query to a host that validates the password, so no GPU/ASIC bruteforcing.
this applies to all password managers. btw with OPRF-based ones, you don’t need to have only one master password, you can have like 2-3 for various security levels, and some extra for distress or self-destruct passwords.
I use a password manager, but if you get into it, to you it’s gibberish. The usernames and sites have no meaning to anyone but me. Consider doing that if you use any type of password keeper. Even handwritten.
Interesting idea, that also breaks when sites decide to change from xitter.com to y.com, or the authentication portal from login.example.com to auth.example.com.
Eventually I found it was faster/easier to just click on “forgot my password”, get an email, create a new system generated one and log in.
Except sometimes the email doesn’t arrive until after the password change times out. Round and round you go.
No Browser extensions, just offline KeepassXC with handtuned auto-fill command per site. Works the same regardless of device, browser, operating system, terminal, etc.
And all passwords auto-generated from characters or wordlists.
Your password will expire in 3 days…
there is an easy (but on the client-side stateful) solution to this, just add a counter to the input password and the hostname, if you wanna change your output password, just increment the counter.
another solution is to have different – per-account – keys on the server and just randomly regenerate them when an (output) password update is necessary, this latter is how pwdsphinx does it (pwdsphinx is an advanced implementation of te SPHINX protocol, which is the basis of the HIPPO tool, it is very mature and in most debian derivates, arch and nix)
Yeah, the tool is a neat idea with really obvious and significant flaws, but HaD’s illustration makes up for it.
“Are you interested in cootys rat semen?”
“I’m interested in all kinds of semen.”
[whispered] “True!”
Yawn. I just use keypassx on my Linux systems. The KISS principle at work. Of course backups (local)of the database is a must. Phone is for talking/texting. So no need for passwords there. All good and not complicated.
i have good news, a very mature and better variant of this is based on the SPHINX protocol by Krawczyk et al, and it addresses all the issues raised in these comments so far. Krawczyk is the guy who gave us among others HMACs, HKDFs and other most widely used cryptographic primitives (and also the OPRF construction shared by SPHINX and HIPPO). sphinx is in most debian derivates, in arch, and in nix, and it is in production for almost a decade now, check out https://sphinx.pm/ – it is command line first, but there is a web extension, and and android app.
also check out my blog for explanations of how an OPRF and how SPHINX works, even some videos on youtube if you care to look for them.
This is not a new idea, Krawczyk et al described this long ago, they called it SPHINX. Krawczyk is a recipient of the Real World Crypto Levchin award, he has provided us with a lot of most widely used crypto primitives like HMAC and HKDF. https://en.wikipedia.org/wiki/Hugo_Krawczyk
I implemented SPHINX back then, it is very mature and easily addresses most issues raised in the comments above. and unlike hippo SPHINX is implemented as a threshold-OPRF eliminating the single-point-of failure. SPHINX is CLI first, but there is a webextension and an android app. It is very mature and in production since almost a decade now, you can self-host your own server(s) if you want. sphinx is debian derivates, in arch, and in nix. check it out at https://sphinx.pm/
on my blog write extensively about OPRFs and other uses of them.
Thank you for the hint, looks great for general passwords. Server looks easy enough to use as a local python install.
What it does not solve at all is management of many other very relevant pieces of security information due to the 64 bytes limit: ssh keys, certificates, expiry dates, recovery phrases and so on.
Personally I will stick with having multiple kdbx databases.
except for the ssh keys (which are supported) it is true, but that is also the point, it is a more strict variant of the KISS principle and also intentional to reduce attack surface. and some of the security properties also enforce this limitation.
If it is too simple to work, it is not simple anymore but insufficient.. ;-)
I get it, you believe in sphynx, but for me it would be too rudimentary. Passwords are meant to be rotated but some account metadata has to be kept around for the whole lifecycle of an account. Running two separate systems is okay for master keys but the bulk of logins can not justify the overhead.
Schneier’s Law: anybody can create a cryptography system that they themselves can’t break.
If passwords are computed from an algorithm, and a bad actor obtains one or more of your passwords, how difficult is it to calculate the rest of your passwords?
the good news is, this is designed by one of the most competent cryptographers of our time, Hugo Krawczyk, back in 2015 he and his described the SPHINX protocol that seems to be the basis for the HIPPO system (if you read the linked article you see a co-author mentioned: Nitesh Saxena) who was a co-author of the paper with Krawczyk. Krawczyk has given us most widely used protocols and primitives like TLS1.2, HMAC and HKDF among others, these are used daily by anyone using the internet…. Krawczyk received the Levchin life-time Real World Crypto award back. There is basically noone more competent to design such a system, and defy the Schneier principle
This is not a new idea, Krawczyk et al described this long ago, they called it SPHINX. Krawczyk is a recipient of the Real World Crypto Levchin award, he has provided us with a lot of most widely used crypto primitives like HMAC and HKDF. https://en.wikipedia.org/wiki/Hugo_Krawczyk
I implemented SPHINX back then, it is very mature and easily addresses most issues raised in the comments above. and unlike hippo SPHINX is implemented as a threshold-OPRF eliminating the single-point-of failure. SPHINX is CLI first, but there is a webextension and an android app. It is very mature and in production since almost a decade now, you can self-host your own server(s) if you want. pwdsphinx is debian derivates, in arch, and in nix.
on my blog write extensively about OPRFs and other uses of them.
Sooo, “they” failed to create a mind reader and now “they” bait us with mind numnums to share our passwords? Haven’t “they” read the proper xkcd strip for this case? Sure, whaking milions with wrenches could take some time … I keep my password on a piece of paper under my keyboard. The piano keyboard, don’t smash it, you can lift it easily. You’ll find out that all this post is my pasword. Including spaces. And mitsakes.
Don’t trust LastPass or Bitwarden? There’s now a self-hosted open source Bitwarden server alternative that’s compatible with all the usual Bitwarden clients and add-ons: Vaultwarden.