All streams
Search
Write a publication
Pull to refresh
10
0
Дмитрий @dso

Software Engineer

Send message
Следующий, кому позвонит Эми, просто обязан попробовать произнести вслух текст sql-инъекции. Вдруг получится?
Если на всех девайсах инженерный пароль одинаковый, то брут на еще одном устройстве увеличит скорость подбора вдвое :)
Строка в конфиге:
add_header                  X-Frame-Options             "DENY";


вызовет ошибку ERR_BLOCKED_BY_CLIENT для сайтов, которые используют загрузку контента в фреймы. У меня была проблема с WYSIWYG-редактором tinyMCE — открывались пустые окна.

Чтобы разрешить загрузку в фреймах, я поменял «DENY» на «SAMEORIGIN».
Есть только сценарий использования: не лениться отключать тома, когда ими уже не пользуешься. Сделал привычкой, уже на автомате это делаю.

А если ноутбук потерял, а пароль украли — тут уже ничего не поделать. Останется только радоваться, что я не знаменит.
Все личное храню в томах трукрипта: переписка, логи скайпа, сканы документов, и прочее-прочее. Крайне удобно.
Да. Пока аккаунт пользователя бомбардируется, пользователь-человек в систему не войдет.
Вы все напутали. Речь идет о подборе пары логин-пароль для авторизации, а не о хранении хэша пароля в БД.
Для авторизации приходят строки без всякой соли.
Мой способ как раз и создан для того, чтобы не забивать голову. Он намного проще реализации входа через соц-сети или двухфакторной авторизации. Он не идеален, не является панацеей и не защитит высоконагруженные проекты. Он уменьшает вероятность подбора пароля, который может оказаться слишком простым. Перечислю видимые мне плюсы:

  • Быстрая реализация. Существующую регистрацию менять не потребуется: создаем свойство touch, добавляем его в условие выборки пользователя, и делаем апдейт touch при попытке проверки записи пользователя.
  • Детектирование проблемы. Хотя журналы учета попыток входа в систему не ведутся, пользователь сам напишет, что не может попасть в систему, а администратор проверит аккаунт и, с большой степенью вероятности, увидит трудолюбивый подбор паролей in real-time. Не всем нравится этот метод, но он лучше, чем совсем ничего или тикет «Здравствуйте, у меня уже украли аккаунт».
  • Бот может подбирать пароли на ресурсе, а его даже могут не замечать годами. Он с большой степенью вероятности не получит положительный ответ на правильную пару логин-пароль. Это может сбить его с толку, если он ведет обычный перебор паролей по словарю к заранее известному аккаунту пользователя (в комментариях уже подсказали, что можно делать перебор не паролей, а аккаунтов, и для такой ситуации это уже проблема).
  • Реализация не завязана на данные с клиента.


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

Авторизация через соц-сети видится мне хорошей альтернативой способа защиты паролей. Но у этого способа есть два больших недостатка: не все зарегистрированы в соц-сетях (а некоторые не хотят использовать личный аккаунт для авторизации на сайте), и для каждой соц-сети потребуется делать свою реализацию входа.
Спасибо за совет. Я обязательно обдумаю, как предотвратить эту ситуацию.
Думаю, малую часть пользователей можно защитить, если принудительно требовать от них смены пароля раз в две недели, например. И если бот не успел перебрать все пароли, ему придется начинать перебор заново, чтобы гарантированно подобрать пароль к конкретному логину.
Да, верно. В данной схеме подразумевается, что если пользователь постоянно будет испытывать сложности со входом, он создаст тикет в поддержку, чтобы администратор ресурса принял меры.
Нет, атаки на ресурс не проводились или мне о них неизвестно. Это небольшой стартап, и популярность у него небольшая.
Пока могу сказать за живых пользователей: они не писали мне о проблемах входа в систему.

Information

Rating
Does not participate
Location
Киев, Киевская обл., Украина
Date of birth
Registered
Activity