Obligatory: Don't roll your own crypto....
Based on your comments, you are asking not about any specific algorithm but if changing the hash input from
email+password provides any additional security.
email@example.com with password
My @wesome pa$$w0rd FTW YO!!!!
- So your input into the hash algorithm is now longer and less likely to be in a rainbow table and will take longer to get the complete plaintext
- As you noted in a comment, you could use the email as a salt, but probably better to use a random value and here
- Depending on some implementation details, email address could still be exposed; if you don't need the email address and will never use the value anywhere else, why require an email address instead of just a username. You may also run into issues with password resets or user management.
Make the server client authentication more efficient.
Also, for this last part:
Store the same hash on server and on client (only calculate the hash once on each side)
It sounds like you want to reduce server load by calculating the hash at the client and sending to the server? Then in your DB you lookup that value with the value in the database? This may not be doing what you think depending on implementation, for example are sending the hash over the network to be compared with the value in the DB; if the DB is compromised, the attacker has the input value so this is the same as doing a plaintext. You wants to prevent someone who gets the DB from being able to log in over the legit channel. Check out "Challenging challenge: client-side password hashing and server-side password verification"