Linux за българи: Форуми

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

Имаме потребители в база данни, чиито пароли криптираме, да кажем с 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, което реално се декриптира за секунди.....

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

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

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

Примерен код

hash = md5(key + password + username)

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

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

Примерен код

sha1(md5(password))

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

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

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

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

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

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

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


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

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

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

salt='gate'
pass='way'

cryptpw=md5(crypt(pass,salt))

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

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

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

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

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

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

I think the suggestion to double-hash your password is not a good idea.  You are much much better off adding a variable salt to passwords before hashing (such as the username or other field that is dissimilar for every account).

Double hashing is *worse* security than a regular hash.  What you're actually doing is taking some input $passwd, converting it to a string of exactly 32 characters containing only the characters [0-9][A-F], and then hashing *that*. You have just *greatly* increased the odds of a hash collision (ie. the odds that I can guess a phrase that will hash to the same value as your password).

sha1(md5($pass)) makes even less sense, since you're feeding in 128-bits of information to generate a 256-bit hash, so 50% of the resulting data is redundant.  You have not increased security at all.

Да не говорим, че не се знае дали няма да направи output-а доста по слаб за разбиване (говорим математически е трудно да се докаже, че като минеш през те3и функции не елиминираш част от свойствата) Също така другия аргумент, е че не се знае дали няма трети стринг, които да произведе това, което ти си произвел без да минава през double-hash. И много много други подобни аргумент.. Изобщо double-hashing е глупост, за DES е доказано че ако се мине с hash-функцията базирана на него няколко пъти не се елиминира, а се подобрява сигурността (за това има 3DES :).
А някои също така маи трябва да прочете man crypt :).

P.S. Има hash concatenation, но то е съвсем друго нещо (всушност за това става дума, че когато единия е слаб... etc)

(Translated with 62c, sorry for the syntax).