There were some feedback in regards to how I created my server side salts and hashed my passwords in my "auth" file. This file contains the usernames, passwords, and authorization objects in Phosphorus Five, and is hence obviously crucially important for the security of the system.

Instead of going "all in" with thousands of hashes, using a "slow hash" method, I figured I could instead simply encrypt my auth file, with a PGP keypair, making the entire question completely irrelevant. Which of course arguably is a much stronger form of protection than hundreds of thousands of hash invocations, to create a "slow password" method.

By tapping into pre-existing Active Events from my code, I was able to add 7 lines of code to my "save auth file method" to encrypt it, and 7 lines of code to my "load auth file method" to decrypt it.

Then by adding some 2 dozens lines of code during initial setup of the server, I was able to have the PGP encryption keypair used to encrypt/decrypt my auth file, automatically generated during initial setup.

For those interesting in reading more, feel free to check up my blog. You can probably easily follow the trail to the code that implements these specific parts of Phosphorus Five if you browse around my newly acquired GitHub repo (Congrats MSFT BTW :) )

https://gaiasoul.com/2018/06/08/creating-hyperlambda-from-c/

The paradox about the above solution, is that what I am doing, is arguably to "create Hyperlambda from C#", which might sound funny, until you realize that Hyperlambda is simply some "syntactic sugar" around a Node C# class, allowing me to declare graph objects, and such dynamically parametrize my Active Event invocations ...

So instead of invoking a method directly, I do a Dictionary lookup behind the scenes, towards a Dictionary<string, MethodInfo> instance, which I then parametrize with a Node, which is simply a graph object / tree structure, which again allows me to create every single "method" in my system, with the exact same signature, allowing for "polymorphism" previously unseen in our industry ...

This makes sure that if an adversary is to somehow gain access to your actual password file, he'd still not be able to figure out its content, because he would also need a private PGP key to decrypt it. This PGP key is stored on your server, in its "GnuPG" storage, and even if he were to gain access to your private PGP key, he'd still need to know its AES password to be able to decrypt the private key.

All in all, providing (I'd say) much larger amounts of security for your passwords, than any amounts of "hashing algorithms" you could imagine ...