> Ну... SHA512 симметричный алгоритм шифрования. Т.е. salt на сервере (сайт) и клиенте (браузер пользователя) будет одним и тем же.
> Получить salt с клиента по сложности равносильно получить пароль в открытом или хэшированом виде, т.к. хеширование с применением сальта будет происходить на клиенте (JavaScript или Flash-плеер)
> Смысла в этом нет.
> Другое дело можно применить асимметричное шифрование, когда вместо сальта будет использоваться открытый ключ.
> И тут... мы приходим к тому что это уже сделано. C помощью SSL >3.0.

Я же писал, ssl это симметричное некриптостойкое шифрование сеансовым ключом.
Соответственно если есть возможность перхватить трафик и позиционировать ваш открытый пароль в шифрованном трафике, то ssl ломается, если позиционируем в трафике хэш пароля известного алгоритма (msd5), то опять ломается.

> Асимметрично шифровать пароль, чтобы потом его передать через HTTPS где шифрование всего трафика (а не только пароля) работает по тому же принципу, не слишком ли извращенно и параноидально?

SSL несколько для иных целей сделан, чем для передачи паролей.

> Безопасное соединение на то и является безопасным, т.к. HTTPS с применением современных сертификатов безопасности гарантирует с большой достоверностью безопасность передаваемых данных. Шифрование используя TLS

Опять же сертификаты. Я не специалист, но вроде бы удостоверяется только одна сторона — сервер. Мы же передаем данные с клиента, то есть с неудостоверенной сертификатами стороны. И даже если бы удостоверялся клиент, телепат-перехватчик тоже может быть удостоверен.
---
Проблема в том, что все эти заборы-огороды создают видимость защищенности, а на самом деле одна маленькая дырка все ломает.