Я храню пароли так. Код (PHP): $n = 200000; $salt = "3c82c42719365742090eb207695a1055"; $str = "mypassword"; for( $i=1; $i<=$n; $i++ ) { $str = md5( $str.$salt ); } $n - это число в районе 200к, которое зашито в коде константой. $salt - это md5'ый хеш от случайного числа, который зашит в коде константой. Проверка пароля занимает примерно 0.1с. Для процесса авторизации - мелочь, а для перебора - ужас. Вы сможете проверить только 10 паролей в секунду. И если Вы не спёрли скрипты, то Вы не знаете соли.
Нас, в свое время, на защите информации, препод учил, что любой алгоритм ломается в течение минуты с помощью обездвиженного человека, знающего как он работает, и паяльника/утюга... В такие моменты люди почему-то забывают, что буквально только что выставили на свет кнопку "ЗаDDOSь меня!", которую сами же и сделали. И да, тема уже обсуждалась.
Все скрипты - такая кнопка. Если вы с ддосом боретесь увеличением скорости работы скрипта - то вы идиот.
А я думаю, что идиотизм - это когда борешься с "перебором" паролей методом забивания процессора машины по принципу "злоумышленник упрет сервер в потолок и обломится!". А что будет, когда проект начнет расти и вы начнете масштабироваться, наращивая мощности? Увеличите количество итераций цикла? Давайте не будем кидаться определениями друг друга на основе субъективного мировоззрения. Просто если у вас начнут перебирать "10 паролей в секунду" за счет того, что процессор просто не будет справляться, то сервак ляжет на бок. Хотите чтобы кто-то ждал какое-то время между попытками, причем выверенное до одной миллионной секунды, не трахайте сервер, а используйте команду usleep(); и пусть машина расходует свои вычислительные ресурсы на обслуживание других запросов. Оно и поэффективнее будет. Если взять не usleep(), а просто sleep() хотя бы на 1 секунду, пользователь, вводящий пароль, тоже ничего не заметит. А вот брутфорс обработает всего 60 паролей в минуту (при идеальных условиях, без пинга и тд, так что на деле - меньше гораздо). А сервер при этом будет спокоен и прохладен.
Не следует лезть в тему, в которой вы ничего не понимаете. Жаль, что этому вас ни один препод не учил.
ты сильно ошибаешься. давай простую арфметику. если страница генерится 200 мс, сколько страниц в секунду отдаст сервер?
Приятно получать такие вот емкие и конкретные ответы. Если не видите разницу между увеличением времени алгоритма и увеличением времени работы, используя первое в качестве второго при условии, что сам алгоритм злоумышленнику неизвестен и время алгоритма роли не играет в принципе, не надо говорить, что это я ничего не понимаю в "вашей теме", и уж тем более упоминать преподов. для одного и того же клиента? Ни одной, пока sleep висит с предыдущего запроса. Если ты на тысячу страниц разом отдашь по запросу, они все равно будут выполняться по одному, с интервалом слипа. Да, ты послал тысячу запросов, но в минуту сервер обработает 60. При этом процессор будет свободен для обслуживания настоящих запросов, а не пытаться положить себя на радость боту.
Ничего менять не буду (в этом алгоритме). Точно таким же образом они могут положить сервер просто запрашивая главную страницу (которая генерится 0.2 сек). Это называется ДДос и боротся с ним нужно совсем другими методами. Вы ничего не поняли в моём алгоритме. Если зло сопрёт скрипты, думаете они не удалят usleep?
Ну наконец-то ответ от человека, который поднял тему, а не от выскочки, которому всех жаль Воот, тут разговор пошел иначе. Имеет место именно целенаправленное увеличение времени алгоритма, чтобы и на своем железе злоумышленник подбирал пароли долго. Такой подход был оправдан когда-то, но, современный мир все спустил к чертям. Дело в том, что зло не будет перебирать пароли на ЦПУ. Он воспользуется видеокартой. А то и парочкой в SLI. Когда речь идет о распараллеливании на тысячи "честных" потоков, ваше наращивание времени алгоритма в 0.1с для ЦПУ, увы, уже не котируется. Для ГПУ это как слону дробина. Тут весь секрет в том, чтобы вернуться из мира сферических гипотез в реальный мир. Вероятность кражи ваших скриптов - 0%, если хостер и датацентр не мудаки.Вы же рассуждаете с точки зрения ситуации, когда речь идет об открытой передаче зашифрованных (а не убитых в хэш) данных, которые могут быть перехвачены. На деле - не могут. Основной источник возможности перебора паролей - ваша логинилка на сайте. И простой слип тут гораздо более к месту. Рассматриваем другую ситуацию - вы проморгали и вам вогнали шелл, о котором вы ни сном ни духом. Думаете кто-то будет через него выкачивать ваши скрипты, снимать дамп базы и расшифровывать ее? Нет. Вам просто добавят пару строк кода, которые будут сливать логины пользователей вместе с паролями налево в тот момент, когда они, пользователи, заходят на сайт. Реальный мир гораздо проще и практичнее, чем мир теоретический.
Ты про это чтоли? Я как бы ответил в следующем посте, просто тебя не цитатнул. Краткий тезис: Слип имеет значение, когда надо именно сделать паузы между обработками. Но не имеет значения, когда целью является не увеличение времени работы, а увеличение времени алгоритма. Как-то так
для начала я прошу третий раз ответить на простой вопрос. если страница генерируется 200 мс, то сколько страниц сгенерируется в секунду?
Для одного клиента в сферических условиях 5 страниц на одноядерном процессоре. Много... Если 2 видеокарты в SLI-режиме, то умножай количество ядер еще на два.
ты умеешь без SLI две видеокарты через один программный интерфейс гнать в параллельном режиме? Патентуй. Срочно. З.Ы. Я знаю, что на самом деле видюхи будут работать по очереди. Точнее по очереди разбирать задания. Будет не 100% удвоенное снижение времени ожидания, но работать они будут по сути двукратно. Все зависит от кривости рассчетного софта. Обычно при этом высказывают свои варианты.
а нет вариантов. может быть сколько угодно страниц в секунду. эти времена никак не связаны. и твой делей не добавляет ровным счётом ничего кроме двух аспектов: 1. дольше ждать ПЕРВОГО ответа. Остальные посыплются с той же скоростью, как и сыпались запросы на них. 2. можно тупо забить потоки пхп, т.к. каждый поток будет честно ждать. Таким образом можно просто заддосить сервак не нагружая проц. Добавлено спустя 1 минуту 10 секунд: а не надо на меня своих тараканов перебрасывать =) я про "один программный интерфейс" не говорил.
Эм...нет. Если делей будет в обработке каждого, то будут работать по очереди с учетом делея. Ну правда, я проверял эта проблема известная и легко решаемая грамотной настройкой сервера. Чтобы выше какого-то порога шли режекты. Даже тот же вконтактик при попытке открыть разом N вкладок, скажет, мол "не спеши". ок, принято.
Это в одном потоке будет делей ждать. А остальные продолжат работать пока этот спит. в ххвм и ноде вообще не будет перерыва. вобщем твоё решение с потолка.
один клиент это круто, но это что-то за уши притянутое. совсем. есть сервер, есть запросы, запросы валятся - сервер работает, пока запросы на паузы не забьют все пхп-потоки. что будет в этом случае - я говорил. Едем дальше. Если у тебя грамотные пароли и соли и хеширование, то 1 раз хеш посчитать или неизвестно сколько раз хеш посчитать - это большая разница. Накрутка хешей в 1000 циклов незаметна даже для проца. Да. но проц не считает лишнего. А "хакер" считает на своей быстрой видяхе и даже если знает, сколько циклов надо прогнать - это многократно его задержит. Многократно. На порядки. Т.е. либо за год вскроет, либо за тыщу лет. Если для тебя это не существенные цифры - дело твоё.