Comments 21
Вы знаете, все, что есть в статье и даже больше элементарно гуглится (хотя даже начинающий веб-разработчик про все это слышал)? Особенно момент про хеширование пароля.
Кстати, требовать вводить пароль два раза при регистрации и смене пароля — это пережиток прошлого. Если человек опечатается — а такое случается редко-редко — всегда можно воспользоваться восстановлением пароля еще раз.
Из то же оперы следующие сценариями, которые долгое время считались единственно правильными и возможными:
1. Иметь длинную форму регистрации.
2. Требовать вбить пароль при регистрации 2 раза.
3. Иметь длинную форму регистрации и сбрасывать поля ввода пароля и подтверждения, если валидация других полей не прошла.
4. Требовать вбить 2 раза адрес электронной почты.
5. Не давать пользоваться сервисом, пока в письме на ссылку не нажмешь.
И т.д, Сегодня большинство пунктов — дикость. Желательно иметь вообще 2 поля при регистрации и логине — почта и пароль. Плюс социальные кнопки по желанию.
Из то же оперы следующие сценариями, которые долгое время считались единственно правильными и возможными:
1. Иметь длинную форму регистрации.
2. Требовать вбить пароль при регистрации 2 раза.
3. Иметь длинную форму регистрации и сбрасывать поля ввода пароля и подтверждения, если валидация других полей не прошла.
4. Требовать вбить 2 раза адрес электронной почты.
5. Не давать пользоваться сервисом, пока в письме на ссылку не нажмешь.
И т.д, Сегодня большинство пунктов — дикость. Желательно иметь вообще 2 поля при регистрации и логине — почта и пароль. Плюс социальные кнопки по желанию.
Дискуссия на тему два раза вводить пароль при регистрации или один раз может получиться действительно эпической. И главное все останутся при своем мнении.
Желательно иметь вообще 2 поля при регистрации и логине — почта и пароль
Или можно пойти еще дальше, и оставить 1 поле для регистрации — почта. А пароль генерировать и отправлять на почту. Я так в одном сервисе делаю.
Требовать вбить 2 раза адрес электронной почты
За такое вообще убивать хочется. Особенно, когда некоторые извращенцы яваскриптом Ctrl+c/Ctrl+v в этих полях блокируют.
За такое вообще убивать хочется. Особенно, когда некоторые извращенцы яваскриптом Ctrl+c/Ctrl+v в этих полях блокируют.
Мы ведь тоже так делали 2 года: пупблика на сайте была непродвинутая и ошибки в почте были часто. Причем мы сразу просили данные карты, и потом снимали с людей денег. И получалось: есть аккаунт, с которого идут деньги, но которому не удается отправить подтверждение. Часто люди платили месяцами и пользовались. Но иногда человек получал очередной платеж, видел его в банке, но не узнавал и заказывал chargeback.
Одно время это был основной источник чарджбеков, и мы пробовали разные варианты. Нужно было и денег не потерять, и на счетчик в платежной системе не вставать. Вариант «следить за тем, что пользователь имеет неподтвержденный мейл и отменять ему подписку» сильно бил по карману. Вариант «вводить почту дважды» снижал конверсию, но в результате по деньгам мы теряли меньше.
Потом через два года попробовали другой вариант: проверять популярные почтовые домены и сравнивать юзернейм в адресе почты и в нашей системе и подсказывать, если есть подозрения. Оказался лучшим со всех сторон.
Причем мы сразу просили данные карты, и потом снимали с людей денег
Тоже, на мой взгляд, антипаттерн. Сразу сообщать данные своей карты какой-то левой системе? Кроме того, если деньги не сразу снимаются, и есть, например, триальный период, то лучше позволить пользователю заплатить тогда, когда это будет нужно. И если ему это будет нужно.
проверять популярные почтовые домены и сравнивать юзернейм
Вот это уже хороший вариант. Но блокировать возможность копипасты — это зло. Если пользователь настолько непродвинут, что свой адрес ввести без ошибок не может, то он и Ctrl+c жать не будет. А остальных будет раздражать.
Тоже, на мой взгляд, антипаттерн. Сразу сообщать данные своей карты какой-то левой системе? Кроме того, если деньги не сразу снимаются, и есть, например, триальный период, то лучше позволить пользователю заплатить тогда, когда это будет нужно. И если ему это будет нужно.
Конечно, антипаттерн. Мы столько копий наломали с руководством, чтобы от него избавиться!
Там вообще много таких скользких мест было, которые зародились на раннем этапе, когда введение одного такого антипаттерна позволяло платить зарплату еще одному члену команды. Потом, когда сервис стал крупнее, все это было уже не нужно, но уговорить людей получать на, скажем, сто тысяч долларов в месяц бывает тяжело.
Сейчас, насколько знаю — меня в той команде уже нет — остался только один косяк: на сайте указан номер службы техподдержки, работающей 24/7, но за номером робот, который регистрирует звонок. Поддержка потом переходит в режим общения по email и звонит клиенту только если он грозит чарджбеком.
А как насчёт варианта при клике на «Зарегистрироваться» возвращать фокус на поле с адресом электронной почты и просьбой подтвердить адрес?
Генерировать псевдослучайную последовательность зашифровав информацию об id пользователя, типе сообщения и времени жизни сообщения в самом сообщении.
Мне кажется, и в данной логике мы имеем нехилую такую дыру в безопасности?
Меня всю жизнь учили, что за пределы сервера не должна выходить никакая информация, даже так или иначе зашифрованная. К тому же не думаю, что там будет, что то серьезное по шифрованию…
За пределы сервера постоянной выходит зашифрованная информация, например при обмене данными по протоколу TLS (SSL).
В статье не нашел ни одного упоминания, о том, что используется, какой либо протокол кроме умолчательного http
И не надо мои слова передергивать. Сервер не должна покидать информация о пользователе, естественно картинки и HTML это не касается…
А то встречались мне «сервисы» где в куках хранились пользовательские логин с паролем… при этом логин был не шифрованный, а пароль md5 один раз, что по радужным таблицам раскалывается на раз, два, три…
Или когда в адресной строке передается как элемент урла что то вида \ТРИ СИМВОЛА\ID\ПЯТЬ СИМВОЛОВ\логин пользователя\ЕЩЕ ПЯТЬ СИМВОЛОВ\
А зная идентификатор пользователя, и его пароль, попытаться пропихнуть SQL иньекцию пусть и слепую на таблицу users… так руки и чешутся… особенно если отсутствует привязка хотя бы к сессиям…
В общем надеюсь я объяснил какую информацию и в каких случаях я имел в виду.
И не надо мои слова передергивать. Сервер не должна покидать информация о пользователе, естественно картинки и HTML это не касается…
А то встречались мне «сервисы» где в куках хранились пользовательские логин с паролем… при этом логин был не шифрованный, а пароль md5 один раз, что по радужным таблицам раскалывается на раз, два, три…
Или когда в адресной строке передается как элемент урла что то вида \ТРИ СИМВОЛА\ID\ПЯТЬ СИМВОЛОВ\логин пользователя\ЕЩЕ ПЯТЬ СИМВОЛОВ\
А зная идентификатор пользователя, и его пароль, попытаться пропихнуть SQL иньекцию пусть и слепую на таблицу users… так руки и чешутся… особенно если отсутствует привязка хотя бы к сессиям…
В общем надеюсь я объяснил какую информацию и в каких случаях я имел в виду.
Вот честно — ненавижу когда логин и эмейл это одно и то же. Эмейлов у меня штук 5, а логинов всего 2-3 (третий — небольшая модификация первого).
Да и к тому же особенно касается сайтов с публичными данными (форумы, комментарии) — помещать там эмейл ну просто глупо.
Минусуйте. :)
Да и к тому же особенно касается сайтов с публичными данными (форумы, комментарии) — помещать там эмейл ну просто глупо.
Минусуйте. :)
Ну тут слегка неоднозначно. С одной стороны — да, иногда удобнее иметь логин. Привычнее как-то, что ли. С другой стороны, зачем плодить лишние сущности? Если email нужен все равно, а однозначно идентифицировать можно и по логину, и по почте, то зачем требовать их оба? Да, тот же джанго по умолчанию предполагает, что может быть несколько пользователей с разными логинами, но одной почтой, но на практике я что-то такого не припомню.
А еще, поработав с одним сервисом, ориентированным на «технически неграмотных» пользователей, я с удивлением узнал, что большинство уже забыло (или никогда и не знало), что такое логин, зачем он нужен, и вообще, что-вы-мне-мозг-парите-непонятными-словами.
А email можно и не раскрывать другим посетителям. Если предполагается функциональность комментариев и пр., то можно в профиль добавить возможность придумать себе ник.
А еще, поработав с одним сервисом, ориентированным на «технически неграмотных» пользователей, я с удивлением узнал, что большинство уже забыло (или никогда и не знало), что такое логин, зачем он нужен, и вообще, что-вы-мне-мозг-парите-непонятными-словами.
А email можно и не раскрывать другим посетителям. Если предполагается функциональность комментариев и пр., то можно в профиль добавить возможность придумать себе ник.
Ну, достаточно «логин» назвать «именем пользователя», чтобы обычные пользователи начали понимать о чём речь, ну и сбоку написать небольшое пояснение о том, что это такое и зачем нужно :)
Просто дело в том, что именно входить по длинному эмейлу куда как менее удобно чем по (обычно) не в пример короткому логину. Ну и не говоря о том, что эмейлов таки может быть несколько, о чём я и сказал ранее. :)
Просто дело в том, что именно входить по длинному эмейлу куда как менее удобно чем по (обычно) не в пример короткому логину. Ну и не говоря о том, что эмейлов таки может быть несколько, о чём я и сказал ранее. :)
Сначала так и было написано: «Имя пользователя». Туда пытались прилежно ввести что-нибудь вроде «Иванов Петр Михайлович». И искренне удивлялись, что с таким логином зарегистрироваться нельзя. И не читали сообщение об ошибке, а начинали заваливать письмами техподдержку. То же самое касается и «написать небольшое пояснение о том, что это такое и зачем нужно» — не читают даже то, что написано большими буквами в красной рамке (вот правда, для меня это абсурд — почему человеку проще написать 20 предложений, чем прочитать одно?). Поэтому решено было идти по пути наименьшего сопротивления и выкинуть это поле.
Кому лень вводить (как мне, например) длинные email и пароль, тот может запомнить в браузере или пользоваться keypass'ом.
Кому лень вводить (как мне, например) длинные email и пароль, тот может запомнить в браузере или пользоваться keypass'ом.
Всякие запоминалки в браузерах и Keepass-ы хороши, пока не нужно заходить в свою учётку с другого компа/мобильного устройства/микроволновки/you say it.
А так с вами солидарен, что бред, про не читающих сообщения пользователей. Хотя по мне так стоило таки разрешить логин формата «Иванов Пётр Михайлович». В чём собственно проблема-то? Ну и показывать «красные рамки» только если есть повторки, да.
А так с вами солидарен, что бред, про не читающих сообщения пользователей. Хотя по мне так стоило таки разрешить логин формата «Иванов Пётр Михайлович». В чём собственно проблема-то? Ну и показывать «красные рамки» только если есть повторки, да.
В чём собственно проблема-то?
Например, проблема возникнет, когда этот пользователь поставит 2 пробела между словами. Или напишет «Пётр» вместо «Петр». Или напишет «Петр Михайлович Иванов». А он что-нибудь из этого точно сделает, зуб даю.
Да, с другого браузера/компа — немного неудобно будет. Но, во-первых, мы же говорим не о пароле (он-то и так супер-сложный и мега-криптостойкий), а о разнице между логином и почтой, это не так уж и существенно.
**Веткой промахнулся**
А зачем в качестве иллюстрации к статье вы используете покореженную иконку давнего продукта компании Elcomsoft?
Sign up to leave a comment.
Манипулирование учетными записями пользователя — шаблоны реализации