Изпечатай

[Mitaka]

Не е нищо ново, но ето какво ми хрумна:

Имаме потребители в база данни, чиито пароли криптираме, да кажем с crypt(). Ако някой се докопа до базата даннни, макар и трудно, той би могъл да декриптира паролите.
Ето каква е идеята ми:

При регистрация на потребител освен парола, той въвежда и key - произволна комбинация от букви и цифри например. Този ключ НЕ се пази в базата данни - просто според него получената стойност от crypt() се криптира още веднъж с xtea алгоритъм, т.е. имаме нещо подобно:

xtea_crypr(crypt(string), key);

xtead_decrypt(xtea_crypted_string, key);

идеята е, че след като ключа, с който е криптирана съответната парола не се пази никъде, т.е. известен е само на потребителя, то дори базата данни да бъде открадната по някакъв начин, то вероятността за кражба на паролата е сведена до минимум, и повечето зли хакери биха се отказали.

За пример:
$1$/3cCifbJ$3J6/eQwaBN2/3pkVRr1QL0   =  123

Но тук получавме:

root@dimitar-desktop:/crypt# ./main '$1$/3cCifbJ$3J6/eQwaBN2/3pkVRr1QL0\'
To crypt: $1$/3cCifbJ$3J6/eQwaBN2/3pkVRr1QL0\ with key:1aff56bf9c19c4dd
Crypted: SKkSDdXVdH9mYkokM0o2L2VRd2FCTjIvM3BrVlJyMVFMMFw=
Decrypted: $1$/3cCifbJ$3J6/eQwaBN2/3pkVRr1QL0\

Т.е. без да знаем ключа (в случая - 1aff56bf9c19c4dd) няма как да достигнем до стринга $1$/3cCifbJ$3J6/eQwaBN2/3pkVRr1QL0\ и съответно до декриптираното 123, което реално се декриптира за секунди.....

[sdr]

И дефакто имаме две пароли вместо една мноо хитро. Иначе хората са го мислили този проблем преди тебе http://en.wikipedia.org/wiki/Salt_(cryptography) хубаво е че си се замислил де '>

[VladSun]

Идеята е сходна с тази използвана във всички "нормално" написани системи за автентификация. Предполагам знаеш, че хората използват т.нар. salt&pepper защита на паролите:
- едното се изразява в добавянето на уникален за потребителя и известен стринг към паролата (най-често потребителското име) преди хеширането й. По този начин се гарантира, че няма да се получат два еднакви хеша на паролите;
- второто се изразява в добавянето на секретен стринг (ключ) към паролата преди хеширането й. По този начин се гарантира ниската ефективност на речник-базираните атаки и подобните им;

С други думи, хешът в една база представлява примерно:

Примерен код

hash = md5(key + password + username)

Съответно и проверката е подобна.

Освен това, "големите глави" казват, че не е добре да се използват съставно няколко алгоритъма за криптиране - т.е. примерно:

Примерен код

sha1(md5(password))

Тъй като евентуално бъдещо откриване на пробив в сигурността, на който и да е от използваните алгоритми може да доведе до общ пробив за твоя алгоритъм. Т.е. с всеки един допълнително използван алгоритъм се повишава риска от пробив.

Твоя алгоритъм (ако съм те разбрал правилно) има един съществен плюс, който е и минус - няма запазване на секретния ключ, но в същото време караш потребителя да помни един параметър повече.

Освен това забелязвам, че криптираш и декриптираш - според мен е достаъчно само да хешираш, както в горните примери.

[gat3way]

Мммм същото нещо ще постигнеш ако пазиш md5 сумата на това, което е криптирано с crypt() само че с определен salt - ролята на твоят ключ се изпълнява от salt-а, а дали потребителят ще го въвежда или той ще си е някакъв hardcoded, или пък има някаква схема, по която той се сглобява примерно от дата на регистрация или нещо от сорта, няма значение. И в двата случая увеличаваш множеството от възможни автентикационни tokens и намаляваш вероятността по някакъв начин човек да ги познае.

[VladSun]

Като се замисля, не ми се струва добра идея да се дава генерирането на salt (де факто) в ръцете на потребителя. Както всички знаем, ТЕ имат навика да използват слаби пароли '>

[Mitaka]

Цитат

Твоя алгоритъм (ако съм те разбрал правилно) има един съществен плюс, който е и минус - няма запазване на секретния ключ, но в същото време караш потребителя да помни един параметър повече.

Идеята е именно този ключ да не се съхранява по никакъв начин никъде другаде, освен в главата на потребителя '> Това ще затрудни до максимум, дори до отказ "хакерите", т.е. без ключа информацията е безполезна. С други думи - получаваме нещо като криптиран мейл, за който нямаме частния ключ, за да го прочетем, макар това да е много много опростен вариант.

То че ще има минуси ще има.. няма нищо без минуси.
А криптирането/декриптирането е просто за пример.

[gat3way]

Е, няма нужда толкова да се издребнява според мен '> В смисъл и salt-a да не е чак толкова уникален, идеята според мен е да не може да се match-ва криптираната стойност срещу един голяяям масив с готови приготвени такива на базата на речник от често използвани или пък на такъв от всички възможни по някакви там правила. В смисъл не вярвам злият хахор да си има такива речници спрямо най-често използваните salts, би отнело безумно много място на диска.

Но да де, може да си ги изгенерира ако има огромното желание,време и нерви да го прави '>


Пък и после ако човек има възможност да чете/пише в базата, може би паролите няма да са му толкова важни, в смисъл най-малкото примерно ще си създаде акаунт с необходимите права примерно, знам ли '>

[VladSun]

Ясно, ама един хахор дори и да разполага с ключа ще му е практически невъзможно да "декодира" паролите от така направените хешове ...

[VladSun]

Цитат (gat3way @ Сеп. 22 2008,13:11)

Е, няма нужда толкова да се издребнява според мен '> В смисъл и salt-a да не е чак толкова уникален, идеята според мен е да не може да се match-ва криптираната стойност срещу един голяяям масив с готови приготвени такива на базата на речник от често използвани или пък на такъв от всички възможни по някакви там правила.

Точно поради причината, която изтъкнах по-горе, не трябва да се дава генерирането на salt-a на потребителя, защото:

Примерен код

salt='gate'; pass='way' hash=md5(salt + pass)

И се получава лесен за атакуване хеш.

[gat3way]

Не съм съгласен '>

salt='gate'
pass='way'

cryptpw=md5(crypt(pass,salt))

'>

[VladSun]

Мммне...
Така пък попадаш в другото изискване - да се избягва съставното използването на различни алгоритми за хеширане.

[gat3way]

Е то е криптиране+хеш функция. При DES има начин да изкараш крава обратно от криптирания мутант, докато при MD5 не говорим за мутант, а за кайма, аз поне не знам някой да е направил от каймата крава.

[VladSun]

Към *момента* това е вярно '>
Но за в близко бъдеще ... дали?

[gat3way]

Аз честно казано съм мислил по тоя въпрос известно време, даже веднъж водих едни спорове тука за вероятности за колизии и дали зависят от дължината на съобщението или не '> В крайна сметка май няма значение, вероятността си остава една и съща, защото съобщението се цепи на блокове и се прави една хватка блок по блок, накрая ако ще да са 20 или 2000 блока, вероятността да се срещнат 2 съобщения с еднаква хеш сума остава същата.

Но честно казано не мисля, че някога някой ще открие начин да прави от каймата обратно крава. Единствено може би някой ден ще открият достатъчно бърз начин да приготвят кайма от друга крава, която да няма никаква разлика с търсената кайма.

[Mitaka]

Хаха, примера с каймата и крвата ми хареса '>
Иначе нчини да се кодира една парола много... идеята е да се избере най-сигурният, макар, че 100% сигурни работи няма.
Например, по такъв начин би било подходящо да е криптира чувствителна информация, да кажем - номера на кредитни карти, които повечето онлайн търговци имат навика да запазват в профилите на поттребителите, уж с цел улеснение.
Веднъж съм попадал на подобна база, като прехвърлях един оскомерс от един сървър на друг.... номерцата бяха в чист, некриптиран вид. Такава информация аз лично бих я криптирал точно по посоченият начин - с ключ, известен само на потребителя... но въобще не казвам, че това е най-подходящият начин.