>Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same passwo

>Firstly, the salt should be changed per user, one of the reasons for salting is that given a large enough user base, a lot of users will choose the same password, This is only an issue if the hash can be reversed. The entire raison d'etre for salts is to prevent hash reversal via precomputed tables. >There's essentially rainbow tables computed for "123456"+RandomSalt iterating over salts Rainbow tables are already enormous-- in the hundreds of GB range for 9+ character passwords. Iterating over the range of possible salts makes the storage requirements untenable. As long as you choose an unlikely or unique salt which could simply be your site's FQDN or its MD5 hash, this isn't an issue. No one is going to have a rainbow table for md5(yourFQDN.com) as salt. >which means that you'll have to use HTTPS underneath all of this You should but it is not necessary for secure password transmission. This is a solved problem for decades now. >Once you are doing all of this over a HTTPS connection, there's simply no point in doing it, you are just increasing the attack surface for no substantial gain in security. Layered security is a thing. Root CAs can be compromised, trusted CA stores can be tampered with, SSL busters like CRIME or BEAST can show up on the scene, someone can gain network access behind the SSL termination.... Layered security is why when LastPass got popped nothing of value was lost, because they used legit KDFs and salts. There's no increase in attack surface for using an HMAC behind SSL. If SSL is your only line of defense, your security model is stuck in the 2000s.