Double Blind Passwords a.k.a. Horcruxing | Hacker News Reader

Double Blind Passwords a.k.a. Horcruxing

kaizoku.dev

336 pointsastroanax181 comments

This is a cool/useful idea.

I thought the article was gonna be about "Shamir's Secret Sharing" [1], "where a secret is divided into parts, giving each participant its own unique part. To reconstruct the original secret, a minimum number of parts is required.". Sounds horcruxy to me :-p. I learnt about it from the PIM book [2].

1: https://en.wikipedia.org/wiki/Shamir%27s_Secret_Sharing

2: https://pimbook.org/

I thought that algorithm was crazy magic when I first heard of it.

The method behind it is pretty fascinating.

A nth degree polynomial is uniquely identified by n+1 points.

So the algorithm interprets your secret to a binary numeric value, sets that as the value at x=0 (i.e. the constant term of the polynomial), picks random coefficients for all the polynomial degrees, then computes coordinate pairs for however many shards you need the secret split into.

Then you give one of the shards to anyone who is sharing the secret.

When enough of the points are input at the same time, the x=0 value can be calculated and the secret is revealed.

The really neat thing about that is if you have something like "There are 500 people in the organization and 6 of them need to be present to perform this procedure", you generate 500 unique points, and any six of those points will let you compute the original secret.

There is some added math bit that gets added on top to make the polynomial less easy to guess, but the concept remains the same.

When the method finally clicked for me, I was left feeling like "that is so obvious, anyone could come up with it", and I feel like those are some of the best discoveries.

Your description made it click for me too! Thank you!

"Cool value" often makes for poor security however. The same kind of excitement you felt goes on to cause people to homebrew insecure versions or inappropriately deploy Shamir's Secret Sharing.

https://en.bitcoin.it/wiki/Shamir_Secret_Snakeoil

There is some added math bit that gets added on top to make the polynomial less easy to guess, but the concept remains the same.

The added math bit is that you calculate the polynomials modulo some prime number.

That means that you're doing integer arithmetic, but with even one missing point you've gained no information about the secret. (As long as your points were actually generated with good randomness that is...)

While it's a clever method, it's also worth noting that for moderately-sized groups you can achieve the same thing with a much simpler method and almost no math.

Let's say you have a 256 bit key as the secret, and you want any 5 out of 15 people to have access.

For each combination of 5 people, pick 4 random 256 bit numbers. 4 people get those and 1 gets the key encrypted with those numbers as a one time pad.

Once you do every combination, each person will end up with a list of a thousand numbers. Any 5 of them can get together, each grab their number for that group, and XOR them to access the secret.

That's only 32KB of data to hang onto. With 15 people the absolute max is 107KB. Even printed as plain text it would need less than 20 sheets of paper.

What happens if 5 people who have encrypted random numbers (and no key) get together?

What's an "encrypted random number"?

If they have 5 random numbers and XOR them together, then they won't get the key as output.

So then it's not "any" 5 out of 15, it's "any group of these three", which is a significant disadvantage compared to SSS.

No, it's any 5 of the 15. You do the procedure for each of the 15c5 = 3003 groups of 5.

Each person is part of 1001 groups and has a separate 256-bit number for each group. To recombine the numbers, each of the 5 needs to select the number corresponding to that group.

I think this works just as well as SSS for small/moderate sized groups. It's a little less elegant because you need to know which group you're participating in at decode-time, and because it's not scalable (but there are few serious applications that need the scalability).

Oh that's great. At one point I wanted to use SSS just for two out of three. I can't believe it never occurred to me to just say "if you're pairing with Jack, xor his number with this one." It's even simple enough to do by hand.

The real magic is that even if you can bribe 5 people and discover their point, you don't gain any information: there is an infinite number of degree-6 polynomials that go through 5 points, so you don't know which polynomial is the correct one. With this method it's either "you have it" or "you don't", there's no step in between.

That was my initial thought as well. I wrote about how to use Shamir's Secret Sharing (with a similar Horcrux analogy) to reset master passwords for end-to-end encrypted applications (such as password managers):

https://francoisbest.com/posts/2020/password-reset-for-e2ee-...

Damn good stuff!

Is this related to that one algorithm where 3 people can find out who makes the most money without any of them knowing what the other makes, and without consulting a 4th person? That one always felt like black magic to me.

I believe you're thinking of Yao's Millionaires' problem [0].

[0] https://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_proble...

The main implementation is called horcrux.

https://github.com/jesseduffield/horcrux

This is basically a low tech (and much more unsecure) version of the n=2 case.

Shameless plug: I've been working on this utility to facilitate sharding keys/passwords so you can set up your own password recovery schemes:

https://github.com/xkortex/passcrux

It's more horcrux-y than TFA in that you need N of M shards to reconstruct. TFA isn't really a horcrux, since there's a 100% dependency on each part of the full password.

Canon doesn't specify how many horcruxes he needs to be reanimated, but we know there is some redundancy due to the loss of the diary.

I saw this post a while ago in a different forum. My note for it hasn't changed: This is called peppering[0]. It's a counterpart to salting, in that you add a random value to a password to make it harder to reverse the password hash, but unlike the salt, it's not stored in the password database.

0: https://en.wikipedia.org/wiki/Pepper_(cryptography)

I think the term "peppering" is mostly used for server side manipulation of the password, which the user is unaware of.

It would be very confusing to reuse this term for what is described in this article, so a new term like "Horcruxing" can be relevant. I like it.

I think I really disagree with you there. This is the same concept but applied client-side instead of server-side.

But “client-side peppering” won’t get you to the front page of HN..

I would click “client-side peppering” over horxsomething, didn't read Harry Potter

Horcruxes are similar to what emmanueloga_ has mentioned. Horcruxes were special things in which Harry Potter's lead antagonist, Voldemort stored parts of his 'soul', so that even if he died, someone cpuld revive him using the horcruxes. I haven't kept up with Harry Potter for a year now, so I might be wrong with respect to the exact definition.

A horcrux is a plot device where the protagonists need 2fa to send a HUP or TERM to the misbehaving process.

> A horcrux is a plot device where the protagonists need 2fa to send a HUP or TERM to the misbehaving process.

Okay, I didn't literally LOL, but you did earn a really big grin and even a chortle. Well done.

BTW, I would totally read "Harry Potter and the Protocols of Security". Some of the "Methods of Rationality" fan fiction by Eliezer Yudkowsky nods in that direction (eg. the Death Eaters' opsec).

I've heard good things about "Methods of Rationality". Worth reading?

Definitely, even without the original.

I think so, particularly if you've read Rowling's books and were annoyed by many of the protagonists and supporting characters for a variety of reasons.

If nothing else, "Methods" succeeds in giving agency to more characters, including the villains (not necessarily to their, or Harry's, benefit), and explores/tests the "system" of magic in more depth.

>> and explores/tests the "system" of magic in more depth.

I particularly liked the section where Harry is trying to find out how magic "works". He starts with the gross physicalities: the materials the wands are made of, the sounds of the recited spells. He ends up with the mathematics underlying physics, learning how to create new spells. He uses his new found knowledge to create a very powerful weapon spell he uses to kill a mountain troll. If you want to know how the spell works, you'll have to read the book. I highly recommend it. (I've read it more than once.)

I liked the exposure of the DWIMian (rather than strictly Newtonian) physics of flying broomsticks, although it should be noted that the DWIMian behavior is based on the physics of low-speed high-friction ground transportation rather than a sourceless 'intuition' the author blames.

Agreed. A common reason for shared terminology in computing is to encourage re-use of techniques, this is a great example of that

I think these concepts are significantly different - as different as salts and peppers at least. Peppering helps protect against database access revealing password. Horcrux protects against password manager access. Peppering is stored on the server, but outside the database. Horcruxes are stored in the user's head. You could do both, one, or neither. Client-side peppering would be having part of your password outside of the password manager but still on your computer. If anything it's brain-side peppering.

> Peppering helps protect against database access revealing password. Horcrux protects against password manager access.

What is a password manager but a database of your passwords? Peppering is a token that is not in the database of passwords that needs to be applied for the password to be correct. Whether it's applied by an application, or a person doesn't seem relevant, as what is an application but a set of instructions a person could do carried out automatically?

I don't care what it's called, but I don't really see a difference in the scenarios you've outlined.

> Peppering is a token that is not in the database of passwords that needs to be applied for the password to be correct.

Well, typically a server only cares about verifying the user (still) knows a password.

A typical server (today) does not have a way to reconstruct the plain password, only a way to check if any given string matches.

A password manager, typically does have a way to supply the password.

Peppers and salts are typically manipulated by the server system, plain passwords are typically managed by the password manager.

In this case the password manager never sees the hocrux, and cannot leak it. A server will typically leak a pepper to anyone with access to ram (or access to a hw enclave, which is expected to be more difficult).

Frankly this has more in common with a 2FA approach with one factor being the password manager and the other your horcrux. I wouldn't call my phone authenticator app a client-side pepper.

I fear it may be unfair to expect most end-users to apply this scheme appropriately and consistently, and therefore recommend that it be known as mustard.

I was thinking currying, as it is both spice-themed and analogous to function currying in that you take your base password, curry it with the secret to get the submitted password.

This is very different from peppering. Salt/pepper is all about server storage/verification. The "path" is plain, hash, salted hash, peppered hash.

Plain:server stores the password, client sends the password - matching is simple. When server is breached, all passwords are known.

Hash:server stores a hash of the password, the type of hash. Client sends the plain password, server hashes and compares. When server is breached, most passwords are known, by way of rainbowtables/brute force.

Salted hash: same as hash, servers additionally stores random salt pr account. Hash is over plain password and hash. When server is compromised, weak/dictionary passwords are compromised via brute force.

Pepered passwords: an additional secret is used for salting. The stored hash now depends on plaintext password, plain salt, "secret" pepper. When server is compromised, most likely pepper is compromised too. If not (eg: only database/backups are exposed), pepper needs to be recovered before brute force of passwords is viable. If the attacker has an account (know a password) it's straightforward to attempt to brute force the pepper, but unless it's weak (eg not a 128 bit random number) - it should not be feasible.

Finally, horcruxing - has nothing to do with server side. Has nothing to do with hashing. Is a simple suffix appended to any given password stored in a password manager, in a INMHO misguided attempt at improved security.

Server sees full password on account creation and login. Seems to suggested to share "horcqrux" cross accounts.

An attacker compromising the passwords stored in the password manager, only gets ~half the password. Need to get the other half via brute force, through compromising another account sharing the same suffix/horcrux, via keyboard logger etc.

A physical compromise of a device with a password manager seem to likely open up for a lot of these attacks.

Note that bitwarden uses 2fa to authenticate a client - but AFAIK if you have a copy of the data/vault - the passphrase is sufficient to get the decryption key.

Horcruxing defends against some odd threats, and otherwise adds more complexity than security IMNHO.

If there's generic malware that's targeting your password manager, then yes this provides protection against that. But it doesn't provide protection against a targeted attack, because the malware can just keylog your horcrux.

Another weakness that doesn't require a keylogger, is the attacker might be able to find some stolen database of a website that stored passwords in plaintext, then deduce your horcrux from the difference between what was in your password manager and what was in the database. And if the site did hash passwords, the attacker can try cracking the horcrux. The 5-character example horcrux probably wouldn't be too hard. The article somewhat covers this by saying only use the horcrux on important sites. This is good, but it still has weaknesses because an important site can still get its database stolen, and some people also want to protect less important sites.

And if no password databases are available, the attacker can create a website and ask you to join it under the hope you'll reuse your horcrux on the attacker's site. I've actually had an attacker contact me personally (that is, actually chatting with me live) and ask me to sign up for his forum under the hope that I would reuse my valuable account's password on the forum.

> I've actually had an attacker contact me personally (that is, actually chatting with me live) and ask me to sign up for his forum under the hope that I would reuse my valuable account's password on the forum.

How did you eventually find out their true motivation?

I had one of the most valuable accounts in a video game, so attackers of all kinds were constantly contacting me. I was immediately suspicious of anyone who contacted me. I signed up for the forum with a password from my password manager (I like toying with attackers). I told him I signed up, and a few minutes later he said there was a problem with my account and asked if I used a password manager. I said yes. He said to sign up without it because the site doesn't support it. I tried arguing with him that that makes no sense. But arguing with someone who's lying and refuses to admit it is generally not productive, and the argument got nowhere.

His idea to make me sign up without a password manager was illogical anyways. If I use a password manager on his site, it should be obvious I use a password manager for my video game account, so me halting my password manager usage for his site wouldn't help him get my video game account.

All security eventually relies on obscurity, it's a bad idea to disclose your security practices. Use hunter2 as password for junk sites.

Can you elaborate on why all security will eventually rely on obscurity?

It's jokingly called Fleming's cryptanalysis: if there's a secret key, you just send James Bond to steal it.

https://xkcd.com/538/

The only type of obscurity that would protect me against that type of attack is if I myself am entirely obscure. By having one the most valuable accounts in a video game, I've already given up on that.

By that same logic, use disposable email addresses and the password doesn’t matter? I mean, this kind of thing only holds up while you don’t care to enter any data about yourself and re-visit the site later. Those who need to be anonymous can provide junk info to junk sites, sure, but for everything else, there’s email and 2FA TOTP codes and password managers for a reason... largely because OAuth and FIDO2 aren’t universal yet I suppose ;-)

From a humor point of view that would be a good idea, something like "dontbothertryingtostealmyaccount".

I also agree somewhat about obscurity. Notice that I haven't said what password manager I use, or where I store it. The fact that I use a password manager I don't consider sensitive though.

Oh, my... I can imagine quite a few obscene and anatomically impossible pass phrases that would be generated for that forum. However, I supposed you would still give up some knowledge/deniability in that case.

>And if no password databases are available, the attacker can create a website and ask you to join it under the hope you'll reuse your horcrux on the attacker's site.

Some sites email your password to you: https://plaintextoffenders.com/

It's sad to think that the list of 5801 sites probably only accounts for a couple percent of the total amount of offenders.

With two important notes:

1) A site that emails you your password might not be storing it in plain text. They're similar but separate problems.

2) A site that sends you a login link could be just as bad as the sites listed here, if that login link doesn't expire (and you used a unique password). It's a more subtle way of having the same problem.

Honest question: If you send it on the email without storing (just sending appending the $password variable to the email body), what would be the problem?

Some email is still sent unencrypted over the web so people snooping on traffic could see it.

Not hypothetical https://plaintextoffenders.com/post/628974096028434433/movis...

Any mail server the email happens to pass through is able to read/log the entire content of the message.

For 2, if it's a password that the user chose, the site should never email it, because the user likely reused that password across many sites, and someone who snoops on the user's email (say a housemate) can get the password to a ton of sites.

If it's a password generated by the site, then it's actually fine to email it. Although you likely don't want it too early in the email that it would show up in a phone notification or in a body summary in gmail.

Many sites are wrongly listed there, like https://plaintextoffenders.com/post/629608281322733568/qnx-s...

> attacker can create a website and ask you to join it under the hope you'll reuse your horcrux on the attacker's site.

I don't think that reusing the same pepper (horcrux string) for all sites would be best practice.

If only we had a secure place to store all of the horcrux strings that are unique per-website!

Joking aside, I don't see the point of this. It guards against exactly one attack (your password manager somehow revealing all your passwords) which is unlikely, but not against a whole lot of other (slightly more generic malware, phishing, ...) whilst making logging in harder (there's now a manual process).

If you're willing to go such lengths, enable 2FA on more accounts (which the articles mentions, points for that) or get a physical token for your password manager.

That might be likely if the password manager database is stored in the cloud. iCloud hacks seem to be at least somewhat common and iOS users often hsve no other means of syncing their password manager database.

Isn't that a non-issue if the cloud version is encrypted?

That defeats the point of using a password manager more or less. You're just remembering individial passwords but it's even more complicated now.

That's ok - just use two different password managers and merge the parts manually on login ;)

True but all of the methods you mention to determine the horcrux are also ways to get someone's typical password, so password manager + horcrux is still much stronger as you need both (besides obviously the keylogger/malware).

You could also just have a horcrux for a couple sites and make them all distinct obviously.

Well my thought is that it doesn't take much effort to get a typical password, but does to get a password manager user's password. So an attacker who gets the password from a password manager can probably easily get the horcrux as well.

For important logins, I don't even write the password in my password manager, as I assume it's already compromised. Instead, I write there notes about how the password should be derived, e.g. contoso.com|x4|s1. Even if someone gets to see this and even they guess the exact structure of this algorithm, they'd have to know the salt, which would take long time to bruteforce. Otherwise they'd have to wonder if x4 means "4 times hashing" or "repeated 4 times" or it's something to do with the salt.

I wrote a program to generate passwords based on user input about 10 years ago. I still use it today and a few teams I have worked with still use it. I called it DPG. Deterministic Password Generator. It is a similar concept. I have implemented it in Go, C++, Java and Python.

I wish the idea of generating passwords when needed rather than storing and retrieving them was more popular. Traditional password Managers are just flawed.

https://github.com/62726164/dpg

The standard answer is that if someone gets hold of your generation procedure, they can guess all your other passwords, and your future passwords too.

They'd still need your master pass phrase though? So the security is only as flawed as a password manager

With DPG, you don't have to use the same sentence for each generated password. It makes it easier and more user friendly, but it's not required. I could easily have two or three sentences and still be able to recall 400 or so unique, strong passwords.

Around 5 years ago I wrote something very similar, for the same reasons as you. It was never intended to be more than a proof of concept, but I've ended up using it most every day.

Mine is web based, but all implemented in the front-end; no data is ever sent to the server.

I was debating whether to post the URL, because I don't really want a bunch of people to start depending on it the way I do (I have zero plans to maintain/improve it). But I feel like there may be sufficient interest. So the URL is in my profile for the next 48 hours.

> Your verification code is 120179. You can use it to verify your seed password in the future.

What does this mean? And how is it used to verify a password?

The "verification code" is a 6-digit hash calculated from the seed password. The idea is, you'll become used to recognizing the same verification code whenever you type your seed password - then you can quickly spot if you ever make a typo in the seed password.

Thank you for this.

So if I need to change my 'amazon' password, I press 'generate different codes'. Then when I need to use my amazon password, I come back and click the 'generate different codes' to retrieve the new password?

What is the best way to use this for a service where the password frequently changes?

If you need to change your 'amazon' password, you click 'generate different codes', yes. That action will be remembered in your browser's local storage. So when you need to use your amazon password again, it will automatically advance and generate the correct password.

But if you come from a different browser, you'll need to click 'generate different codes' again to advance to the correct password.

For services where the password frequently changes, I don't think there's a very practical way to use this. At least not across several different browsers.

This would be too hard for the average computer user. I love the concept and could see it working for more technical users, though. There are definitely some risk trade offs over traditional password managers, though. To start: Humans have biases. Randomly generated passwords don’t have any biases. I would have to think more on this from a cryptography perspective as well, but I think it’s a cool idea :)

Another open-source tool for that is Master Password:

https://masterpassword.app/

Can it cope with services that disallow certain characters? Can it cope with services that require e.g. at least one digit, symbol, and capital letter?

>I wish the idea of generating passwords when needed rather than storing and retrieving them was more popular. Traditional password Managers are just flawed.

Why?

Password generators have flaws of their own and have been discussed extensively on hn eg. https://news.ycombinator.com/item?id=13016132 or https://news.ycombinator.com/item?id=22580719

So if a site is compromised and requires a password rotation, do you just never use that site again?

This is not an improvement over just using the click-to-login features of modern password managers.

Modern password managers generate strong random passwords and integrate with login forms in your desktop browser and on your mobile device. There are some exceptions with sites or applications that don't behave well, but as a general rule: you should not ever need to know any of your passwords anyway.

You should be clicking on whatever little icon is attached to login forms so that your password manager can autofill it for you. There shouldn't be an opportunity to add something to a password during login; you're just adding friction to a process that should be as frictionless as possible, because friction causes people to make bad decisions.

If the concern is that someone might be able to access your password manager, you should think harder about what it would mean for someone to have that level of access to your devices or data.

> [What if] your master password (the password to your password manager) is compromised...

Remote access for cloud-sync'd password managers should all have 2FA enabled anyway. You shouldn't be using anything even remotely simple for your master password. Local access to your password manager means you're screwed.

> [What if] someone gained temporary access to your unlocked system (computer or phone) when you stepped away

This is weird. Is this a thing? Are there people with private data in public environments who don't have the presence of mind to take their devices with them in to the bathroom but do have the presence of mind to dick about with their passwords every time they have to sign in to something? I'd pretty comfortably wager there's a much larger real risk from skilled phishing than from somebody in a hoodie rushing over while you're on the can regretting last night's last-minute Taco Bell trip.

> you're just adding friction to a process that should be as frictionless as possible, because friction causes people to make bad decisions

Integrating a password manager with a browser is too fragile and risky way of using both. It is best to have them fully separated so they can't communicate. They should communicate exclusively via the user.

The login process should have some friction and should not be fully automated. Adding a secret domain-specific suffix to the password is very little friction for the user a gives obvious benefits: password manager does not know the password, it can't send it to other application (intentionally or by chance), it won't login the user by accident.

> Integrating a password manager with a browser is too fragile and risky way of using both. It is best to have them fully separated so they can't communicate. They should communicate exclusively via the user.

Which gets targeted more and why, the user or the password manager?

If you are suggesting that we should be manually entering passwords into sites as copied/observed from our password managers, that removes the anti-phishing benefits of password managers altogether by giving primary control back to the human. If I never type a password again, those hackers sending fake login page links "from my boss" will never gain me. Not so with no direct connection between my password manager and my browser.

this requires you to only remember one horcrux to add a layer to security, and it survives key rotation. there is a difference.

You have a point, but I think technical people here are more concerned about buggy or malicious or badly interacting local software than about them falling for such phishing attempts on websites. I may be wrong, and I agree verifying validity of URL is a nice feature. A feature that should be implemented by the browser as well.

Passwords are about proving identity. Using high entropy passwords for greater confidence of user identity is only part of the equation, the user needs to be able to identify the validity of the service as well.

The greatest benefit of an autofill enabled password manager is it handles the task of URL validation before offering up credentials. When you split up that function, now it's back to relying on humans to get everything right on verifying credentials get submitted only to the intended service.

Yes it has benefits but also drawbacks; I don't like the tradeoff. You have to give the password manager too great capabilities to achieve the autovalidation+autofill. Maybe if you check and compile the password manager yourself.

Also automating the process entirely means the login process can happen and succeed (or fail and disclose the password to attacker) without the knowledge of the human.

I don't have time for that, so I just run both browser and password manager isolated and copy and paste the password.

If you hash the concatenated string result, and use the hash as your password, it also means your horcrux wouldn't be at all visible to services. That's a lot of extra work though.

Older and weaker hashing algorithms are probably better for this, sha384 and upwards produce large hashes that might be too big for passwords for some websites. Protonmail trims anything more than 72 characters. See - https://www.reddit.com/r/ProtonMail/comments/khrzhe/pm_ignor...

Just take the first n characters of the hash then.

This isn't good security advice. Taking trunc(32, hex(sha512)) will still give you a result that is stronger cryptographically than taking the 32 characters hex(md5sum) would give you.

For more security, you of course can encode the sha512 hash in a format other than hex in order to let those 64 bytes be fewer characters. The hex encoding is only one of many encodings.

But the main point is that the solution to needing to store a shorter value is not to use a weaker hashing algorithm, but to truncate the result.

This is the reason that sha-512/256 exists as a truncated sha-512 even though sha-256 already existed.

The problem is some websites have very old password rules like uppercase characters and symbols. So you would need a hashing function which produces these, and change the algorithm per website depending on what they allow and disallow for password characters...

This is even worse advice! If you have a small input, you want a hashing function that matches that size[1] of the input as closely as possible. Collisions aren't important here (so "strength" isn't important), just the randomness. MD5 and SHA families give you (mostly) random distributions. The bias in the results are practically meaningless.

[1] https://crypto.stackexchange.com/questions/12822/are-the-sha...

I was only trying to point out the apparent effect of randomness that hashes give. Randomness is the key here, since probably no one is going to brute force a unhashed password, since the password would already be known. Not all websites automatically truncate a password, although yes, using the first 'n' letters would be a good idea. Some websites straight up say the password is too long, and you might have to try and guess the limit.

I don't think the algorithm matters here, but only the length.

This seems no better than a password manager that stores encrypted passwords but not the decryption key.

It is much better to use a password manager than trying to remember poorly crafted passwords in your head. But also really/truly remember not to really put all your eggs in one proverbial basket.

Password managers are not without dangers:

1. If you forget your master password or secret key (you need both to setup a new device), you are screwed.

2. If the password manager cloud sync service (like 1password) decides to cancel your account for whatever reason, you are screwed.

3. If the password manager allows silently keeping replicas on devices you don't know about, you are screwed.

4. If your password manager logs your sign-in access patterns along with your IP addresses (even from behind your fancy VPNs), you are screwed.

5. If you are storing your password, your 2FA secret, and your recovery keys - all in the same password manager, you are royally screwed when that password manager is compromised.

6. If you lose your device, or device gets damaged etc and you don't have a copy of your vault, you are screwed.

Remember – supply chain attacks (example: password manager company's office gets hacked, and their signing key gets stolen and a trojan update is delivered to your machine) will happen some day (may have already happened) and all your passwords will be stolen. Just assume that and behave accordingly.

> 4. If your password manager logs your sign-in access patterns along with your IP addresses (even from behind your fancy VPNs), you are screwed.

Can you explain why one would be screwed in this case?

In this case, screwed w.r.t privacy (your credentials may still be safe). But you may become a target because of your sign-in activities which are no longer private.

A lot of these are easily mitigated by running your own password manager. They're just general drawbacks of running stuff in the cloud.

Others are mitigated by good opsec and backup strategies.

I somewhat recently made my personal disaster recovery plan, and the password manager features prominently into it. If I lose all of my electronic devices in a sudden accident, how can I recover my online life? To address your questions specifically:

1. I used Shamir's secret sharing to send out a copy of my secret key to a few loved ones. The master password is in my memory only. If I forget the master password, I lose.

2. I use 1Password, and they say they make accounts read-only once you stop paying. If they did actively delete my account, my devices have a local copy. If I lose my devices and they delete my account at the same time, I lose.

3. I don't know what you're imagining, but you need the data, secret key, and master password to have this be a concern.

4. This has nothing to do with my threat model, I'm afraid. I can't imagine a world in which knowing my IP address leads to decrypting my password vault.

5. I am and this is correct. If there's a vulnerability in the cryptography used by 1Password, I lose. As you said, if there's a trojan update, I lose.

6. This is the same as 1 and 2.

All things considered, as a regular person who is concerned about protection from thieves and not especially concerned about being a target of governments, I am OK with these risks.

How did you encode messages for (1)? Did you provide instructions? Did you keep a copy?

There's a ton of online sites for it. I used something custom, but the first result on google seems like it would work just fine. https://iancoleman.io/shamir/

I kept a copy of the combined secret... it's the secret key to my password manager. I do have a plain-text document that fully describes the steps to restore my identity, but it's addressed to myself. My goal is to get my own identity back, not to prepare for my own death.

My least-effort solution to most of these issues is to be storing hard copies of the password to my primary email in different places and using 2FA.

Then if my password manager does get nuked or compromised, I can "restore" my accounts by using the "forgotten password" feature for most places. If I get trojaned, what are they really going to do with my accounts? The majority of things of importance are behind 2FA anyway, and I'm not a public enough figure that any of my data that isn't is of any importance anyway.

> All things considered, as a regular person who is concerned about protection from thieves and not especially concerned about being a target of governments, I am OK with these risks.

As a regular person, you have to consider these possible attacks on your money/data:

1. Attacker is a person in your life – friend/family/acquaintance – targeted you specifically. Attack may not be very sophisticated and maybe easy to defend against if basic hygiene is followed.

2. Attacker is a remote entity – people who you don't know personally – you were not targeted personally – but you became a target because you are part of a cohort they targeted – nothing personal. Attack of this form can be quite sophisticated.

3. Thief is a govt entity (foreign or domestic) – because you were targeted directly or because you are connected to someone who was targeted directly. More than technical mechanism there are legal mechanisms at play here.

#2 is a very big threat. A password manager service company is a very attractive target for them. Imagine the recent SolarWinds Orion supply chain attack being done by an underground cyber criminal group and being chained together to compromise your favorite password manager service stack.

2. Use a local password manager that saves to a file that you share using your own Nextcloud server.

This doesn't address the key issue of how many "in head" horcruxes you want to have. Is it one and the same for all passwords? Then two broken passwords reveals it (if someone's clever maybe even 1, not sure here). If it's different for different passwords, you now need to memorize (or store elsewhere) a list of many, many such horcruxes. Not 7... but maybe a 100 or 200 to be practical for a heavy user of internet apps. Which basically means you need 2 password managers.

So where do I store the 100 horcruxes? What's your take on this?

I have about 400 DPG passwords all stored in my head.

https://github.com/62726164/dpg

Now teach my grandma to do that.

Experts can go buy yubikeys and achieve far greater security for less work. Everything else needs to work for the masses.

deterministic password generator? You mean like https://pwdhash.github.io/website/ ? Might be worth spelling out the differences for those of us lacking expertise in computer security matters.

You can store them on a keyring or in a wallet.

A 2nd password manager for the 2nd part of the password breaks maybe the key advantage of this mechanism by putting the "something you know" into a decryptable by design storage space that is most likely duplicated in the cloud.

You could take this a step further and make your "horcrux" a short & simple cipher code based on some attributes of the organization instead.

It takes a bit longer to construct for sites you don't log into often, but when appended to a password/passphrase, it appears to be random across each site. If multiple logins get leaked it's not immediately obvious you're are using the double-blind approach.

My bank uses some kind of mandatory javascript malware to make it impossible to paste or password-manage the password they demand. I'm beginning to see this on an increasing number of sites.

Even if I could find out which banks don't make this particular offering to Satan, what would prevent the bank I switch to from adopting this malfeasance next week?

Yes this is the most annoying thing to deal with. From my experience these sites block pasting values. I use Don't Fuck With Paste [0] [1]

[0] https://chrome.google.com/webstore/detail/dont-fuck-with-pas...

[1] https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...

This can be a useful idea, requiring a checkbox on password managers, e.g., "[ ] Pause for additional input".

No one ever answers how often security breaks are from: passwords being guessed, brute forced, or shared; client side compromise from malware, keyloggers, and first-hop IP session takeover; or server side compromise from poor custom code and poor infrastructure choices. Anecdotally, the chart leans to the server side security breaches.

In the absence of knowledge, we get two security talks repeated over and over. This is the first: do a better job with passwords. The second is "You are irrovacably insecure because of [some issue], but update your passwords regularly."

Security has not developed a reputation for being a craft or science.

> No one ever answers how often security breaks are from: passwords being guessed, brute forced, or shared; client side compromise from malware, keyloggers, and first-hop IP session takeover; or server side compromise from poor custom code and poor infrastructure choices.

It's really hard to get those guys to fill out questionnaires.

It seems to me that this does not add a lot of security if you use the same extra word for all passwords.

It probably does add a lot of security if you use a different extra word for each password, but then you can't remember them anymore and you need to write them down somewhere.

Not if you use some obscure pattern for these added words. Yeah if a hacker saw a bunch of them then maybe it could be deciphered, but wayy better than reusing the same one.

I think it’s more of a last line of defence in case your password manager gets compromised. Especially if your pw manager also handles your TOPTs.

But if your pw manager gets compromised then that’s a pretty big problem so probably best to focus efforts on that not happening.

It could make sense for sensitive accounts like email, valuable social media etc

I am honestly somewhat confused by this newfound lack of confidence in human memory.

When I was 12 years old, everyone around me could easily remember up to 50 different 10 digit phone numbers, I still remember those.

Double blind is the wrong term here. Multi-factor would be appropriate.

With a degree of complexity removed since the key doesn’t change over time.

Removed? Do you regularly change passwords?

I can see the point when using a password manager, though it's typically overkill, but please be aware that forcing memorized secrets to be changed arbitrarily (e.g. time-based) is recommended not to do in the updated guidelines from USA's NIST, UK's NCSC, Microsoft, and others based on research into what effect it has on password quality.

But the expectation is that something does change (the 2fa). If you use this system without a second factor then a hash breach screws you. And if you do have a second factor then this system achieves almost nothing.

Although this seems cool, there are at least two downsides:

1. You have to copy/type the password manually, instead of relying on your password manager to recognize the website, leaving you more vulnerable to phishing.

2. More manual entry... I a world where I use passwords around a hundred times per day, I don't want to type them.

Also, it's easy to avoid the two risks he mentions:

1. Don't write your master password on a post-it, duh.

2. Don't leave your session open when getting a coffee.

I'll stick with the standard practice.

interesting idea that I'm loath to follow as I enjoy having my passwords auto-filled from my password manager - particularly on mobile.

> use a horcrux only for the most important logins - your social media, bank accounts etc.

Am I the only person who does a huge double take on this? If someone hacks a facebook or a twitter - what precisely am I scared of? My bank accounts are literally my net worth. If they get hacked I'm broke.

Why would I want a particularly strong password on Twitter or Facebook or Linkedin for that matter

I wonder if it's implicitly acknowledging that social media (at least Google and Facebook) are authentication providers for thousands/millions of other services. So it's more of a "protect the keys to the kingdom" suggestion for those that use Facebook/Google to sign in to everything (not that I recommend doing that often).

I would 100% consider email under the highly important banner, but I'd not considered at all the "Log In With Facebook" angle.

There are at least some people for whom twitter and other social media sites are important professional assets.

And I'll echo another comment that if you login with Facebook or Google, that increases the value of that password.

On a similar note, your very strongest password should be whatever controls the email where your password resets get sent to.

Probably because (too) many people use them as OIDC providers for many other sites. "Log in with..." &c.

Because they are your public face online and the quickest route to your contacts. It is trivial to do immense reputation damage with access to that. Would you rather go through the hassle of getting money back after you were the victim of bank fraud, or getting respect back after someone posted hardcore porn to all your contacts or used your social media as a vector to spread a scam link?

Isn't the whole solution to the problem:

1) Choose a good master password for you password manager

2) Remember it

3) !!! Don't write it down anywhere !!!

It’s not a solution if most people can’t or won’t do it.

The solution to murder is “don’t kill anybody,” but that’s not helpful in a discussion about preventing crime

I think there are a couple of problems in practice with this:

1) I don't leave my password manager open overnight, but I do during the day. My master password is long and I enter a lot of passwords. The most obvious attack vector is getting onto my computer while I'm working, not cracking the master password.

2) Losing my master password would be a _big fucking problem_. Once I'm confident I've learned it I destroy whatever it's on, but I can't risk having no backup before then.

Both of these points could be addressed if I were safeguarding nuclear launch codes. But I think it's silly to treat my passwords as national secrets. I'm not willing to abandon all convenience for the sake of safety.

How real is the evil maid threat model where they open up your password manager but don’t have enough time to install a key logger? And even if this threat model matters, 2fa defeats it.

This entire horcrux system feels like cleverness for cleverness’ sake rather than actually addressing a meaningful threat model.

I don't have a strong opinion on the horcrux system. It's a simple solution to a minor class of threats. Six to one, half dozen to the other.

My issue was that the "whole solution" to the problem proposed by the parent relies on idealised password manager usage which I don't think is representative of real-world use.

> It's a simple solution to a minor class of threats.

The threat models it addresses are (1) "evil maid without time to download a keylogger", (2) "cloud leak of your password database alongside sites that aren't using any 2fa" and (3) "cloud leak of your password database alongside SMS-based 2fa and a desire to go through the trouble to SIM-swap you".

All of these threat models are handled with TOTP-2FA. (1) is rare. (2) and (3) require your password manager to be compromised but not your application's password database.

In practice, virtually all threats to online accounts are phishing or password stuffing from database breaches. This system does not change your posture against these threats.

People will only follow so much security advice so you need the specific small set of things that you recommend to everybody to address the most common threats and you need the set of things you recommend to more targeted individuals to actually address a wide range of threats. Introducing additional systems that address a subset of meaningful threat models just introduces confusion.

"Use a password manager with autofill to generate unique passwords" defeats credential stuffing and most forms of phishing. This system is worse against phishing since you personally type in the password. "Use a password manager with autofill and a yubikey" fully defeats credential stuffing and phishing. It also defeats the situations addressed by horcruxes.

> My issue was that the "whole solution" to the problem proposed by the parent relies on idealised password manager usage which I don't think is representative of real-world use.

I do agree with this.

This concept has been around for forever but referred to as "something I have" (password manager, yubikey, etc) and "something I know" (the one in your head).

Cloudflare published a fantastic piece on passwords (viz. OPAQUE) recently that got little to no attention on news.yc, unfortunately [0].

OPAQUE + Horcux sounds pretty close to what Signal did for its app passwords [1].

[0] https://news.ycombinator.com/item?id=25346632

[1] https://news.ycombinator.com/item?id=21839117

Isn’t the effect the same as having a second layer of encryption, i.e. a second master password that you enter on the client only, to unlock each password?

A second layer of encryption actually seems better since the key, unlike the horcrux, won't be leaked to all services.

The best password manager would be a physical device which requires a tap to unlock a password.

Trezor password manager got close, but it seems like they abandoned it and they never supported local (sd card) storage.

Basically, It would be a yubikey style device, secured by a master password. You could have nice browser plugins for listing all your available passwords and single click logins, etc.. Everything that lastpass/1password does from a UI standpoint.

The difference would be that decrypting/unlocking passwords would require you to physically tap on the device each time to approve the unlock- and the screen would say "Unlock password for github.com?". Basically, this system makes it impossible for some trojan remote-control virus to be able to get your passwords, even if they have your master password. The BEST they can hope for is just to sit quietly on your PC for months, slowly storing all the passwords you decide to unlock.

Alas, doesnt seem like this device is going to exist any time soon. As I said, the best bet was trezor but they dont seem to care about it anymore. Too bad, they were so close.

I'm building exactly that.

Trevor is a joke, security-wise. I literally laffed.

> Trevor is a joke, security-wise.

Any links you can share?

I like this, but what about mobile? What if you borrow a friends device?

Genuine questions. I want ease-of-use and security. Is it possible?

On iOS is the real question/problem and it's unclear if it would be workable outside a custom app to talk to it.

From a security perspective it'd be nicer to use FIDO2 normally and approve from a device where the secure password could be entered.

You can set this up with `pass` and a Yubikey: https://www.palkeo.com/en/blog/perfect-password-manager.html

Or just use federated authentication ala log-in-with-X with non-SMS 2FA protecting the identity account. SAML, OIDC, and friends are immune to dictionary attacks, leaks, rainbow tables, cross-site re-use, and all the other password problems.

If you can trust X enough to not allow social engineering for password resets then it provides at least as much security as a memorized passphrase. Google provides Advanced Account Protection for people who really need it.

Hopefully most sites start allowing multiple federated identities per account so that anyone worried about keeping all their eggs in one basket can maintain and attach more than one identity.

For any X meeting the above criteria they're going to be a much harder target than any random online service accepting the federated credentials (this applies to insider threats and external attackers alike).

X doesn't exist for you? Help build it. There's no specific reason that Facebook, Apple, and Google should be the only trusted identity providers on the web, but they do invest significant effort in minimizing account theft and hardening their infrastructure, and most eat their own dogfood to protect their corporate assets. The big advantage that Apple and Google have is that they can tie identity to biometric and physical factors in a way that's hard for anyone else to achieve.

Once computing implants are widely in use identity can move to that but until then we have cell phones that, paired with U2F hardware, can be the root of trusted identity and (with a passphrase and lock screen timeouts) are practically immune to anything below state-level actors. 0-day exploits exist but they're sold to state actors and held in reserve.

Note: This only applies to online services. Memorize your device encryption keys for local data security; there's no way around that.

The problem is trust. What would you do if e.g. Google closed your account? Something like easy to install on prem X speaking standard API with pluggable 2FA could be a winner.

This won't work very well if the site you're logging into uses bcrypt, and the value you store in your password manager is >= 72 characters.

https://paragonie.com/blog/2016/02/how-safely-store-password...

If a site is using bcrypt and it allows users to set passwords longer than 72 chars, the operator of the site is the problem not the use of a password manager + in-my-head-secret

Bcrypt is very common on the Internet, though.

I do't really agree with the long passphrase thing.. I leave my passwords at 12 characters max (and 8 for less important sites)

Reason: You still have to type it sometimes. Like on a device you don't have the password manager on. That makes it really annoying. And because it's only used on one site it doesn't really matter how long it is. If a hacker gets hold of the password file they already own that site anyway. Doesn't really matter whether they can bruteforce the hash. It won't give them more access than they already have.

I do agree with the horcrux thing though.. Really important passwords I only store on paper and I already add a memorised thing to them. But be aware it's not perfect either. A compromised endpoint could have a keylogger installed. Totally passwordless with Fido2 for example would be even better.

> won't give him access to more then he already has.

That is very incorrect. A lot of hash leaks happen when an attacker can read data. but he can't necessarily edit it or even make sense of it. Also, the attacker usually does a quick download, then _sells_ the data. So, imagine your Twitter password was leaked. The original attacker a) likely doesn't have write access, and 2, is just going to sell the password hashes. The real worry is the buyer, who buys the hashes, to log in as you and do anything.

This is how youvebeenpwned works. He actually finds leaks of hashes on the dark web.

> Reason: You still have to type it sometimes. Like on a device you don't have the password manager on.

Assuming a standard typeable character set (letters upper/lower, numbers, symbols you can type on a standard US keyboard), you've got 92 characters. (Safe assumption given you're planning on typing this on all sorts of devices.)

Your randomized eight character password has 52 bits of entropy. Twelve characters takes it it to 78 bits. Not really enough if you're up against an offline attack.

Assuming you choose 5 random English words (which will probably take you about two seconds to type on something like a phone), you'll have a more secure password.

I agree typing on devices that don't have your password manager is annoying, but in my experience it _really_ doesn't come up that often. Yours is the exact reason I use 32 character passwords rather than the 64/128/etc some people I know use.

But 12 is.. short. The trade-off between the added security and the inconvenience makes it a pretty obvious choice for me. (And you're wrong--having a database dump full of password hashes does not "already owning that site" make.)

Typing 32 characters on a game console to log into Netflix taking an extra minute every few years is really not that inconvenient relative to the added security. And it's something like 2^130 times more secure than your 12 character password for the inconvenience it brings. Or about 1,361,129,500,000,000,000,000,000,000,000,000,000,000 times (I can't actually find the SI prefix for how big this is) stronger.

While not being a bad idea, I think that any advantage of this method and double/triple locking your password manager (by an additional encryption layer) falls into the category of warm-fuzzy-feeling-of-security.

Also, while unlikely to pose a real threat, since this method literally breaks the 3rd rule introduced in the article ("Have a significantly different password for each account") and not only that, it does so by _appending_ a constant string to all your passwords, it introduces the potential risk in case a vulnerability is found in the cipher that's used to encrypt your passwords database.

Another great 2FA app on android is Aegis [1]. Open source, beautiful design, and supposedly better crypto than andOTP [2].

[1]- https://play.google.com/store/apps/details?id=com.beemdevelo...

[2]- https://old.reddit.com/r/androidapps/comments/b45zrj/dev_aeg...

Is there any reason why something like bitwarden couldn't prompt you with an in-browser prompt() dialog for your horcrux right before you enter your password and append it the one they auto-inject into the form?

I immediately thought of this. There’s no way I’m using this technique if it’s not automated at least a little

I've been using this tactic for years http://lukasz-madon.github.io/Password-management/

What a great idea and with a fitting name to boot.

There's another project called horcrux[1], but it doesn't split passwords, it splits files to encrypt them without password.

[1]: https://github.com/jesseduffield/horcrux

Password manager + sha256sum generated from /dev/urandom has worked well enough for me for the past six or seven years.

Is occasionally a pain when doing things on a phone, but even then I just log in once to most things and am good to go.

> NOTE: process-cancel-stingy-garnet is technically a passphrase - basically an easy-to-remember password in comparison to randomized strings like B6fSpxMj&f6DU@5^k

(Word dictionary size)^4 > (Alphabet size)^17

I don't think so

With a dictionary of 10k words, you can get 1e16 combinations, which seems adequate when used with a deliberately slow hash function like bcrypt.

I would point out the part you store in your head is the master password.

> If it feels like too much effort, use a horcrux only for the most important logins - your social media, bank accounts etc.

In what world is my social media account more important than bank account?

This is the wrong use of the term "double blind".

Doesn't scale. To do it correctly, you would want a different secret in each case, and our inability to remember so many secrets is exactly why we use password manager in the first place.

For a small number of key accounts, sure.

When sites let users use asymmetric cryptography, like RSA or ECDSA? It's far more superior because of invulnerability against server hacks or phishing.

I don't like raid-0 for passwords.

What do you mean?

They probably mean that they don't like situations where the loss of one password element / harddisk means losing everything.

In other words: they don't like having a single point of failure.

Make backups.

Quick question: how do you deal with sharing important passwords with your closest relatives in case you are unable to recall it (sick, dead)?

Printed paper backup in a sealed (=tamper evident) bag in a safe with a family-known code.

did secret sharing really needed a new clickbait name? or OP just thought he reinvented the wheel?

horcrux encrypted messaging related: horcruxencryptedmessaging.jperla.com

> Randomized passwords are better than personally identifiable passwords

Better in what sense?

If you can’t remember it you have to store it, which increases surface of attack.

Reply on news.ycombinator.com