Как стать автором
Обновить
102
0.2
Slava Vedenin @vedenin1980

Java developer

Отправить сообщение
Не уверен что это хорошая идея:
1) Пользователям быстро это надоест, например принудительно менять раз в месяц даже на рабочем компе пароль для меня было весьма утомительно
2) Есть пользователи, которые могут месяцами не логиниться (и соответственно не менять паролей),

Вообще, все украдено для нас. Самый простой и довольно эффективный алгоритм защиты от перебора такой:
1) Все-таки заставлять пользователей не использовать совсем уж легкие пароли,

2) Ограничить кол-во попыток логирования для пользователя и ипишника (отдельно для каждого user'a и отдельно с каждого ip'шника) определенным числом за N минут, например не более 5 неудачных попыток входа за 15 минут, после требовать ввода сложной капчи и давать ещё 5 попыток, если пользователь ввел её успешно (ввод любой капчи это ещё не гарантия что это не бот из-за трудолюбивых китайцев с их сервисами ручных распознаваний капч, но распознавание миллионов капч все-таки весьма дорогое занятие, чтобы оно имело смысл),

3) Ограничить общее время неудачных попыток за все время, то есть если пользователь даже в течении месяца ввел 20 раз пароль неправильно и не ввел ни разу правильный пароль, то при каждом следующем вводе, требовать капчу.

Это позволит ограничить как ботов, перебирающих пароли сразу, так и тех кто перебирает по-немногу. Правда, проблема все равно остается если пользователь заходить часто, а бот перебирает достаточно медленно, тогда есть шанс что пользователь будет успевать вводить правильный пароль чаще чем бот израсходует лимит неправильных. Тут есть несколько вариантов:
1) Анализировать соответствие правильных и неправильных пользователей, если ипшники и юзер агенты и включена ли js или нет, всех кто входит под правильным паролем и под неправильным никогда не совпадает, включаем для пользователя капчу при каждом входе,

2) другой вариант, при входе правильного пользователя выводить предупреждение с каких ип адресов, когда и сколько раз были попытки входить в систему и показывать кнопку «это был не я»

3) придумать что-то свое…

P.S. Если есть желание помучатся, можно порыть в сторону анализа таких вещей как включен ли у пользователя javascript (например, отдавая ему хитрую, сгенеренную каждый раз заново, функцию javascript, устанавливающую хитрые ключи в скрытые поля форм), правильные ли user agent'ы и работа с куками, нет ли следов работы с прокси или ипишников совсем отличных от предыдущих ипишников регистрации и успешных входов и т.п. Соответственно, для подозрительных пользователей, показывать капчу или раньше или вообще сразу при вводе пароля.
Смотря что за БД. В данном случае хорошо бы подошли nosql key-value БД, в идеале in memory.
Основная проблема только в том что очень тупые боты будут непрерывно перебирать пароли одного пользователя без остановки. Дело в том что в большинство нормальных сервисов после некоторого кол-ва неправильных паролей в течении определенного времени у одного пользователя будет требовать не только пароль, но и вводить сложную капчу (а может вообще заблокировать данную запись и требовать восстановления через почту/телефон). Поэтому боты не перебирают пароли у одного пользователя, а ходят по всей базе данных пользователей (её на форуме или почтовом сервисе, например, можно получить вообще в открытом виде) и подставляют каждому пароль 123. Причем ходят, естественно, под разными ипшниками. На следующий день они пойдут по всем пользователем, но с паролем 1234 (на самом деле это утрировано, они могут случайно выбирать из списка легких паролей и подставлять каждому «свой» пароль и запоминать результат). Через месяц-другой у ботов будут все аккаунты с легкими паролями, причем ни разу они не натолкнуться на лимит по времени или ип адресу сервиса, так все запросы будут очень распределенные по времени и ип.адресам.
Только в теории, так как такой внешний код не сможет нормально работать с сущностями 1С, а даже гипотетически сложно представить ситуацию, когда в 1С потребуется миллиард итераций, работающих только с числами и строками и никак не использующий объекты самого 1С.

Плюс, мерить производительность циклов в высокоуровневых языках в большинстве случаев никакого смысла не имеет, так как один кривой запрос к базе данных или к сети, будет выполняться дольше любого практического числа итераций.
Мне кажется вы что-то путаете, нельзя удалять или добавлять элементы в коллекцию во время for/foreach, а св-ва объектов менять, конечно, можно.

Скажем, в java, код:

for (MyClass obj: collection)
{
obj.prop = 1;
}

работает прекрасно. В C# тоже, должен работать.
По-моему, это хороший пример почему крайне аккуратно стоит использовать вложенные finally блоки.
Единственные причины всей этой гоблинской валидации — закостенелость сознания и нежелание лишний раз контактировать с клиентом.


Не всегда, иногда почта это единственный способ связаться к клиентов напрямую. Представьте что в ваш интернет магазин обратился клиент готовый прям вот счаз купить вообще все что у вас есть, но написавший адрес почту с ошибкой. И что тогда?

Да, можно требовать обязательно вводить телефон/скайп/icq, но клиенты зачастую не любят ещё больше.

Вообще, оптимальнее, на мой взгляд, давать возможность входить через соц.сети. Это с одной стороны, относительно безопасно (так как соц.сеть вашего пароля стороннему сайту не отдаст), с другой стороны всегда есть возможность связи и защита от «левых» регистраций.
Увы, инет все больше развивает параною, особенно та фишка «введите ваш телефон и мы пришлем бесплатный код подтверждения».
Нет, я бы тоже не стал переходить так на почту, фродную страницу далеко не так легко распознать. Это что-то из разряда введите ваш номер телефона и мы пришлем вам код подтверждения. С одной стороны удобно, с другой очень часто пытаются так кинуть на деньги.
Идея, конечно, интересная, вот только вопрос насколько захочет пользователь идти по такой ссылке, если он не 100% уверен в безопасности сайта, ведь по сути нет ничего проще чем подсунуть ему фейковую страницу почтового сервиса и получить его почтовый логин и пароль? А ведь зачастую почта это ключ к реальным деньгам и разным сервисам, вроде фейсбука или вконтакте.
Нет реализации стандартных библиотек.


А стандартные библиотеки планируется тоже перекомпилировать в код на java вашим компилятором или вы хотите сделать заглушки-аналоги стандартных библиотек в Net через стандартные библиотеки java? В смысле чтобы вместо метода X класса Y, вызывался некий java аналог?
А, понял, спасибо
Насколько помню в виндовс была такая методика — как проверка самых часто используемых временных каталогов (вроде tmp) на последнее время файлов. Вот тогда практически невозможно обмануть переводом назад, не знаю насколько такое легко реализовать на андроиде.
Интересно, а можно вопрос: Я правильно понимаю, что перевод назад можно поймать только если пользователь переведет время до последнего запуска? То есть, выключили программу на два дня, перевели на полтора — программа будет думать что прошло только полдня?
Проще, но https (точнее у протоколов, которые он использует, SSL или TLS) есть свои уязвимости, позволяющие совершать на него атаки типа man-in-the-middle. Особенно в случае если используется самоподписанные сертификаты. Подробнее про атаки на SSL или TLS можно посмотреть хотя бы в википедии. В любом случае полезно знать разные варианты реализации безопасности в приложении, поэтому эту статья для меня очень интересно было прочитать, в первый раз вижу что все варианты разложены по полочкам.
Если я правильно понимаю, сжатие реализовано даже на уровне таких протоколов как ssh, http, то есть в теории это может сработать, даже если просто пересылать более структурированные данные по сети от бека веб.клиенту. Впрочем, я так понимать, все будет зависеть от алгоритмов архиватора протокола и в некоторых случаях никакой пользы от такой оптимизации может и не быть.
Спасибо, очень интересный «фокус», но можно уточнить? Строчки дублируются или просто похожи? Т.е. большая часть это
1, a1, 2014.12.30, 2014.12.31
1, a1, 2014.12.30, 2014.12.31
1, a1, 2014.12.30, 2014.12.31

или все-таки вида
1, a1, 2014.12.30, 2014.12.31
1, a1, 2014.05.21, 2014.05.22

Просто есть подозрение что данная магия хорошо работает только если строчки полностью дублируются и есть подозрение что group by по всем полям или DISTINCT сработали бы ещё более эффективно, так как мне сложно представить необходимость получать сто тысяч одинаковых значений в поле имени без других параметров.

Но все равно, спасибо за интересный «трюк», надо будет попробовать и на других базах данных.
1) Замеры делались с учетом того что хранилища работали на той же машине, правильно? А при реальном использовании вы тоже будите запускать все на одной машине? Просто практика показывает, если хранилище оказывается даже в одной локальной сетке, но на разных компах, скорость будет совсем другой, так основная задержка будет при передаче по сети.

2) У монги есть 3 официальных режима: write, write/2, write/3. Если будите делать ещё раз замеры, советую попробовать все три, дело в том что write самый медленный, но самый надежный. write/3 быстрее и почти так же надежен, а вот write/2 это практически in memory скорость, так как монга не будет ничего писать на диск, а сразу отдаст управление обратно. Минус — естественно, если монга упадет, вы об этом не узнаете, а просто потеряете данные, плюс есть шанс что при немедленном чтении, клиент не успеет увидеть последних изменений. Однако, как раз при таком режиме она может использоваться как быстрый кэш для не особо критичных данных (при этом это будет более надежно чистого in memory).
В том-то и дело, что мало кто знает что у GSON есть собственная реализация JsonReader (в пакете com.google.gson.stream), которая судя всему и есть полная копия android.util.JsonReader (видимо, гугл просто использовал одну и ту же библиотеку в разных пакетах). То есть если в проекте активно используется именно GSON не обязательно использовать что-то ещё для SAX решений.
12 ...
398

Информация

В рейтинге
2 101-й
Откуда
Luxemburg, Luxembourg, Люксембург
Дата рождения
Зарегистрирован
Активность