Реализация регистрации/входа/выхода пользователей на php

Вы довольно туго представляете как работает соль. Как минимум, для каждого пользователя она своя и хранится в базе рядом с хешем.

Вообще, при наличии ruby / python / JavaScript v6 / Cofeescript, писать на этом говноязычке может только толстый слон, который ограничен в выборе информации.

Не все от разрабов зависит. Если клиент скажет, шоб ему писали на битриксе то ни у тя, ни у менеджера особого выбора не будет. По этому тут твои хотелки не играют большой роли.

регистрация (шифрование пароля, активация профиля и т.п.)

можно использовать md5+соль для пароля, так же можно добавить ограничение в 20 символов (или больше). Если капча вас смущает, можно заюзать например невидимое для пользователя поле. если бот то он его увидит и заполнит. и с его помощью проверку делать.

восстановление/смена пароля

по почте, ну или по смс. (лучше первое)

А с какого хера клиент решает на чём будет написан продукт? Не кажется ли вам, что клиент много на себя берёт, особенно, если он не компетентен? Нафиг такие клиенты - шлите их лесом.

Смысл хранить соль с базой в одном месте? Утекла база - утекла соль.

А с какого хера клиент решает на чём будет написан продукт? Не кажется ли вам, что клиент много на себя берёт, особенно, если он не компетентен? Нафиг такие клиенты - шлите их лесом.

Большинство клиентов как раз хотят на определенной cms/cmf, а большинство из них как раз на php. И им насрать, что лендинг на битриксе - это тупость, а интернет-магазин на вордпрессе будет тормозить.

можно использовать md5+соль для пароля

уже заюзал password_hash() + уникальный для каждого пользователя локальный ключ

Если ты перезапустишь сервер, то все залогиненные юзеры, подозреваю, разлогинятся?

Об этом даже и не подумал)

Правильно сделал. Считаеться что для паролей использовать md5 с солью или без, уже не стоит.

Ну возможно как раз потому, что они платят. И хотят знать почему на этом (яп, цмс, фремворке), а не на другом. Если вы умеете переубеждать клиентов это очень хорошо.

1. Соли лучше всего генерировать для каждого хэша отдельно, это усложнит жизнь любителям перебора.

2. Утечка соли проблемой не является при достаточной длине ключа алгоритма шифрования.

3. Алгоритмы с более длинными ключами доступны всем и каждому, вместо вызова md5() можно впереть любую другую муть по своему вкусу, особенно если пациента беспокоит вероятность того, что кто-то потратит месяцы на разгадывание сотни пользователей из базы.

Вопрос исчерпан?

Ну да, а rails никто не ломает, потому что на нем сайтов и цмс нет ха ха

это в какой-то альтернативной реальности? завязывай с веществами, ну или наоборот не забывай принимать вовремя.

Не совсем. Соли ничего не усложнят для любителей перебора. Если они хранятся вместе с хешами паролей, конечно.

Простите конечно, но вы разве храните соли на удаленной машине, и получаете только по специальным проверенным сертификатам каждый раз?=)

Смысл хранить соль с базой в одном месте? Утекла база - утекла соль.

Если утекает база, боюсь, уже не имеет смысла заморачиваться за какую-то соль :D

Желательно алгоритм

Нет, серьезно? Что тут такого что нужно спрашивать на форуме? Проверяем пароль, ip, опционально юзерагент и верификация по смс, а дальше пускаем или нет - вот тебе и алгоритм. Пароль храним в хешированном состоянии без возможности декода, соль обязательна. Идентификатор сессии в куки, сама сессия в файле (дефолт, у тебя одна вебморда), мемкеше или бд (не дефолт, вебморд > 1).