Криптиране на пароли за потребителска оторизация

Доста често разработчиците на софтуер си задават въпроса: „В какъв вид е най-добре да бъде запазена една парола в базата с данни?“ Повечето програмисти се спират на варианта с най-обикновенно MD5 криптиране, което между другото върши работа, но когато става дума за по-големи системи, където не трябва да се прави компромис с качеството, това не е достатъчно. В много от случаите MD5 хешовете могат лесно да бъдат разбити с помощтта на големи бази данни от MD5 хешове. Поради тази причина софтуерните продукти с отворен код все по-често започват да използват по-сложни варианти за криптиране на паролите. Разбира се, не трябва да се прекалява със сигурността, защото това би могло да окаже влияние на цялостната съвместимост на продукта.

Добро решение на проблема е паролите да се пазят в базата с данни в криптиран вид, заедно с добавена сол. Солта представлява определен набор от символи, които се добавят към паролата, след което паролата бива криптирана заедно с тях. По този начин възможността да бъде декриптирана паролата с използване на хакерски бази данни се свежда до нулева. Единствения вариант за нейното разбиване е да бъде направена BruteForce атака (брутална сила), когато всички възможни комбинации се проверяват и се прави сравнение между паролата в базата и генерирания хеш. Но в този случай хакерите трябва да знаят солта и хеша, също така паролата трябва да бъде примитивна.

Да си представим в момента цялостна система за оторизиране на потребители, без значение на какъв език за програмиране е писана тя (PHP, Python, Java). След регистрация, към паролата на потребителя се добавя случаен набор от символи, които се записват в отделно поле в таблицата. Паролата и солта се запазват заедно в криптиран вид (MD5, SHA1 и т. н.) За да бъде проверено, дали въведената парола от даден потребител съответства на тази, създадена при регистрацията, скрипта прави следната проверка. Взима от полета на таблицата солта, добавя я към въведената парола, криптира двете и сравнява двата хеша. Системата работи, и в същото време е достатъчно сигурна. Постигнахме точно това, което търсихме.

Разбира се, сигурността на една система не зависи само от това в какив вид се пазят паролите. За изграждането осигуряването на сигурността на Вашите системи, можете да използвате услугите на фирма Zapprotect.

Други подобни публикации от Zapprotect:

  1. Значението на паролите
  2. Информационната сигурност при споделения хостинг
  3. Какво представляват SQL инжекциите?
You can leave a response, or trackback from your own site.

4 коментара to “Криптиране на пароли за потребителска оторизация”

  1. Супер. Каква препоръчвате да е солта? Примерно името + паролата. Примерно:
    md5($username.$pass)
    така не могат да се използват rainbow таблици тъй като дължината на хеширания стринг е над 12-14 символа при положение, че името е 6 символа и паролата там някъде. Може и да се добавят и разни специални знаци като . * – + % ^ & , – тогава още по-трудно става.
    Вие как мислите?

  2. admin казва:

    Освен името и парола също така можеш да добавяш и Secret Key. Това е променлива, която разполагаш в някой от конфигурационните файлове. Друга полезна техника е използването на double md5. Например:

    md5(md5($username.$password.$secret_key))

    И въпреки всичко, никога не трябва да се прекалява със сигурността. Хехе. :Р Остави малко вратички и за compatibility. Напълно достатъчен ти е варианта с потребителското име, паролата и секретния ключ.

    В противен случай ако ти се наложи да интегрираш приложението с някое друго ще имаш проблеми. За пример мога да дам phpBB след 2.7 версия, когато въведоха отделно криптиране за паролите. Лично аз съм се сблъсквал с проблема, че не може да се преместят потребителите от форума към друг сайт заради прекалено добро криптиране.

    За да избегнеш това нещо можеш да добавяш солта след вече md5 криптираната парола. Примерно:

    md5(md5($password).$secret_key.$username)

    Има друга много интересна техника, която съм срещал при Django. Паролите в базата данни се пазят в следния вид:

    <crypy_type>:<salt>:<crypt_type(salt+password)>

    Уникално лесно, и много трудно за разбиване – това нещо се разбива само с Brute Force атака, и то при положение, че имаш достъп до базата с данни…

    Това са основните начини са осоляване на пароли. Препоръчвам последния – виж как е реализирано в Django Framework.

  3. Не те разбрах много правилно с последния пример. Нещо от рода на:
    md5(::)

    Нещо такова?
    Също какво хеширане бихте използвали вие? MD5 или SHA1 ?

  4. admin казва:

    Нещата трябва да се разглеждат от няколко спектъра. Ако говорим за алгоритъм, който теоритически може да се разбие, то SHA1 е по сигурен. Той предлага 160 битово криптиране, докато MD5 предлага 128 битово. Освен SHA1 е бил разработен от NSA, като усъвършенствана версия на MD5. Предполага се, че предоставя поне малко по-добра сигурност.

    Ако говорим за съвместимост, всички модерни CMS и криптират използвайки MD5. Така че, ако нещата се разглеждат от гледна точка на съвместимостта, по-добре е да се използва MD5 криптиране.

    Нещото което имах впредвид с предишния си пост беше паролата да се пази базата данни като VARCHAR: md5:dfssa:gsadj5gs23jgsakdkhgdsat2t3zvc, като по този начин имаш възможност и да ротираш криптирането: за един запис да е md5, за друг sha1 (като имаш впредвид, че вида на криптирането също може да е криптиран. На 2-ро място ти е солта, на трето място самия hash.

Коментирай

  • Славчо Хаджийски: Аз не съм толкова в час с нещата, в които се ровя ... »
  • DIDEXS: Това е доста полезно точно това ми трябваше за да ... »
  • Делян: Атанасе моля те хващай мотиката и стига писа глупо... »
  • Делян: Сара ще да е изхвърчала от Сони като тапа от задни... »
  • Делян: За домашни потребители, които нямат чуствителна ин... »