Middle level
1) Соединение защищено по https?
Если нет, то у меня для вас плохие новости - ваш логин и пароль может быть легко перехвачен между браузером и сервером. Публичными вайфаями, на уровне провайдера или даже на уровне уязвимого роутера, которым вы пользуетесь. Весь сайт в теории может быть по http (лучше бы нет), но форма логина и регистрации - только https. Но даже в таком случае - токен аутентификации сможет быть перехвачен (но не логин и пароль). Весь сайт обязан быть https.
2) 🚩Нужно ли при неудачной попытке регистрации писать, что такой пароль уже существует в системе?
Конечно нет, это может говорить хакеру о том, что пароли хранятся в plain text и уже какой-то пользователь точно существует с таким паролем. Вы должны выдавать МИНИМУМ информации всего, что касается безопасности. Есть шуточная версия в виде сообщения "такой пароль уже используется пользователем %username%". Шутки шутками, но возможно где-то и написали.
На aws к слову максимальный уровень - после ввода логина, сразу же запрашивают пароль И второй фактор, т.е. злоумышленни даже может узнать что именно не подошло.
3) Если попытка входа была неудачная - нужно ли логировать данные формы для дальнейшего изучения проблемы?
Нельзя. Максимум - логин. Пароль - нельзя. Был уже ни один и не два инцидента, когда у крупных сервисов ломали системы логов и вытаскивали пароли, которые логировались в plain text (лог шёл всего реквеста).
4) Если хэшировать пароль, то как? Каким алгоритмом? Хорошо, если мидл назовёт парочку, допустим md5 или sha-1.
Вопрос чем они плохи - уже скорее сеньорский левел. Но для мидла и такой ответ ок. Так же плюсом в карму будет рассказ о том, что хэшировать нужно с солью. SALT - это что-то, что добавляется к паролю чтобы уменьшить риск его обратного преобразования в случае утечки данных. Многие популярные пароли уже находятся в базах (так называемые Rainbow tables и хеши к ним подобраны, поэтому реверснуть какой-нибудь md5 без соли - дело несложное.
Post #173
374