Password hashing in Windows store app

I am writing an authentication Service for my app. Clients will connect via HTTP to this Authentication service to register or connect. After they have connected, they will receive a sessionkey, that they can use the encrypt TCP / UDP packets send to a secondary server. That is still WIP so, just to give you a big-picture-overview.

Serverside, i use BCrypt to hash the incoming password. and store that in a database. Serverside, I also use BCrypts Verify method to check any incoming password with the stored hash. So that basically works.

However, i naturally dont want to transfer an unhashed password over the wire. There is no BCrypt for Windows Store apps, but I found some MSDN sample code demonstrating how to use the new Cryptography API for Windows Store apps to hash a string, like so:

    public static string Hash(string password)
    {
        HashAlgorithmProvider provider = 
            HashAlgorithmProvider.OpenAlgorithm(HashAlgorithmNames.Sha512);

        CryptographicHash hash = provider.CreateHash();

        IBuffer buffer = CryptographicBuffer.ConvertStringToBinary(password, BinaryStringEncoding.Utf16BE);
        hash.Append(buffer);
        IBuffer hashedBuffer = hash.GetValueAndReset();

        return CryptographicBuffer.EncodeToBase64String(hashedBuffer);
    }

I plan to have various clients connecting to the service, not only windows store apps (also traditional Windows Desktop Apps). So naturally i want "one" way of hashing the password client side.

I need advice on additional security mechanisms i should implement and if hashing the password clientside using SHA512, like demonstrated in the code above, is "enough" when transmitting it to the server (which again hashes and salts it before storing).

Performing any kind of authentication without TLS protection leaves you with vulnerabilities. Bcrypt server side can give you limited protection against attacks on a stolen database. Sending (hashed) passwords unprotected over the line however should however be considered a security risk.

It should be possible to introduce at least a salt and a work factor to the client side. These parameters could be retrieved from the server side as they need to remain constant. Then you could use brypt client side. You say that it isn't available in the API, but that should not concern you. Bcrypt is just an algorithm and there will be implementations of it available online.

Brute force attacks and dictionary attacks would still be available to an attacker (eavesdropper), but they would be harder to accomplish, giving you limited protection for the users with moderately strong passwords (if the client code can be trusted).