соль, хеши.. мой алгоритм круче чем в IPB > 2.0 :D
 

скачал сейчас оффлайн-сборник статей античата (респект Nova ;) ) и прочитал статью Гаврилы про хеши и соль в IPB > 2.0
Из этого сделал вывод что алгоритм хеширования, придуманный мной ещё круче и непоколебимее чем в IPB! :)

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

вот так :)

имхо
 

реал пасс: abcdefghi -> подбор: abcdabcdefghi
реал пасс: bcdefghij -> подбор: bcdebcdefghij
то, что не виделенно - программа берет из первых 4 символов строки, которую она сравнивает с оригиналом.
Вот тебе и подбор паролей =)

Что мешает создать программу, которая будет на таком же алгоритме расшифровывать? Брать те же первые 4 символа и вставлять их в начале слова...

Имхо, даже логически хеши в ipb будет труднее рисшифровать, чем в твоем варианте.

юзайте crypt() с рандомной солью и не зайте проблем =))) на разных серваках хеши не сойдутся =)

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

напиши мне алгоритм расшифровки?

ЗЫЫЫ Я не имел ввиду местных Анют!! %) :d

Эта другая тема асболютно. Постановка твоего метода была направлено на то, что метод шифровки был известен.

но согласитесь, можно и в Cms и в опен-сорс форуме
к примеру в админке сделать выбор между тремя методами составления соли.
этого хватит на сотни лет перебора брутом.

Дикс
Ты сильно заблуждаешься.
Попробуй лучше такой метод.
Массив salts = {соль1, соль2, соль3, соль4, .... , сольn}
hash(pass, current_salt)
{
a = md5(current_salt.pass);
for(i=0;i<count(salts);i++)
a = md5(salts[i].a);
return a;
}

В данном случае фактически используется альтернативный алгоритм хеширования, чтобы брутить его, как минимум нужно иметь доступ к диску (чтобы получить массив salts) и к sql-базе данных (там хеши и current_salt для каждого из них).
Но даже если эти условия выполняются, перебор будет производится значительно медленней.


Я хочу сказать следующее: не пытайся придумать "невзламываемую" систему, насколько мне известно, за последние 6000 лет этого никому не удавалось.

сегодня полдня думал над усложением системы.
в итоге придумал такую хрень:

1. юзер регается. вводит пароль forest
после регистрации ему выводится сообщение:
"ваш новый пароль: Xforest" где X - рандомное число от 1 до 6 (если у вас стоит проверка на то что пароль должен быть не менее семи символов)

а вот как он хешируется:
if (первый символ пароля == 1)
// способ первый
беруца 2,4,6 символы и вставляются после первого
>1frsforest
затем хешируется

if (первый символ пароля == 2)
// способ второй
беруца 2,4,6, затем инвертируются и вставляются после второго символа пароля
>2fsrforest
хешируется

...

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

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

взглянем на это с другой стороны:
у хацкера есть все шесть алгоритмов (это более реально).
для брута ему надо перебрать все шесть вариантов! потому что он не знает число юзера.
это увеличивает срок брута в шесть раз!

как вам такая система?

Если на это рассчитывать (непреступность кода) - то достаточно и просто любой символ (один) подставлять и хэшировать. Все равно код никто не увидит и не поймёт, как хэшируется пароль. ихихи.

А вот про шесть алгоритмов - это стоящая идея. Хотя накладные расходы при большой посещаемости (например, большого портала) достаточно приличные будут.