16 ms·
Horcrux: A Password Manager for Paranoids
- posnet 9y agoRepository of the project: https://github.com/HainaLi/horcrux_password_manager https://github.com/HainaLi/horcrux_password_manager
- 1ba9115454 9y agoPerhaps this helps with trusting the password manager but it looks a bit complex to me. Personally I'm more concerned about when I enter a master password that if there's a Trojan on my computer it's game over. As most password managers are an encrypted database of sorts once it's encrypted all your passwords are out. The only protection against that is some sort of 2FA.
- Santosh83 9y agoI guess if your system is compromised then password security becomes gravely threatened, no matter how secure the password manager may be. The only partial solution I can think of is to have the OS sandbox every application from every other.
- kefka 9y agoYep, pretty much. It really reminds me of this: https://xkcd.com/1200/ https://xkcd.com/1200/ for obvious reasons. The only ways I can think that would be able to prevent this are: 1. Physical non-networked device password manager 2. Really creative usage of SELinux 3. QubesOS And in reality, #1 is kind of how RSA tokens are used. Of course, physical can be lost, stolen, and all that. QubesOS takes a ton of resources to run effectively, given everything is VM'ed and contained with a capability system. In all honesty, I could see buying an Android at a Pay as You Go place, and repurpose it to be a offline password manager. Never connect it to wifi, BT, cell. And any APK's you need you load via microSD card and USB.
- simias 9y agoYou can also use a hardware token to handle the encryption/decryption (yubikey/nitrokey/GnuPG smartcard/...). If you have a trojan on your computer it'll still be able to decrypt your passwords while the token is plugged and unlocked of course, but at least offline attacks shouldn't be possible. Of course that doesn't mean you shouldn't use 2FA wherever possible to mitigate the risks further. Some tokens can also be configured to wait for a physical button press to allow the decryption which which can help prevent a complete background decryption of your passwords (assuming that each password is stored with a different key, like with password-store for instance).
- snowwrestler 9y agoYes, the way to deal with trusting password managers is to use TFA as much as you can.
- Nyubis 9y agoThe trick of entering a dummy username and password, which is then modified in the post request sounds a whole lot better than playing clipboard roulette or messing with the DOM.
- baby 9y agoThis sounds pretty cool! What I'm wondering, is how they are intercepting the POST request and at what level?
- kodablah 9y agoI have not read yet, but my guess is they are taking all HTTP requests from the page and looking for their dummy username/password and replacing that. Not every login form (though we would like it) is in a form tag w/ an explicit action. Some SPA's will do an AJAX post of JSON w/ the credentials embedded (which is bad practice, but happens). Actually, the more I think about it, I don't think I want this extension to do that...how does it know how long between when the fake fields are entered and when I press submit? Now I am going to read the paper... Edit: Yup, the extension intercepts all network traffic even before you click submit. If you, e.g., hash on the client side this password manager will break. If you never click submit, this extension will continue to read all HTTP bytes from the page going back to the server it seems, looking for some strings...not sure the perf implications of this.
- curiousGambler 9y agoOut of curiosity, why is an AJAX post of JSON with credentials embedded bad practice?
- kodablah 9y agoNot bad practice from a security perspective per se, just annoying to users that don't want JS, or like the non-password fields to support their browser's features like autocomplete, etc. Granted if it's a SPA, some of that usability shop has sailed. And while any AJAX post is secure normally, many JS implemented login solutions open themselves up to CSRF and other problems.
- iancarroll 9y agoI am pretty sure the code is reusing IVs for AES-CTR[0] (i.e. the encryption is worthless), because it doesn't specify an IV and Node seems to derive the IV from the key.[1] This seems like a massive footgun in Node. I don't think their scheme results in different keys for each site, but I could be wrong. [0] https://github.com/HainaLi/horcrux_password_manager/blob/master/utils.js#L20 https://github.com/HainaLi/horcrux_password_manager/blob/mas... [1] https://nodejs.org/api/crypto.html#crypto_crypto_createcipher_algorithm_password https://nodejs.org/api/crypto.html#crypto_crypto_createciphe...
- letharion 9y agoI opened an issue on the topic. https://github.com/HainaLi/horcrux_password_manager/issues/1 https://github.com/HainaLi/horcrux_password_manager/issues/1
- analogist 9y agoWow. This is yet another example of the fatal combination of Rolling Your Own Crypto + Using OpenSSL Directly And Blowing Your Own Foot Off Because It Lets You. var cipher = crypto.createCipher('aes-256-ctr', key.toString('hex')) Besides the completely fatal error of using derived and non-unique IVs (fatal as in, if you encrypt more than 1 item with it, it is exactly as good as plaintext because any two items encrypted with the same key+iv in CTR mode cancels out to plaintext), isn't using hex encoding vastly constraining the possible complexity-per-byte of the key? A single hard-coded salt for key derivation: const key = crypto.pbkdf2Sync(auth, '0945jv209j252x5', 100000, 512, 'sha512'); Again, the salt is only lowercase alphanumeric. This makes this 120-bit salt really just a 77-bit salt. But since it's hard-coded and not randomly generated, it's a 0-bit salt. Can everyone who is developing crypto apps Just Use NaCl/Libsodium?
- sgdread 9y ago5c from me: 1) why CTR mode was chosen? I would probably go with something like GCM: privacy + integrity check. 2) IV ideally should be re-generated on every re-encryption. It doesn't have to be secret, but has to be random (securely random).
- thinkMOAR 9y agoIf you are paranoid, then there is only one option, you are the password manager. Certainly not a piece of software you didn't author yourself. Else you are not truly paranoid.
- fictioncircle 9y agoIf you can audit the code yourself, you can treat it as code you authored. (assuming you are competent to perform the audit)
- thinkMOAR 9y agoTrue, in theory, though in practice, i know plenty of capable people but almost none of them bothers to read the openssh source (or even a subset, like recent changes) before updating or recompiling.
- phinnaeus 9y agoMake sure you read the code of the compiler you're using as well, and bootstrap/compile it from that source instead of trusting an existing compiler binary.
- Santosh83 9y agoWhy stop with compilers? Inspect the circuit diagrams for all your hardware and then make sure the actual manufacturing followed the designs to a tee.
- Royalaid 9y agoI mean I know it hyperbole but I am pretty sure there are hardware bugs that allow access, see that Intel or IBM remote management disclosure. It might not a real backdoor but it's as good as one. As people above are mentioning keep your paranoia inside your threat model
- madamelic 9y ago
- w8rbt 9y agoI think all password managers that store passwords are flawed. Storage is a burden. The store must be synced between devices, secured, backed-up, etc. and it can be stolen. I believe that passwords should be deterministically generated when needed, not retrieved from a store. I'm not sure why this approach is not seen more often. Edit: It seems people don't understand what I mean... I just put some code here to better explain: https://github.com/w8rbt/dpg https://github.com/w8rbt/dpg
- fredley 9y agoBecause passwords need to be changed (e.g., after a breach). Deterministically generating them does not allow this, unless you add additional information (such as appending an index, e.g. news.ycombinator.com|2), but then you need to store that somewhere...
- patrickmn 9y agoAll such deterministic algorithms are seeded by something. This is their basic flaw. Guess the seed and you get all the passwords. With a password manager that randomly generates unique passwords, you don't have that problem, but you do have to synchronize the data.
- w8rbt 9y agoThe master password of the password manager has the same issue plus the burden of storage.
- simondedalus 9y agoand the virtue of allowing a single point of 2FA. the seed is just the seed, and will always be the seed. the master password can change and be supplemented by 2FA / other enhancement schemes.
- w8rbt 9y agoI'm not sure we're talking about the same thing. See the code I posted. There is no unchangeable static seed.
- crusso 9y agoI haven't looked at the security of it yet, but the name alone is a winner for something you want to keep secret.
- danjoc 9y agoSticking with zx2c4 pass. It is an assembly of gnupg, git, and pwgen. Trusted open source components. Works with a Yubikey (opensc and gpg-agent) to prevent private key theft via software. PassFF extension provides excellent browser integration. Android Password Store and OpenKeychain allow pass and yubikey to work on my mobile. Strong 2 factor password storage everywhere I need it. My biggest problem these days is dealing with sites that don't allow 30+ char passwords with full range of special characters. Almost exclusively, banks.
- pitaa 9y agoWhat is it with banks and their annoyingly terrible "security" requirements? My old bank once sent me an email saying I had to reset my password. The email seemed legit, but upon following the link therein something didn't seem quite right. So I use another device to visit my bank's site directly. Upon trying to login, I get redirected to the same form I reached from the email link and had a sinking realization that my bank did indeed expect me to fill in my name, address, SSN, DOB, debit card number, and PIN just to reset my password. I sent a strongly worded email to a handful of people at the bank asking them if they really thought it was a good idea to teach their customers that its okay to click a link in an email claiming to be from their bank and provide that much personal information. I never got more than a canned response back, but several months later they did overhaul their password reset procedure to a more typical one.
- YCode 9y agoI suspect it's the same reasons nuclear launch facilities use floppy disks -- the solution is approved, and getting a new solution approved is viewed as too expensive/infeasible. Not saying the argument is valid, just that it may be the reason.
- chakalakasp 9y agoThat and its proven to work, has a ridiculously long track use history (for software) so the bugs are fixed or well documented, and pretty damn hard to exploit. It's not like anyone is going to plug an 8 inch floppy disk they found laying in the rural Wyoming dirt parking lot into the nuclear silo master computer to check what's on it.
- cbhl 9y agoDoes anyone else think it's cool that Harry Potter fans are now old enough to be getting crypto papers published?
- haberman 9y agoWhy on earth isn't the industry moving away from per-site passwords? They are terrible. The fact that you need your own app to "manage" them is just evidence of how terrible they are. People should be able to use their phones, Yubikey, TouchID, etc. as their authentication, without needing a password (except a master password for the phone/Yubikey/TouchID). And yet I see no movement towards this from the industry. Are we stuck in this terrible state forever? If I could see into the future I would dearly hope that in 10 years we are not seeing HN front page articles about the newest innovations in password managers.
- taeric 9y agoI'm not sure I actually agree with this. Do you know of any studies that go into this? My concern is around having a single source of failure/attack. Which, to be fair, is probably not that different than most people's scenarios. That is, most people just let their browsers and phones remember passwords. So, in practice this already happens. I just don't feel like it is safe. I'm highly interested in being challenged on this.
- haberman 9y agoI think the only way you avoid a single source of failure is if your brain is actually capable of remembering a separate, high-entropy password for every website you visit. If you use the same password (even a high-entropy one) on every website, any hack of a single site compromises you on every website. If you use a password manager to store high-entropy passwords for every site you visit, then the password manager is a single point of failure. Both of these attacks happen in the real world. But securing a single authentication system like a phone app/Yubikey/TouchID/etc. seems more tractable than securing every website that you visit. Password managers are available today, but since the websites you are using don't actually know about them, the integration and ease of use are not as great as they could be. My vision is that you can use a phone app/Yubikey/TouchID/etc. to create as many identities as you want, and then you can use these to robustly authenticate to any website. To the website you would just be a GUID: an opaque identifier that it doesn't know anything about unless you tell it more. And all the app/Yubikey/TouchID does is let the website know (securely) that you are the same GUID that logged in last time.
- tIONTamINariciA 9y agoIt's fun that the authors readily admit that the idea is for paranoid people. https://xkcd.com/538/ https://xkcd.com/538/
- deno 9y agoBeing vulnerable to blunt objects does not mean you shouldn’t care about other attack vectors.
- tIONTamINariciA 9y agoOverly focusing on one attack vector still leaves you vulnerable to many others. System designers need to consider risk:reward and effort:reward for users. The paper offers an interesting but extreme extension into one aspect of security that users control. That is great to offer an extreme solution for the paranoid. If implemented well, even the less paranoid could use it. Sadly this solution still offers less security than systems integrated into SSO/OAuth and 2FA.
- deno 9y ago> Sadly this solution still offers less security than systems integrated into SSO/OAuth and 2FA. OAuth implementations very often have vulnerabilities. Just look at how many Facebook had! Not to mention 1) it doesn’t scale like passwords and 2) all the privacy implications. As for 2FA it’s in addition to primary authentication scheme, like a password, not instead.
- X86BSD 9y agoI use hashicorps Vault for keeping all my secrets. And never looked back.
- stinos 9y agoa password manager that is designed holistically Honest question: what does 'holistically' mean in this context?
- dave1629 9y ago(co-author here) Good question - it means the whole system (that is, both the client and server) were designed with the goal of limiting the exposure of the user's passwords in all ways we can - including time (not exposing them in the DOM and having the minimum possible exposure to the browser with acceptable user experience), code (minimizing the amount of code that has access to the user's credentials), and organizations (minimizing the trust the user has to put in any one provider).
- EGreg 9y agoToo many problems with passwords, oauth and other things. There should be a standard auth protocol that is secure and works with everything out there. Why isn't there a successfully adoptef one yet? This is my attempt in progress: https://github.com/Qbix/auth https://github.com/Qbix/auth
- pishpash 9y agoSpeaking of, why is there still no standard protocol for changing passwords? That's 90% of the barrier to managing passwords.
- ptman 9y agoThere's several. LDAPv3 ja kpasswd are some examples.
- dspillett 9y agoThree is no complete general agreement on best practise, and probably never will be as the risk factors involved are not entirely objective. Any attempts to create a standard will result in several competing standards ending in this ubiquitous problem: https://xkcd.com/927/ https://xkcd.com/927/
- nickpsecurity 9y agoFor those interested in related work, Mark Currie designed and patented one around 2008 that intercepts logins, injects correct credentials, and handles the TLS on a USB device. He described it to us on Schneier's blog as follows: "The device is a small USB gadget that effectively acts as a SSL proxy, allowing it to have direct and first access to the clear text data to and from the host. It has a small user interface so it can accept (and optionally store) specific user input (PINs, passwords, credit card no, etc) and display specific user/server output data fields. This allows it to insert either pre-stored or on-demand passwords etc. into the outgoing stream. It also allows specific confirmation data fields from the server to be displayed e.g. a beneficiary account no., balance amount, etc. So the actual passwords are only available in the comms path and PC-side in SSL-encrypted form and any confirmation fields (beneficiary account no., balance amount) are confirmed to the user via the integrated display just before being SSL-encrypted, so they cannot be manipulated before going to the server. In terms of inserting a password, it automatically detects the standard HTML password form field and the corresponding response message (used by all secure web servers), and substitutes a dummy password for a real one. I have confirmed that this function works on all the major web sites e.g. PayPal, Amazon, E-Bay, Google, LinkedIn, etc. and at least four banks that I have checked (probably most). For displaying server confirmations, it might require a little help from the host server in terms of detecting the HTML display field, or else it would need to store a profile for each website (not ideal). However, it costs the host service very little to tweak a bit of HTML. I agree with you whole-heartedly about the user being in the loop. That is what my aim was with this device – The gadget directly authenticates the server through normal SSL and displays the server validity directly to the user via the integrated display. In Internet banking the main threat is the beneficiary account number. As long as the user is satisfied that the account number displayed on the device is correct then it cannot be manipulated other than by breaking the SSL crypto. In this it is almost identical to the IBM ZTIC. The difference is that it also allows the user’s password to be sent securely to the bank and therefore does not require the use of a client cert (so no private key needed)."