> Furthermore salts larger then the final output side offer no additional security. If you have 256bits of output, you only need 256nits of input. Larger inputs technically risk reducing the entropy of the final output.

If I understand that correctly, then for a 256bit hash with an internal state of 1024 bit, initialized to a fixed and public nothing-up-my-sleeve set of values, increasing the salt from 256 bit to 1024 bit - going from 1 random bit for every 4 known bits to 1 for 1 - reduces entropy.

If from there we assume that the hash uses a Merkle-Darmgard block construction for which it is proven that the only loss of entropy comes from the compression function, this would - for me - mean that the chosen compression function loses more entropy on random bits than on the initialization vector, which makes it special, although it is supposedly chosen to be not special in any way.

This confuses me, but I'm just a sysadmin not a cryptographer, so that is ok. Do you have any links for me to follow up on this?

That's a lot to respond to at once. :-)

I will say it's important to understand how the Salt we return is generated. We use a massive pool of data as effectively the internal state of a hashing function. This means you need all the data in order to perform the same calculation.

The value sent to us is just the hash of a salted hash. By itself it is useless. The value we return is Salt2 -- also useless on its own. This is very purposeful. If the TLS channel is owned, nothing of value is lost. The Salt1 is still private on the site's server, and no passwords can be cracked without it.

Availability is a legitimate concern. Similar to SMS multifactor, this is an added 3rd party dependency. We direct peer to many of our customers and route over private IP space to avoid a potential DDoS.

      I will say it's important to understand how the Salt we return is generated. 

Not in the slightest. It is the HASH of a HASH of a HASH. There is no academic rigor to support this gives you any additional security. And a lot of academic rigor that states it is a moot operation.

      The Salt1 is still private on the site's server, and no passwords can be cracked without it.

1) If you argue any SALT is private... Then WHY EVEN USE SALTS?!?! If something on the database is private/secure why not use clear text passwords? The whole idea of using SALT+HMAC is that NOTHING stored is private/secure. You cannot EVER assume SALT(s) are private.

2) Cracking the password is irrelevant. All that is needed is:

      SALT2 + Web transferred hash

Then the credentials are gained. Yes learning somebody's password, or several million's peoples password is a fun experiment but gaining access to the website is also an attack vector, one your system is making easier.

For a traditional HMAC/Scrypt/Bcrypt recovering the password is a critical part of this as the authentication mechanism is a single black box program. Input is SALT+Password+Hash. Output is an auth token.

The system you describes breaks this dichotomy. No longer must the password be broken to gain access.

:.:.:

       Availability is a legitimate concern

An extreme one

       Similar to SMS multifactor

SMS Multi-factor is depreciated. Faking SMS from an arbitrary phone number is extremely trivial in practice. Look into Dave Kennedy's work on social engineering.

Multi-Factor auth is best done via Tokens or TOTP.

       We direct peer to many of our customers and route over private IP space to avoid a potential DDoS.

So instead you want to just install your own box on the customers network? This opens up even more headaches about managing and authenticating your access to their private LAN. Then you get into patching agreements, possible OS limitations, security audits. This is a horrible solution for both parties.

I'm sorry if I'm not explaining it right, there's definitely something lost in transmission here.

We are keying the hash (HMAC), keyed by a value derived from the data pool. Please don't take the 4 line pseudo-code too literally.

The value stored in the database (Hash2) can only be used to verify a password if you can also complete the blind hash which is blinded by the data pool.

I can say, this approach has been vetted by both well known cryptographers (Solar Designer, Scoob) as Passwords^15 as well as industry crypto wonks at MITRE and elsewhere. It's certainly not snake oil.

The salt kept on the site's server means that the site must be breached in order for a successful attack to be mounted. It's why we call this a fully additive layer of security. You need the Salt from the site, and the entire data pool from us, to mount an offline attack.

2) Why would you say that? It's absolutely not the case that you can login with Hash1 and Salt2.

If you intercept Hash1 and Salt2 then you may know Hash2 but you still cannot login, and you cannot try to crack it without Salt1. Again, this is all assuming TLS is broken in which case you can just inject your own JavaScript onto the page and steal passwords in clear text.

By direct peering I mean programs such as AWS DirectConnect which gives us 10Gbps on their network and private IP access to our peers. Nothing to get too excited about.

I'll be back online in about an hour if this still doesn't answer the basic questions around the security of the construct.

EDIT: I do not mean to say solardiz or sc00bz have personally endorsed our product. Only that we have all worked on and published write ups on the same general approach (using large data pools with bounded network links) to solve the password security problem.

While security does not rely on simplicity, a simple system is much easier to reason about security. What you add is a whole stack of complexity through multiple hashes, entropy generation (on your end), and network transport (TLS).

There's no way you could convince me to use your system over a basic KDF implementation. The only people you're going to convince to use this protocol is someone who doesn't have experience in the field, which is why I'd consider your solution snake oil.

I've talked to many cryptographers in the field. Universally they appreciate the solution for its simplicity. We don't use any new crypto - the whole construct is based on a CS-PRNG, hashing and HMAC.

You talk to this service just like you talk to any service over the LAN or WAN. Through an encrypted channel. Goes are the days when you can just dispatch a request over the LAN and assume you're good. We are happy to setup dedicated machines with spiped as we are using TLS.

But certainly you look at solutions like CloudFlare or even dare I say Firebase, and the industry has moved far beyond your level of paranoia.

I don't want you to use it instead of your basic KDF, but in addition to / after your KDF.

13 million Americans had over $15 Billion stolen last year in cyber-heists and almost 70% of those attacks were using a stolen password. The basic KDF is not working, and it's time to stop blaming the user for not having 69 bits of entropy on their password and start giving companies the tech they need to actually secure their passwords.