One of the hardest problems you can face is getting a community of disparate developers to do the right thing at scale; sometimes the easiest solution for that is a monolithic integrated blob.
OP here. I am sympathetic, really I am, but the challenge then is a diversity of solutions tends to lack really good high quality security systems integration, meaning that data leaks differently. It's hard to have a high integrity solution which is an open standard and implemented equally well by all players.
I kinda agree (and I wrote the cited article) but as soon as you pick a number (2^40? 2^64? 2^80? 2^128?) you are painting a huge target on your forehead, when it's better to teach people that the point is the asymmetries (plural) and how you use, combine and compose them.
Author of original blogpost here; I am seeing a lot of discussion here about "what constitutes a public group?" and so I wrote this to help with the discussion. https://alecmuffett.com/article/15095
Indeed, I am not a patent lawyer; I am a crypto geek attempting to ascertain whether and to what extent this treads on current, and future, implementations of (edit: and enhancements to) the double ratchet algorithm. I believe that my tweets are pretty clear about that.
ps: other people have simply said to "read the claims", which is fine but does not help clarify anything.
Tor crypto guarantees an E2E connection to an entity possessing a key which matches the onion address which you sought to access. That's a benefit over DNS/TCP/BGP :-)
I get what you're saying, but it's an "all food will be cooked by machines"* argument; yes there are robochefs which can produce doughnuts, noodles, pizzas, etc; but there's an ever-expanding area of innovation and niche-filling that humans are really good at. Ask any Michelin-starred chef, or freelance software engineer.
Software engineering is not a zero-sum game where the AIs rise to the exclusion of humans - it's an expanding space.
*and then there's the meta: does using an oven qualify as cooked-by-machine?
Oh, the fun that could be had by starting a meme of "subliminal advertising for bots"; part-inspired by that "alexa buy a doll house" thing, we float a startup that will pitch audible product placement in YouTube/etc videos, in the hope that your Amazon Echo / Google Whatever will buy it for you. We make millions on VC and then skip the country. Deal?
> you also have to authenticate the HMAC-providing service
Yes.
But, to look at the Facebook approach, what is the risk surface presented by the HMAC service?
Done properly in the FB approach the password is irreversibly hashed before it arrives at the HMAC component, and cheaply HMAC'ed and returned, where the onion of hashing is completed.
It's good to bidirectionally authenticate access to the HMAC service, but in terms of protocol it strikes me as less critical than in your scenario.
Either the HMAC is done properly (in which case the eventual hashes will verify for legitimate users) or - if someone inserts a "fake" hashing service - the HMAC'ed results will not validate, and a bunch of legitimate users will experience login failure.
( edit: there's a risk of exfiltrating the input to the service, but it's meant to be a shitload of work to achieve any evil with that input anyway, which also can be shorn of user-metadata and other clues thereby making it a bit less valuable )
Maybe I have missed something but to my mind this threat scenario fails (by dint of fake services, exfiltration, etc) in a "safe" manner.
=== Now === consider your "authentication service" approach.
Plaintext goes into... what?
The real service?
A fake service that returns "true" in all circumstances?
A MITM that exfiltrates the plaintext?
Where do you put the root of the trust chain to this service? In an SSL Certificate? Pinned? From which CA?
Simply: I feel that in centralised password authentication services there are a lot more potential shenanigans to defend against.
Putting the authentication service into a nice tidy centralised box does not actually achieve much, and may have architectural downsides.
Not the least of which is: if it's wholly in a service, then you have to authenticate the service; that's not such a big step from "if the hashed passwords are stored in a directory, then you have to authenticate the directory" of course - but if we were to equate the two systems because of the need to authenticate the {directory, service} then the service-based solution still has the downside of being a CPU hotspot and a potential single point of failure.
We're much better at distributing directories of data which is self-protected / needs no special treatment, than we are at building humongous scalable "secure" services with an enormous TCB and a physically enormous attack surface / footprint.
Yes. If I was doing this, sure, I would do this again. Curiously I am a big fan of password hashing rather than all-singing, all-dancing authentication services.
>Last question first: large, but not Facebook large (I spent 10 years consulting on this kind of thing).
I just spent 3 years living it for 50h/week. Hence why I am taking a vacation.
>If it's there because that's how password hashing worked before your team got to it, that makes a lot more sense.
That. It wasn't even me, it was done before I arrived, but it was done by a team of geeks with a tremendous nose for making the best of the database that they had available to them without pulling the old password-migration "log in with one password, parallel-encrypt with a new algorithm, and save the new hashes" - thing, because some of those billion people might never log in again for years. You would never stop migrating people.
I remember internal pasword algorithm migrations at Sun, at least there you could force the matter for 10,000..40,000 people.
But you can't force everyone to migrate at FB scale.
>But then: it's not a "layer" of the onion so much as a sheen of dirt that needs to be washed off the onion. :)
You can take that approach, but - again - when will you finish the task? Whereas wrapping one algorithm in the next is a finite task which is completable in a reasonable amount of time.
>I get that your
...Facebook's...
>auth problem is huge. Yuge. So big you wouldn't believe it. I totally believe you. No, wait, I don't believe you, that's how big I know your authN problem to be: unbelievably huge.
Well channeled. :-)
>But here's the thing: you're already scrypting passwords. We're not debating whether you can use expensive password hashes. You already use expensive password hashes. I'm saying: the model where the KMS does a small bit of the password hash step and defers the heavy lifting to front-end servers seems like a suboptimal way to structure this:
>* You have to bill cycles from the front end to do it
Yes. 0.1% of frontend cycles. <blank expression> And?
>* You can't change password hashing without updating all the front-end servers
...which happens three times a day, weekdays, and is moving to moreso.
>* It's harder to track usage because it's spread across a zillion machines
>* You're more constrained in how you scale it (for instance, if you wanted to double or triple the work factor) because whatever your new scheme is, it has to fit with the existing front-end resources.
Yes. For a site with wildly heterogeneous architectures in front-end deployments, I can see how that might be a concern; but even AWS leads people to standardise on having approximately-the-same-kinds-of-hardware-doing-approximately-the-same-things.
>I'm not saying "wow, it's dumb that you
...Facebook...
>built it this way". I'm saying, if other people are reading this thread thinking about how to do it:
>* DO split authentication out into its own service
...or some component of it...
>* DON'T have that authentication service be "HMAC as a service" and then do scrypt on your front-end service
Why not?
>YOUR MOVE, ALEC MUFFETT. I keep going until you unfriend me on Facebook so I can't see you wincing about these posts.
Wince?
> I've assessed Facebook-large variants of this, though.