Есть ли смысл в соли из хеша пароля?

на Хабре уже было столько статей на эту тему, что даже отвечать стыдно.

Вообще есть довольно стандартное решение: использовать HMAC. Он специально разрабатывался для хэширования с солью. Естественно соль нужно генерировать рандомно и хранить рядом с хэшэм.

Обычно как… соль для каждого пользователя своя. Обычно это рандомная строка. При хешировании пароля с солью достигается большая криптозащита за счет увеличения времени перебора для получения нужной строки пароля + соли.

А можно сделать еще круче — можно использовать медленные алгоритмы. Тобиш скажем хеширование происходит в цикле. Если колличество итераций динамическое — то и это хорошо. И алгоритмы шифрования надо брать не быстрый md5 а что-нибудь помедленнее, например sha512. Это в свою очередь сведет попытки подбора хэша и генерации радужных таблиц на нет, ибо каждый вариант перебора будет происходить немыслимо медленно. На хорошей видиокарте с CUDA можно в секунду сгенерить миллиончик MD5 хэшей. А так хорошо если сотню сгенерит.

md5 уже давно не актуален, используйте bcrypt и не ломайте голову.

Для чего вообще нужна соль? А для того, чтобы md5(password)+salt было достаточно длинным, чтобы его нельзя было получить из хэша по предвычисленным таблицам. Таблица-то даст что-то, но нет никакой гарантии, что в конце будет именно ваша соль.

По-моему, криптостойкость одна и та же: тот же уровень противодействия перебору и та же защита от таблиц.

Я не силён в криптографии, но насколько я помню, соль использовали не только как способ увеличить строку пароля, а значит и стойкость хеша. Но и как безопасный метод передачи данных от браузера на сервер. Гляньте форумы готовые, движки итп, почему все хронят соли в базе, а не пишут алгоритмы динамических солей?
Скажем, вы пишите форум, решили использовать алгоритм с динамической солью, аля

substr(md5(md5 (<динамическая соль> . $password) . <статическая соль>), 0, 16);

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

Если с английским все ок, то советую почитать RFC 2898

Одна из важнейших целей засаливания паролей — не допустить одинаковых хешей в случае совпадения паролей.
Не хотите отдельную колонку — храните соль в той же в качестве префикса фиксированной длины. А еще лучше, продайте велосипед и возьмите crypt() — она умеет и соль, и bcrypt, и все хранится в одной колонке

Ну и как известно, одним из слабых мест md5 является наличие коллизий. То есть по простому два разных куска текста могут задавать один и тот же hash. Поэтому солить md5, при современных вычислительных мощностях - не шибко эффективно. Можно сбрутить также с помощью хеш таблиц. Да и куча онлайн сервисов предоставляет уже несколько лет свои услуги. MD5 последнее время используют больше для сверки контрольной суммы, а как и сказали выше смотрите bcrypt.