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...
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.
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.
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].
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.
"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.
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.
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):
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.
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.
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).
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.
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.
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.
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.
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.
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
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 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.
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.
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.
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?
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.
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.
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.
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.
> 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
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.
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.
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 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.
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.
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.
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.
184 comments
[ 3.3 ms ] story [ 259 ms ] threadIn other words: they don't like having a single point of failure.
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.
[1] https://crypto.stackexchange.com/questions/12822/are-the-sha...
I don't think the algorithm matters here, but only the length.
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/
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.
https://en.bitcoin.it/wiki/Shamir_Secret_Snakeoil
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...)
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.
If they have 5 random numbers and XOR them together, then they won't get the key as output.
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).
https://francoisbest.com/posts/2020/password-reset-for-e2ee-...
[0] https://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_proble...
https://github.com/jesseduffield/horcrux
This is basically a low tech (and much more unsecure) version of the n=2 case.
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.
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.
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.
Can you explain why one would be screwed in this case?
Others are mitigated by good opsec and backup strategies.
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.
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.
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.
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.
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.
https://paragonie.com/blog/2016/02/how-safely-store-password...
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.
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.
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.
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.
How did you eventually find out their true motivation?
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.
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.
Some sites email your password to you: https://plaintextoffenders.com/
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.
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.
I don't think that reusing the same pepper (horcrux string) for all sites would be best practice.
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.
You could also just have a horcrux for a couple sites and make them all distinct obviously.
[1]- https://play.google.com/store/apps/details?id=com.beemdevelo...
[2]- https://old.reddit.com/r/androidapps/comments/b45zrj/dev_aeg...
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.
(Word dictionary size)^4 > (Alphabet size)^17
I don't think so
0: https://en.wikipedia.org/wiki/Pepper_(cryptography)
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.
But “client-side peppering” won’t get you to the front page of HN..
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).
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.
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.)
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.
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).
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.
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.
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
When I was 12 years old, everyone around me could easily remember up to 50 different 10 digit phone numbers, I still remember those.
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.
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