php - Security Risks of Cient-Side Password Hashing -

i've read through abundance of blog posts, tutorials, , questions on proper password hashing. still have 1 question risks of client-side hashing.

i want salt & hash user's password on client's end in javascript, re-hashing & salting done on server , data sent on https (no plain text). hashing on client's side not use same salt or algorithm server.

logically server user's password hash, if data transmission in plain text wouldn't matter if password hashed or not attacker. if javascript read, exposing client-side hashing, is theoretically easier hash of known length , characters (0-9 & a-f) password of variable length , alphanumeric characters, upper & lowercase, , special characters?

for example, basic md5 hashing (i know md5 bad) on client side produces 128 bit (16 byte) hash. so, 16 possible characters, that's 16^16 = 1.84e19 possible hashes.

with password of length 8-10 characters, choosen alphanumeric or special character (by wikipedia's count, that's 95). gives 95^8 + 95^9 + 95^10, equals 6.05e19. can see more 3 times amount of passwords hashes (and number goes higher allow passwords long desired).

so wouldn't better not send hashed password client server?

as second part question, readings, understand tools such dictionaries can used logically reduce number of possibilities. can these tools narrow down results below 1.84e19 combinations of hash?

there no point hashing on client side. you've done made application javascript dependent.

an attacker can read transmission can submit hash directly server anyways, never needing typed password.

https protects users password on transmission. unless using wireless keyboard in range of clever attacker. heh.