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].
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.
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.
https://francoisbest.com/posts/2020/password-reset-for-e2ee-...
[0] https://en.wikipedia.org/wiki/Yao%27s_Millionaires%27_proble...
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.
https://github.com/jesseduffield/horcrux
This is basically a low tech (and much more unsecure) version of the n=2 case.
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 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..
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.
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.
You could also just have a horcrux for a couple sites and make them all distinct obviously.
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 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.
I wish the idea of generating passwords when needed rather than storing and retrieving them was more popular. Traditional password Managers are just flawed.
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.
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?
What does this mean? And how is it used to verify a password?
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
Can you explain why one would be screwed in this case?
Others are mitigated by good opsec and backup strategies.
So where do I store the 100 horcruxes? What's your take on this?
Experts can go buy yubikeys and achieve far greater security for less work. Everything else needs to work for the masses.
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.
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?
[0] https://chrome.google.com/webstore/detail/dont-fuck-with-pas...
[1] https://addons.mozilla.org/en-US/firefox/addon/don-t-fuck-wi...
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.
It's really hard to get those guys to fill out questionnaires.
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.
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.
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.
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
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.
1) Choose a good master password for you password manager
2) Remember it
3) !!! Don't write it down anywhere !!!
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.
This entire horcrux system feels like cleverness for cleverness’ sake rather than actually addressing a meaningful threat model.
The solution to murder is “don’t kill anybody,” but that’s not helpful in a discussion about preventing crime
OPAQUE + Horcux sounds pretty close to what Signal did for its app passwords [1].
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.
Genuine questions. I want ease-of-use and security. Is it possible?
From a security perspective it'd be nicer to use FIDO2 normally and approve from a device where the secure password could be entered.
Trevor is a joke, security-wise. I literally laffed.
Any links you can share?
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.
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.
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.
[1]- https://play.google.com/store/apps/details?id=com.beemdevelo...
[2]- https://old.reddit.com/r/androidapps/comments/b45zrj/dev_aeg...
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.
(Word dictionary size)^4 > (Alphabet size)^17
I don't think so
In what world is my social media account more important than bank account?
For a small number of key accounts, sure.
In other words: they don't like having a single point of failure.
Better in what sense?
If you can’t remember it you have to store it, which increases surface of attack.
