Эрик Микоян, для решения задач, на которых не нашлось ответа в других источниках информации. Поймите, авторизация и регистрация пользователей разжевана и пережевана уже миллион раз на всех возможных языках программирования.
Эрик Микоян, Кроме того, ваш вопрос звучит слишком обобщенно. На каком ЯП вы планируете реализовывать авторизацию? С помощью каких инструментов? Вы хотите написать свою собственную систему авторизации или использовать готовые механизмы (например, OAuth)? Вы не удосужились написать в вашем вопросе абсолютно ничего. Какой ответ вы ждете?
Создать базу с пользователями. У каждого пользователя должен быть уникальный логин (можно проверить генератором и проверочной рекурсией). В базе хранить нужно не сам пароль а хэшированный или зашифрованный. При входе пароль нужно опять хэшировать и сравнивать хэши пароля в базе и на странице входа. Остальные поля в базе можешь сам составить. У меня это обычно: id, email, login, phone, is_verified, status, passhash, is_deleted
Хэшировать надо на клиенте или на сервере? Или и там и там? В первом случае легко узнать метод хэширования, во втором можно перехватить пароль пока он летит к серверу.
Pardon Me! Where Do I Find 4giveness?, уникализировать нужно логин, а не пароль. А метод хэширования можно использовать стандартный, с применением соли. Данный человек спрашивал о том как организовать простую систему авторизации, а не новороченный велосипед. Вы полностью правы в своих суждениях, если речь идет о "супер правильной" системе авторизации и я согласен!)
#, ключевая фраза "стоя у банкомата". В случае когда мы знаем метод хэширования, нам не нужно спрашивать сервер каждый раз, мы берём перехваченный хэш и перебираем у себя сколько хотим.
Сергей Шиловский, ну раз пошла такая пьянка (с) зачем вообще подбирать?!!.. отправляйте хеш!!! (хотя на это и нужен HTTPS)
любой подбор обнаруживается*, а потому и легко блокируется. если опираться только на пару логин/пароль по HTTPS, в принципе, не велика разница что хранить. но по мере изучения вопроса - хеш лучше, особенно если это хеш от пары логин/пароль, а еще лучше от большего количества факторов, особенно меняющихся от сеанса к сеансу и/или наследующих что то от прошлого сеанса ;)))
ps грамотная организация хешей - защита не только от утечки на пользователе, но и от компрометации самого сервера
* - ломовой подбор безпонтовый. а скрытный подбор не приемлемо долгий
У каждого пользователя должен быть уникальный логин
За это надо бить лопатой по яйцам. Используйте почту в качестве логина. Не надо городить великов.
Если у вас перехватывают трафик на пути к серверу путем подмены сертификатов, тот тут вам уже ничего не поможет за исключением двухстороннего шифрования с обменом ключами по надежному каналу.
Я думаю, вы врядли собираетесь встречаться с пользователем, чтобы обменяться ключами.
тут вам уже ничего не поможет за исключением двухстороннего шифрования с обменом ключами по надежному каналу.
Я думаю, вы врядли собираетесь встречаться с пользователем, чтобы обменяться ключами.
Надёжный канал не нужен, встречаться с пользователем для обмена ключами - тоже.
Задача двухстороннего шифрования решается через Доказательство с нулевым разглашением
ну раз пошла такая пьянка (с) зачем вообще подбирать?!!.. отправляйте хеш!!!
Сам хеш даст доступ только к этому сайту, а вот с паролем можно получить доступ ко всем остальным, не у всех разные пароли на разных сайтах.
Со всем остальным согласен, я имел ввиду простейшую систему, где просто берётся хеш от пароля и в лучшем случае соль, т.к. автор вряд ли сразу начнёт городить супер защиту.
Philipp, практический пример на Хабре, и rfc5054 к нему.
Получив слитую базу (или перехватив процесс регистрации пользователя на сервере), максимум что сможет злоумышленник - представиться сервером и авторизовать пользователя.
Средний
