
Horcrux: A Password Manager for Paranoids - lainon
https://arxiv.org/abs/1706.05085
======
iancarroll
I 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/mas...](https://github.com/HainaLi/horcrux_password_manager/blob/master/utils.js#L20)

[1]
[https://nodejs.org/api/crypto.html#crypto_crypto_createciphe...](https://nodejs.org/api/crypto.html#crypto_crypto_createcipher_algorithm_password)

~~~
analogist
Wow. 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?

~~~
stouset
As an infosec guy, I'm honestly getting really tired of this. Virtually every
time someone submits some new security tool to Hacker News, the author has
made trivial, catastrophic, and what should be _completely avoidable_ security
mistakes.

So for the hundredth time, if you're not a cryptographer or experienced
security engineer, _please stop releasing and promoting your crypto-related
projects_ before they have been vetted by someone who is. If this is something
you intend to release, ideally run the basic idea by someone qualified
_first_. By not doing so, you are doing _active harm_. Someone's life and/or
liberty may very well depend on the software you write, and when you fail them
in this regard you are ethically and morally responsible when these things are
taken from them.

~~~
zgotsch
Is there a good way to find people who are qualified to do such a review? This
paper was written by a Ph.D. student and professor of Computer Science at a
respected university. The professor teaches a crypto course on Udacity
([https://www.udacity.com/course/applied-cryptography--
cs387](https://www.udacity.com/course/applied-cryptography--cs387)). If they
don't meet the criteria for being cryptographers, I wonder how many people in
the world do?

~~~
dsacco
I'm going to push back on this a bit.

Thomas responded alongside this comment to talk about how academic
cryptographers are not necessarily qualified to implement original crypto, and
I largely agree with that; however, I don't actually think that's the issue
here. Rather I would pin this on a lack of _peer review._

I could be wrong, but I don't believe the author of this paper has had it
published or at least accepted in any journal or conference proceedings. Being
an eprint format with endorsement rather than peer review, you can expect
mistakes like this to happen often, even if the authors are ostensibly
qualified. When you submit original research for publication you generally go
back and forth a bit with adjustments as needed, and as long as there is
nothing egregious you don't need to redo it all.

In this specific case, I believe the author fully understands the issue (or
would, were it presented to them) and is fully capable of fixing it. A
qualified peer review would (hopefully :) have caught this and other latent
issues if an HN commenter did.

We see this in the broader mathematics and computer science communities, and
we especially see it in sub-disciplines like machine learning as well. It's
absolutely true that academic cryptographers should not be assumed capable of
rolling their own crypto _a priori_ , but in my (educated) opinion I would
certainly place far more weight on crypto developed by an academic
cryptographer than a software engineer without any particular training.

My platonic ideal for someone who is capable of developing original crypto is
something like an academic with a PhD in math or computer science (focusing on
crypto), who can develop software very well and who joins an applied lab for
crypto engineering and development (like NCC's) or a top cryptanalysis firm
like Riscure. Failing that, I'd probably place the most weight on someone who
had a lot of training in crypto engineering or practical cryptanalysis over an
academic with no implementation experience.

(I apologize if any of this is patronizing, I don't know what your background
or familiarity with the academic process is w/r/t peer review, etc).

~~~
forgotpwtomain
> A qualified peer review would (hopefully :) have caught this and other
> latent issues if an HN commenter did.

Would the qualified peer-review necessarily be reading the NodeJS code, or
just checking the theoretical soundness of the paper? I'm not so certain about
the former...

~~~
pbsd
Almost certainly not the former, no. At best the code would be "supplementary
material", which reviewers are not required to go over.

------
Nyubis
The 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
This sounds pretty cool! What I'm wondering, is how they are intercepting the
POST request and at what level?

~~~
kodablah
I 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
Out of curiosity, why is an AJAX post of JSON with credentials embedded bad
practice?

~~~
kodablah
Not 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.

~~~
baby
You can have the form submit to a real address when js is disabled, and
disable the form's behavior when js is enabled.

------
posnet
Repository of the project:

[https://github.com/HainaLi/horcrux_password_manager](https://github.com/HainaLi/horcrux_password_manager)

------
thinkMOAR
If 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
If you can audit the code yourself, you can treat it as code you authored.
(assuming you are competent to perform the audit)

~~~
thinkMOAR
True, 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
Make 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
Why 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
I 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

------
pishpash
Speaking of, why is there still no standard protocol for changing passwords?
That's 90% of the barrier to managing passwords.

~~~
ptman
There's several. LDAPv3 ja kpasswd are some examples.

------
crusso
I haven't looked at the security of it yet, but the name alone is a winner for
something you want to keep secret.

------
haberman
Why 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
I'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
I 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.

~~~
taeric
I primarily rely on resets, oddly. Drives me crazy when folks think I will
actively try to remember a password that I do not use daily for more than a
few days. If you have my email, you have everything you need to let me
initiate a reset.

Which, I fully cede is also a single point of failure. Basically, I think we
have plenty of weak links in the chains. I'm not too keen on codifying any new
ones. If you have something that increases the strength of everything, I'm
game to try it. And I am highly interested in studies that look into different
strategies.

------
w8rbt
I 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) ___

~~~
brbz
How could you generate passwords that satisfy arbitrary password constraints?
Say example.com has a 20 character limit, must contain a capital letter and
symbol (but not certain symbols), and can't contain a dictionary word. It
seems to me like your generator would have to have an option for each
constraint to satisfy, and you'd have to remember them at the time of
retrieval (unless you store the settings).

Is there a different solution?

~~~
rkeene2
I solved it in WebPass[0] by encoding the constraints for special (i.e., not
generic) sites into rules associated with a unique ID, then only valid
password are considered.

[https://webpass.rkeene.org/](https://webpass.rkeene.org/)

------
nickpsecurity
For 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)."

------
1ba9115454
Perhaps 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
I 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
Yep, 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.

------
EGreg
Too 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)

------
cbhl
Does anyone else think it's cool that Harry Potter fans are now old enough to
be getting crypto papers published?

~~~
xfer
You are assuming Harry potter fans are all ≤12?

~~~
cbhl
Well, I assume that there's a bell curve, with the median around 8, because I
was eight when the books were first published in the US. (Scholastic is often
associated with publishing kids books, too.)

------
stinos
_a password manager that is designed holistically_

Honest question: what does 'holistically' mean in this context?

~~~
dave1629
(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).

------
tIONTamINariciA
It's fun that the authors readily admit that the idea is for paranoid people.

[https://xkcd.com/538/](https://xkcd.com/538/)

~~~
deno
Being vulnerable to blunt objects does not mean you shouldn’t care about other
attack vectors.

~~~
tIONTamINariciA
Overly 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
> 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.

------
danjoc
Sticking 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
What 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
I 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
That 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.

~~~
adrianratnapala
Yikes! Last time I looked, the intercontinental nuclear launch codes of any
major power have not yet been proved to work.

But OK, I assume they still pass whatever dry-run test procedures exist. But
if it is true that they are based on floppy-disks, then I don't think sticking
with them is a net win for reliability and safety.

Bits rot, especially on floppies. So if they are still using them they have
created procedures for refreshing the bits from backups. By now the floppies
might be little more than ceremonial objects inside the systems that _really_
determine the launch procedure.

And those systems would have evolved informally over time and might be ever-
changing, poorly understood and poorly tested.

------
X86BSD
I use hashicorps Vault for keeping all my secrets. And never looked back.

