Шифрование
Думается, лучше всего пойдет собственная функция СУБД для этого.
md5 хорошая штука, но ею лучше шифровать дважды - сначала пароль, затем получившийся хэш. Тогда сбрутить пароль будет более чем затруднительно.
Где ты такое вычитал? :)
Сам подумай логически.
Если идет подбор брутфорсом и хэш известен, то
1. Есть реинбов метод - уже готовые пароли для хэша
2. Пароль который захеширован (пусть даже и 5 раз) не обязательно должен совпадать с тем который ты подберешь, да и вообще одному хэшу теоретически могут соответствовать множество паролей...
Если идет подбор брутфорсом и хэш НЕ известен, то двойное хэширование лишь просто даст дополнительную нагрузку на сервер, который мы брутфорсим.
Сам подумай логически.
Если идет подбор брутфорсом и хэш известен, то
1. Есть реинбов метод - уже готовые пароли для хэша
2. Пароль который захеширован (пусть даже и 5 раз) не обязательно должен совпадать с тем который ты подберешь, да и вообще одному хэшу теоретически могут соответствовать множество паролей...
Если идет подбор брутфорсом и хэш НЕ известен, то двойное хэширование лишь просто даст дополнительную нагрузку на сервер, который мы брутфорсим.
Пытаюсь думать логически:
1) по определению, вероятность того, что хэши любых двух разных паролей, зашифрованых md5, будут совпадать стремится к нулю.
2) устойчивость md5 к бруту заключается именно в том, что машине не хватит ресурсов подобрать пароль, если сам пароль конечно удовлетворяет правилам паролизации :) Зашифровав пароль дважды, мы значительно увеличиваем время подбора.
3) Если предположить, что есть машина с бесконечно большой производительностью, или таблица хэшев на все существующие пароли, то если вы подскажете метод шифрования пароля так, что его будет трудно подобрать/расшифровать, скажу ОГРОМНОЕ спасибо.
Да, согласен, но не равна. :)
[QUOTE=~ArchimeD~]2) устойчивость md5 к бруту заключается именно в том, что машине не хватит ресурсов подобрать пароль, если сам пароль конечно удовлетворяет правилам паролизации ) Зашифровав пароль дважды, мы значительно увеличиваем время подбора.[/QUOTE]
Ну тогда уж лучше ИМХО блокировать атакующего на определенное время или вставить какую-нибудь задержку типа sleep(), а не нагружать сервер дополнительными алгоритмами, кроме того, снова таки ИМХО, двойное хэширование не намного больше будет занимать процессорного времени, чем одинарное (хотя тут надо бы сделать бенчмарк... :))
[QUOTE=~ArchimeD~]3) Если предположить, что есть машина с бесконечно большой производительностью, или таблица хэшев на все существующие пароли, то если вы подскажете метод шифрования пароля так, что его будет трудно подобрать/расшифровать, скажу ОГРОМНОЕ спасибо.[/QUOTE]
Методом брута можно подобрать все (единственное ограничение это время, которое зависит, в свою очередь, от многих других факторов) :)
Хватает ИМХО и хэширования одним из существующих алгоритмов, просто я не вижу смысла в двойном хэшировании, вот и все. :)
Конечно же лучше использовать сессии и еще и проверять ip-адрес посетителя...
если хэш каким то образом будет свиснут левой стороной, из бд или перехвачен из куков с помощью xss, то войти этот нехороший человек с этим хэшем на сайт сможет только пока сессия активна, и то, если к ip не привязана. Скорее всего у него возникнет желание из полученного хэша получить пароль. Следовательно кинет он в брутер этот хэш на подбор, и уйдет спать. А если пароль зашифрован дважды, то получит этот нехороший человек только первый хэш, и то через месяц-другой. Думаю перебирать его ещё один раз желания уже не возникнет.:)
Возможно, судя по постам окружающих, я ошибаюсь, и метод этот не эффективный. Но мне кажется, что так оно и есть, как я имею в виду:)
Поэтому - ваши исправления и комментарии.
З.Ы. а в случае перебора через запросы блокировать по ip на 15-20 минут после нескольких неудачных попыток - это само собой разумеется.
1) по определению, вероятность того, что хэши любых двух разных паролей, зашифрованых md5, будут совпадать стремится к нулю.
Вот только не надо умничать. Ничего тут не стремится к нулю. Надо быть осторожней с терминами "вероятность" и "стремится к чемуто", тем более "по определению".
По поводу двойного хэша - абсолютно не понятно зачем это нужно. Если залогинится на сайте с помощью этого хеша - то чем спасет двойной по сравнению с одинарным? Если же просто вытянуть изначальный пароль из хеша, для каких то своих целей, - то это не возможно. Вспомните, что md5 - это необратимая, невзаимооднозначная функция. Тоесть это не шифрование данных, которые можно восстанавить - это хеширование, хоть и криптографическое, при котором теряется информация о изначальных данных. Следовательно даже если подобрать последовательность, которая дает тот же хеш - ничего не гарантирует, что это был нужный пароль. Хотя да, на сайте им логинится можно будет, если пароль в хеше хранится в базе. Но тогда опять же 2-й хэш не нужен ))
По поводу двойного хэша - абсолютно не понятно зачем это нужно. Если залогинится на сайте с помощью этого хеша - то чем спасет двойной по сравнению с одинарным? Если же просто вытянуть изначальный пароль из хеша, для каких то своих целей, - то это не возможно. Вспомните, что md5 - это необратимая, невзаимооднозначная функция. Тоесть это не шифрование данных, которые можно восстанавить - это хеширование, хоть и криптографическое, при котором теряется информация о изначальных данных. Следовательно даже если подобрать последовательность, которая дает тот же хеш - ничего не гарантирует, что это был нужный пароль. Хотя да, на сайте им логинится можно будет, если пароль в хеше хранится в базе. Но тогда опять же 2-й хэш не нужен ))
Насчет умничать, неплохо быть повежливее для начала. Было написано про попытку думать логически. "По определению" - это значит мне такое определение встречалось, и ежу понятно что число всех возможных символьных комбинаций больше всех возможных хэшей.
Если пароль зашифрован 1 раз - то вероятность, что подобранный перебором пароль, будет таким, каким нужно, как раз имеет очень большой процент, т.к. не родился ещё тот человек, который будет запоминать и использовать 64-символьные пароли на сайтах. А в пределах 20 символов врядли 2 строки будут иметь одинаковые хэши.
Если дважды зашифровать пароль - при переборе (именно у себя на компьютере, а не на удаленном сервере! - в целях нахождения строки, имеющей одинаковый с требуемой хэш) он будет один раз расшифрован, на сайте под ним не залогинишься, т.к. это не будет исходным паролем, пока не выковырнешь именно изначальную строку. А сколько это займет времени, думаю объяснять не надо.
Всех возможных комбинаций бесконечно много. Равномощьно множеству целых чисел. Но вопрос то был в стремлении к нулю, что некорректно. Вспомните.ю что такое стремление к нулю. ))
А в пределах 20 символов врядли 2 строки будут иметь одинаковые хэши.
Уверенны в этом? Вероятно - это не обяательно. 2 коротких строки воплне могут (и имеют) один хеш.
Уверенны в этом? Вероятно - это не обяательно. 2 коротких строки воплне могут (и имеют) один хеш.
Ок, насчет стремления к нулю оставим дискуссию. Попробую привести для понимания пример:
Есть сайт, дядя Вася стырил значение кукиза "пароль". Подобрать через запросы не получается - через 5 попыток бан на 15 минут.
Дядя Вася видит, что это md5 хэш, берет переборщик и начинает перебирать возможные комбинации. Есть два варианта -
1) через месяц найденная строка будет неверной, ситуация тупиковая для дальнейшего развития, в ее конце дядя Вася убивает сибяапстену.
2) через месяц найденная строка будет верной, но дядя Вася, в состоянии, близком к истерике обнаруживает, что это очередной хэш. Но он упорен и начинает подбирать строку и для него. Опять две ситуации
2.1) Ещё через 2 недели дяде Васе выплевывается неверный пароль. Дядя Вася убивает сибяапстену.
2.2) Ещё через 2 недели дяде Васе выплевывается верный пароль, но к этому времени пароли уже все поменяли. Дядя Вася убивает сибяапстену.
Вот и пусть считает спец по теории вероятностей Aks, на сколько снижается вероятность нахождения верного пароля при увеличении количества шифрования, и сколько это займет времени.
А суть то в том, что хранить и передавть хэши в куках в данном случае не корректно. )) Не для того они предназначенны, а шифрование в сети другими средствами достигается. )
Надежная авторизация используется в основном в инет-магазинах и платежных системах, а если юзверь, такой нехороший, меняет динамически свой ип значит он что-то скрывает, значит такому пользователю доверять нельзя, значит мне такие пользователи не нужны.... :)
[QUOTE=~ArchimeD~]или перехвачен из куков с помощью xss[/QUOTE]
Параноидально проверяем переменные и ниче такого не будет :)
[QUOTE=~ArchimeD~]Следовательно кинет он в брутер этот хэш на подбор[/QUOTE]
Он подберет пароль к этому хэшу и успешно авторизируется с помощью него.
[QUOTE=aks]Ничего тут не стремится к нулю.[/QUOTE]
Если есть четкие ограничения, например, пароль может быть в приделах 8-12 символов и еще и ограничения на символы, то врядли таких совпадений будет много, т.е. будет "стремится к нулю" :) (ИМХО конечно)
А суть то в том, что хранить и передавть хэши в куках в данном случае не корректно. )) Не для того они предназначенны, а шифрование в сети другими средствами достигается. )
Ну вот, кажись и договорились - хранить и передавть хэши в куках не стоит, но если уж Магомет предписал делать именно так, то шифровать дважды - надежнее, чем один раз:)
А если у юзера несколько точек доступа (с ноута например, а юзер серьезный такой, богатый, постоянный) и все с разным IP? Или dial-up у него, да мало ли чего. Почему обязательно скрывать?
Если есть четкие ограничения, например, пароль может быть в приделах 8-12 символов и еще и ограничения на символы, то врядли таких совпадений будет много, т.е. будет "стремится к нулю" :) (ИМХО конечно)
Мое замечание было именно в к коректности применения термина "стремится". А "врядли таких совпадений будет много" и "стремится к нулю" это абсолютно разные вещи. Из разных плоскостей можно сказать. )
Передавать то в кукис не стоит, но и в базах двойное хэширование использовать тоже не стоит :)
Я имею ввиду динамическое изменение, тоесть в текущем подключении (скажем каждых 2 минуты) ;)
[QUOTE=aks]Мое замечание было именно в к коректности применения термина "стремится". А "врядли таких совпадений будет много" и "стремится к нулю" это абсолютно разные вещи. Из разных плоскостей можно сказать. )[/QUOTE]
ок, полностью согласен
Ну можно так сделать, скажем на каждой странице проверять пароль юзера, тот или не тот в кукизах лежит.
Можно вообще кинуть пароль в кукис не зашифрованным и не хэшированными, если сайт типа "домашняя страничка" :D
Спор идет о том нужно ли вообще двойное хэширование пароля... Или я чета недопонял... :D
Спор идет о том нужно ли вообще двойное хэширование пароля... Или я чета недопонял... :D
Понял правильно, но не понял, что уголовное дело закрыто за обоюдным соглашением сторон. Выяснили, что от двойного шифрования пароля в кукизах будет не хуже, а лучше, но при этом пришли к соглашению, что вообще совать пароль в кукизы - бред:D
