Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 16
AnyEvent::HTTP мне кажется очень достойная замена LWP, думаю ускорит перебор в десятки раз.
В посте мельком упомянуто, были и другие уязвимости? То что расписано, имеет отношение только к брутфорсу паролей.
использовать отдельные логин и ник — не слишком удобно
Вот никто и не использует. Есть статистика корреляции логина и ника по сайту? Я уверен, что ~65%.
удивительно, что пароль и подтверждение дополнительно проверяются на совпадение еще и на сервере
Действительно, зачем бы? Да и от SQL инъекций можно JavaScript'ом обезопаситься.
Что же касается капчи — она достаточно простая, чтобы не быть помехой.
А что, уже придумали достаточно сложную капчу, чтобы она была помехой?
Я уверен, в этом аудите вы ещё очень-очень много чего упустили.
Значительная часть ников — реальные ФИО.
Отчасти, поскольку так написано в форме регистрации, отчасти, поскольку эта система использовалась в различных официальных и полуофициальных мероприятиях.
SQL-инъекция к сверке пары «пароль-подтверждение» отношения не имеет.
Основная задача этой пары — защитить пользователя от ошибки.
Если человек ввёл данные вручную в форму, JavaScript замечательно справится с валидацией, а если злобный хакер отправляет хитрые запросы, то как-то обрабатывать подтверждение пароля на сервере вообще бессмысленно.
Существование капчи, по моему опыту, замедляет перебор процентов на 30, в зависимости от сложности распознавания, за счёт ошибок ввода. Эта капча же настолько проста, что распознаётся с вероятностью 99,9% довольно быстрыми алгоритмами.
Отчасти, поскольку так написано в форме регистрации, отчасти, поскольку эта система использовалась в различных официальных и полуофициальных мероприятиях.
SQL-инъекция к сверке пары «пароль-подтверждение» отношения не имеет.
Основная задача этой пары — защитить пользователя от ошибки.
Если человек ввёл данные вручную в форму, JavaScript замечательно справится с валидацией, а если злобный хакер отправляет хитрые запросы, то как-то обрабатывать подтверждение пароля на сервере вообще бессмысленно.
Существование капчи, по моему опыту, замедляет перебор процентов на 30, в зависимости от сложности распознавания, за счёт ошибок ввода. Эта капча же настолько проста, что распознаётся с вероятностью 99,9% довольно быстрыми алгоритмами.
JavaScript может быть отключен или вообще отсутствовать. А иной раз просто не хочется вводить хоть строчку JS на страницу.
Может быть.
Но в конкретном случае проверка была двойная: и на клиентской, и на серверной стороне.
Что и удивляет.
Но в конкретном случае проверка была двойная: и на клиентской, и на серверной стороне.
Что и удивляет.
Тоже нормально, если и другие проверки проводятся дважды. Вообще многие некоторые фреймворки так делают по умолчанию — задаёшь одно правило валидации, а обрабатывается оно даже трижды: у клиента (по возможности) — чтобы избежать лишних запросов на сервер и получить моментальный отклик, в приложении — проверить типы, форматы и т. п., при записи в БД — проверка уникальности (при необходимости) или триггерами (редко).
>Слабая политика паролей (нужно запрещать пользователям вводить цифровые пароли)
Имхо, если это касается доступа пользователя к его данным на моем сервисе, то это его личное дело какой пароль устанавливать. Уведомить его, что простой/короткий пароль может быть легко подобран, в следствие чего доступ к его данным будет получен кем-то другим, сами данные могут быть уничтожены, а аккаунт использован для противоправных (включая нарушение пользовательского соглашения) действий — правило хорошего тона. Ограничивать — моветон.
Другое дело, если он регистрируется, чтобы получить доступ (например платный) к моим данным. Тут уже я заинтересован в том, чтобы его пароль было сложнее подобрать.
Но больше всего я не понимаю «чудиков», которые ограничивают сложность пароля. Чуть ли не саботажем выглядит. А когда при вводе пароля при логине они пишут только, что пароль неверный, но не пишут, что использованы недопустимые символы в нём и какие допустимы —убить карму заминусовать хочется. Например я использую «дежурный» пароль для неважных регистраций, содержащий не только буквенно-цифровые символы. Ладно когда при регистрации мне пишут [a-zA-Z0-9]{3,8}, я их просто опускаю, но когда при логине этого же не пишут, я раза три пробую ввести «дежурный» пароль, тщательно проверяя нажатия, регистр и раскладку, и уж потом думаю: «а может туту дважды „чудики“, попробуюка без „спецсимволов“».
Имхо, если это касается доступа пользователя к его данным на моем сервисе, то это его личное дело какой пароль устанавливать. Уведомить его, что простой/короткий пароль может быть легко подобран, в следствие чего доступ к его данным будет получен кем-то другим, сами данные могут быть уничтожены, а аккаунт использован для противоправных (включая нарушение пользовательского соглашения) действий — правило хорошего тона. Ограничивать — моветон.
Другое дело, если он регистрируется, чтобы получить доступ (например платный) к моим данным. Тут уже я заинтересован в том, чтобы его пароль было сложнее подобрать.
Но больше всего я не понимаю «чудиков», которые ограничивают сложность пароля. Чуть ли не саботажем выглядит. А когда при вводе пароля при логине они пишут только, что пароль неверный, но не пишут, что использованы недопустимые символы в нём и какие допустимы —
Ни разу не встречал таких чудиков. И это хорошо.
Возможно они это делают на самописных движках, потому как пароли с различными спецсимволами у них не очень хорошо обрабатываются (например с кодировками не сумели разобраться или еще что...). И они придумали «выход» просто не разрешать вводить такие данные
Возможно они это делают на самописных движках, потому как пароли с различными спецсимволами у них не очень хорошо обрабатываются (например с кодировками не сумели разобраться или еще что...). И они придумали «выход» просто не разрешать вводить такие данные
— (нужно запрещать пользователям вводить цифровые пароли) — за такое разработчиков обычных сайтов (не связаных с финансами) надо убивать. Пусть пользователь сам решает какой пароль использовать
Среди пользователей слишком много людей, которые не понимают разницы между «123» и «123!»
Обычные сайты в этом не нуждаются, но в этой статье я говорю про довольно крупные сайты с репутацией.
Обычные сайты в этом не нуждаются, но в этой статье я говорю про довольно крупные сайты с репутацией.
Пароли на почтовый ящик, к которому привязана регистрация на нескольких сервисах, и на каком-нибудь форуме отличаются по критичности. Если я знаю, что туда больше не приду или не вижу смысла скрывать защищенное паролем содержимое, я как пользователь хочу иметь возможность установить такой пароль, который посчитаю нужным. Сайту и другим пользователям от моего слабого пароля вреда не должно быть никакого.
За пост спасибо, но все же — в чем состоял аудит? Насколько этично и, что важнее, правомерно в данном случае проводить аудит (читай, взлом) паролей без ведома и согласия их владельцев?
За пост спасибо, но все же — в чем состоял аудит? Насколько этично и, что важнее, правомерно в данном случае проводить аудит (читай, взлом) паролей без ведома и согласия их владельцев?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
История одного аудита