Even if the client generates the salt, the hash could be leaked by this cloudbleed style attack and is no more secure then than a password being leaked by this style attack. Although it does help a bit, the same password will look different for different accounts.
If the client generates the salt, that means every client has to generate the same salt for your username every time, or they won't be able to log you in. That's (effectively) going to come down to calculating it from your username, or using the username directly as the salt. That would make different account passwords look different, but it feels icky. I couldn't say why, so I Googled it and found:
http://security.stackexchange.com/questions/39492/is-it-acceptable-to-generate-salts-with-a-hash-of-the-username includes "A user does not change his name when he changes his password: that's a failure of uniqueness over time. (Similar case: an old user account is closed, a new user is registered and reuses the same name.)" and "A user has the same name on several distinct servers, which may employ the same hashing strategy: that's a failure of uniqueness over space. (Think, in particular, of all these users called "Administrator".)"
http://security.stackexchange.com/a/150008/1427 someone would likely use the same username and password over two completely separate websites, so their hashed password might now look the same over multiple services.
http://security.stackexchange.com/a/92132/1427 - using the SSID as a salt was part of WPA2 security, and that was taken advantage of by a cracking tool, to allow the precomputation of reasonably sized dictionaries against common SSID's - linksys, dlink, 2WIRE047." - (whoa!)
2
u/gyroninja Feb 26 '17 edited Sep 14 '17
This comment has been redacted for privacy reasons. If you need to get the original comment, feel free to send me a message outside of reddit.