Thread by @AlecMuffett

OKAY, LET'S DO THIS!

https://twitter.com/Zaeyx/status/1084579423746109440

Ball and Chain A New Paradigm in Stored Password Security Benjamin Donnelly - speakerdeck.com/zaeyx/ball-and…

I'm going into this presentation blind, I haven't read this yet, but it's in response to a thread rebutting blog.benpri.me/2019/01/13/why…

So, apparently it's "Hashing" that's broken, rather than "the password paradigm as a whole"; personally I aver neither are broken because in the end anything that qualifies as "something you know" as an authenticator, is a password, and we'll never shuck that off. But I digress…

The next two slides present the argument ass-backwards, so I reverse them below to illustrate the issue: apparently "slower(presumably, strong) hashing" is some sort of gateway drug to weaker passwords. As opposed to "lack of enforcement of password entropy to a decided standard"

It's a kinda tragic argument to say:
- strong hashing enables shorter passwords
- shorter passwords are bad
- therefore strong hashing is bad

Next Slide, aaaaand, for some reason the authors — without supporting figures— assert that bcrypt/etc is a tremendous economic cost to "Mom And Pop"; similar, doubtless, to the tremendous cost of cryptography to support SSL nowadays, oh, wait, no, that was in 2004

The "Russian Mobsters" only have to hack passwords once - aside: interesting that I've seen no mention of "credential stuffing" yet? - but that's not really an advantage BECAUSE TYPICALLY THEY DON'T KNOW THE CIPHERTESTS AT-HAND INSIDE MOM&POP'S SITE.

If "Russian Mobsters" can pop a list of MomAndPop's ciphertexts, then MomAndPop either have REALLY BAD SHIT GOING DOWN ALREADY or else somehow they missed the "shadow password revolution" of 1995.

OH GOD NOW WE'RE UP AGAINST AN NATION STATE APT - I wonder if they're buying from @jmgosney or if they are building hashfarms out of repurposed Bitcoin miners?

Uhhhh... well, in order

1) Uh, business does not find this burdensome. This is a false premise. I would know.

2) see below

3) is just being needlessly dramatic.

#2 needs drilling into, at some length:

So far I am getting a big sense of "circular argument" from this paper; I fear that it has a cute/ish idea somewhere, and that the authors worked backwards for a rationale to support the proposition.

Notably: password cracking requires you to have the hashes to work on. (cont)

Gone are the days when you could do:
$ ypcat passwd
...and get a dump of all the crypt() hashes; now you have to pop a site and exfil the user database, crack it offline, and try replaying 1/more successful breaks at 1/more sites where the credentials might be valid.

It doesn't matter how clever one single site is, regards the quality of its hashing - or hash replacement - because if hackers want to get into a site they will use any of N viable credentials of M different users, all taken from OTHER SITES.

In short: the systemic risk nowadays is credential reuse from other sites, being used to infiltrate your own; this is an old problem, one which is typically framed as "am I trying to break a specific person's account, or am I trying to break 1+ entries in a whole password file?"

drama, drama...

<skips yet more drama>

HOLY SHIT: LET'S STOP SOMEONE EXFILTRATING YOUR CREDENTIALS FILE BY PUTTING A SITE-SPECIFIC TERABYTE OF SALT INTO A FLAT FILE AND MAKING THE PASSWORD HASH DEPENDENT UPON THIS.

(Presumably this is more computationally efficient than scrypt or bcrypt with a high work factor. No?)

Come the year 2029:
"640 Terabytes ought to be enough for any system to be secure..."

To be fair, part of the rationale behind the design of "Pluggable Crypt" (dropsafe.crypticide.com/article/1389 ) was so that next-generation hashes could have site-specific "$8$saltfile=/etc/foo$bar$baz..." hashes... but then that, as this, made a nightmare of distributed authentication.

[ ...but then Sun foolishly patented the mechanism, and then Oracle bought Sun, and that was the end of Pluggable Crypt. This is why patents are evil, people... ] /cc @solardiz

Oh gosh, so: there's a machine-specific 2Tb pile of crap, and {weird magic happens} and ... a substring is extracted, which is encrypted symmetrically under the user's plaintext password…

NOBODY IS TELLING ME HOW TO SECURE THIS 2TB FILE, OR WHAT I WILL DO WHEN THE SPINDLE DIES

...nor are they (yet?) telling me how I will deal with `[e-mail]` reusing her 2010 LinkedIn password for my site.

So it's a BAD SPARSE ARRAY BEING USED TO ADD WORK FACTOR TO PASSWORD AUTHENTICATION VIA "IOPS" rather than an algorithm being used to add work factor via maths.

Except it's machine-specific. Which you could replicate in scrypt() by using pluggable-crypt / similar site-local salt

Did I mention yet that "machine-specific salt" (worse: machine-specific 2TB sparse-arrays) are nightmares to (a) protect and (b) deploy/securely-replicate in a distributed environment with decentralised (ie: non-Kerberos) auth? Did I? Surely I've mentioned that by now.

I need a drink. <something, something, "diffusion", something>

<thinks: "…so I pop the box, seek randomly around the 2Tb file, and flip random bits. I can statistically disable percentages of the userbase with high certainty.">

<thinks: "…I wonder if this author has considered using words like `sharding`">

We interrupt this stream of consciousness to bring you this biting observation:

https://twitter.com/vathpela/status/1084595873076654080

There was once an operating system (possibly RSX-11?) where something similar to this latter was an issue, you could brute-force the password space by running the plaintext across a page-fault boundary and causing the auth routine to fault/not-fault upon checking characters:

1) Problem
2) Drama
3) ????
4) "1234" is now magically a "secure" password!

Because, apparently, it has IOPS work-factor, not CPU work-factor.

Summary: this is someone's vanity project; there will be no convincing them that their baby is ugly, or that it will have problems surviving in the real world. It swaps one kind of work factor for another, and pretends that doing so makes it "more secure". It's actually (cont)

Ball and Chain actually attempting to leverage the presumed security advantages of what I'll describe as "resource-intensive, site-specific hashes" - which would be beneficial in a world where we still barely had distributed user directories.

A site that implements "Ball and Chain" must perforce centralise all of its authentication on a single machine, whose data bus will burn with the IOPs of the thousands of users are re/authenticating; otherwise with replication of the 2Tb file, you'd dilute the value proposition.

It certainly would _work_ in much the same way that strapping a pig to a rocket WILL make that pig fly… but the results will not be pleasant. I think what matters to @Zaeyx is for someone to tell him that it will work …

...but that someone will not be me, because holistically it will not work.

It will not work in distributed environments, it will choke on bandwidth, it will raise operational risk (ie: death of 1 spindle = death of authentication; shard the data and you shard the risk)

And it will do nothing regards "credential stuffing" other than guarantee that an attacker who decides to try credential-stuffing a site which has implemented "Ball & Chain" will kill their entire authentication infrastructure by overloading the auth server.

( Incidentally, this is the same architectural fuckup that Sun achieved in "SunOS CMW" / B1-Secure SunOS, by implementing "pwauthd" centralised authentication to enable "three-strikes" lockout dropsafe.crypticide.com/article/11784 )

Finally: the author seems to lack a sense of irony. Compare and contrast: