Меню
Что нового?

Запутался с шифровкой пароля

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

grigori
вариант не гарантирует уникальность соли, обычно регятся везде под одним логином, если он доступен, я вот с ником прогадал (4-ре символа не везде можно).
 
Почему статическую? Генерировать рандомную при установке или первом использовании. Польза в том, что делает угнанный дамп базы бесполезным в плане подбора паролей. А если нужна единая авторизация между приложениями, никто не мешает использовать $secret = '' (что сводится к /etc/shadow которому уже сто лет)
 
proWoke
Код: 
$password = $password."abr13";

не пиши так, вынеси в отдельную переменную.а вобще по хорошему соль генерировать на каждого нового пользователя, потому как узнав один раз твою соль, последующее её применение становица бесполезным.
 
melo: знание соли упрощает брутфорс. Но при этом любая произвольная (известная или нет, неважно) соль - сводит на нет атаки по словарю.
Если предположить, что и солёный хэш и соль лежат в базе, то будучи украденными - в руках злоумышленника так и так, будут все пароли и все соли.

Я не могу нарочно придумать ситуацию, когда вдруг ты смог узнать только 1 соль и все солёные хэши. Или ты узнал всё, или ты не узнал ничего.
 
"потому как узнав один раз твою соль, последующее её применение становица бесполезным."

предложение: ты называешь соль, я солю ей пароль - ты доказываешь бесполезность соли, м? :-)
 
РНР с версии 4.3 поддерживает sha1. У него выше стойкость к появлению коллизии в сравнении с md5. Пользуюсь им. Для каждого пароля генерирую уникальную соль.
 
Более того - я даже облегчу тебе задачу, выбрав словарный пароль, который тупо находится гуглом в словарях md5. М? :-)
 
я этого делать не умею.
при знании соли время подбора пароля с помощью радужных таблиц не уменьшаеца?
 
melo: наличие соли в принципе исключает возможность использования радужных таблиц. Как только ты добавил в хэш соль - можно радужные таблицы выкидывать на помойку.
 
zerkms
да, почитал.
соль исключает использование радужных таблиц.
знание соли упростит только брутфорс(хотя там можно год брутфорсить) и сведет на нет атаки по словарю.
и да, если соль в бд, то узнаешь и соль и хэш.
молодец)
 
zerkms написал(а):
melo: знание соли упрощает брутфорс. Но при этом любая произвольная (известная или нет, неважно) соль - сводит на нет атаки по словарю.
Если предположить, что и солёный хэш и соль лежат в базе, то будучи украденными - в руках злоумышленника так и так, будут все пароли и все соли.

Я не могу нарочно придумать ситуацию, когда вдруг ты смог узнать только 1 соль и все солёные хэши. Или ты узнал всё, или ты не узнал ничего.
Нажмите для раскрытия...

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

также не следует путать атаки с помощью радужных таблиц с классической атакой по словарю.
использование константной "соли", a la $password = $password."abr13", если предположить что она известна,
криптостойкости никакой не добавляет, тк:
1. select count(id), hash from auth group by 2 order by 1 desc
исходя из http://ru.wikipedia.org/wiki/Парадокс_дней_рождения

и далее брутфорсим | пускаем через словарь по порядку.

2. из словаря A можно построить словарь В = A + "abr13" за линейное время.

с учетом нанотехнологий типа КУДА, напрашиваются два вывода:

1. соль должна быть независимой случайной величиной (только тогда не прокатит атака по словарю, точнее будет менее эффективна).
2а. желательно также подмешивать "секретную" константу ("соль") в хеш хранящийся в бд, для минимизации ущерба при тупом угоне базы.
2б. желательно также подмешивать "секретную" константу ("соль") в хеш который в куке "ремембер ми", для предотвращения "автологина" c любым юзер айди, при тупом угоне базы.

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

 
SiZE написал(а):
РНР с версии 4.3 поддерживает sha1. У него выше стойкость к появлению коллизии в сравнении с md5. Пользуюсь им. Для каждого пароля генерирую уникальную соль.
Нажмите для раскрытия...

Не надо говорить глупости, про коллизии это "слышал звон". То, что китайцы какие-то там нашли, как сгенерировать два текста с одинаковым md5(), не значит, что можно найти пару для произвольного текста, и никак не упрощает подбор; более того, для коротких текстов (а пароли не бывают длиной в несколько килобайт) коллизий никто не находил. Кстати, для sha1 такие пары тоже существуют для текстов примерно той же длины; тогда уж - sha256. :)
 
fixxxer
у md5 есть коллизия на XOR ,а именно

md5(DATA) = XOR(md5(XOR(DATA,RAND), RAND)

где естественно RAND одинаковое но не важно какое число
 
И? Вот есть у тебя содержимое /etc/shadow, где в качестве crypt алгоритма используется md5, чем это тебе поможет?
 
Войдите или зарегистрируйтесь для ответа.
Сверху