На самом деле madnet прав, пароль не должен передаваться на сайт в открытом виде, хотя предложенные способы авторизации тоже могут не прокатить
js - Злоумышленнику не нужен пароль, у него и так есть то, что просит у него сервер, это хэш
ssl - Может защитить только если злоумышленник начнёт снифать трафик, после того как браузер принял сертификат, иначе у него и браузера одинаковые шансы получить всю передаваемую информацию.

Лучший способ защитить пароль, это получить у клиента логин, достать из базы пароль, сгенерировать блок рандомных данных длиной примерно 256 байт, передать его клиенту, потом каждый из вас зашифрует его хэшем пароля, сервер положит хэшь в сесионную переменную,

Клиент обращается к серверу передовая логин: сервер достаёт из базы хэш пароля, генерирует блок рандомных данных длиной примерно 256 байт, возвращает его клиенту, тем временем шифрует его хэшью пароля, вычисляет из результата новую хэш и сохраняет её в сессионную переменную.
Клиент получает от сервера блок данных, так-же шифрует его хэшью пароля и так-же вычисляет из него новую хэш, с которой и обращается к серверу: сервер сравнивает полученные хэши и ауторезирует клиента в случае совпадения.
При смене пароля нужно снова провести всю эту операцию, за исключением того, что сервер уже знает логин.
При таком случае, даже если не использовать ssl и злоумышленник будет снифать весь трафик, ему потребуются сотни лет, чтоб сбрутить хэш от 256байтного блока, зашифрованного хэшью пароля.
Недостаток, время выполнения скрипта(ДоС-атаки), выход бан по ип.

Новый пароль, при смене пароля можно хэшировать и зашифровать хэшью старого, так как и клиент и сервер её знают.