For password security reasons we are using a double hashing approach in SlideWiki. We're hashing the password client-side at the users browser (thus the plain text password never leaves the machine) and carry the hashed password to the user-service for user-registration/-login. So all the user-service ever got, was the hashed password. This makes it impossible to login directly at the user-service with an unhashed password (e.g. plain text) or the wrong hash. But if you register directly at the user-service with a plain text password, you can also login at the user-service with the plain text password, but you will not be able to login through slidewiki-platform, as it hashes the plain text password before sending it to the user-service.
Workflow: In the users browser (plain text password → hashPassword() → hashed password → send to user-service) → at the server (hashed password → hashAgain() → save/lookup in the database).
Why we hash at the client-side: the plain text password never leaves the users machine, thus the plain text can't be stolen at the transport channel. As it's impossible to map a hash back to the original plain text, the attacker is not able to get the users plain text password. So even if we have a Man in the Middle attack, plain text passwords are safe. Nevertheless, the attacker will be able to login at the user-service as the spied user.
Why we hash at the server-side: in case the database gets stolen, an attacker can't use the saved hashes to login at the user-service, as the user-service would hash the double hashed hash, thus comparing a three times hashed hash against a double hash. This won't work/match.
Example:
Plain text password: 12345678
Salt: ABCDEFG
1. The SlideWiki client hashes the password (+Salt) at the users browser:
>> echo '12345678ABCDEFG' | sha512sum
44fc7cb7b922b651324c2c63144140877d4cf08c789ee2bf1d41eb4eaff009cd73fdd5a584bd9fc13088635e9235fdd8dda5027ee64198263a60cea762e59f21 -
2. The SlideWiki client sends the hash to the server
44fc7cb7b922b651... → http request → user-service
3. The user-service hashes the recieved password again
#notice the appended SALT
>> echo '44fc7cb7b922b651324c2c63144140877d4cf08c789ee2bf1d41eb4eaff009cd73fdd5a584bd9fc13088635e9235fdd8dda5027ee64198263a60cea762e59f21ABCDEFG' | sha512sum
6d7d64e2cf84eea64260b25504a8d445e59dd71014fd0dd6b66c18ed437459529cc3c56aca2bfe52b3687e70bc1aea2fe1f5c607eab4e219b6d2787c2f99ef28 -
4. This hash is saved in the Database in case "register" was called, or used to login a user (and thus compared to the stored hash).
Why we use a publicly available Salt: in order to prevent the so called rainbow table attack. There are precomputed tables available for any hash methods, thus finding the plain text of a hash (without a salt) is fairly easy. In case (and we do) a Salt is used, the rainbow table needs to be recalculated. As it takes a ridiculous amount of time to generate the data for enough hashes, it's safe to publish the Salt.
What's about third-party clients for SlideWiki: a user using the third-party client, that won't hash with the same hash function and salt at the client-side that we use at the official client, will not be able to login with our official SlideWiki client, as the data provided to the user-service is different. This forces third-party clients to keep passwords secure. As the used hash function and salt are public data (see Github Repository), it's possible for them to implement it the exact same way we do.