C, PHP, VB, .NET

За кода в предишната статия, в която се демонстрира „завършената“ форма за автентикация с поддръжка на автоматично влизане с cookie, има допълнителни фактори, на които би трябвало да обърнем внимание при запазването на паролите. Нека припомним как записвахме паролите в базата данни:

hashedpass = HASHCODE ( ‘SALT1passwordSALT2’ )

В тази формула „hashedpass“ е защитената парола (записана в базата данни), „SALT1“ трябва да е много дълъг произволен низ, който записваме в кода на приложението и до който правим всичко възможно да няма външен (та дори и вътрешнофирмен) достъп, „SALT2“ беше псевдослучайно число или низ, записан за всеки отделен акаунт в базата данни, „password“ е паролата на клиента, а „HASHCODE“ e хеш функция, която приемаме за сигурна и непробиваема (т.е. възползваме се от цялата ѝ ентропия). Нека припомним предимствата и недостатъците на двата вида salt:

• SALT1
  • Предимства: Подсигурява хешовете записани в базата данни от съществуващи rainbow таблици. Низът е записан в приложението и се предполага, че не е наличен за хакер, който има достъп само до базата данни.
  • Недостатъци: Достъп до сорс кода на приложението излага секретния низ на показ, а от там хакера може да създаде нова rainbow таблица спрямо него. Освен това две еднакви пароли на различни потребители ще имат един и същи хеш код.
• SALT2
  • Предимства: Подсигурява хешовете записани в базата данни от съществуващи rainbow таблици, като при това долепеният низ е различен за всеки един потребител (т.е. хакерът не може да се възползва от създаването на нова rainbow таблица, която да използва за всички потребители, а ще му се наложи да атакува всеки един поотделно). Потребители с еднакви пароли ще имат различни хеш кодове.
  • Недостатъци: Низовете са налични в базата данни, до която се предполага, че хакерът има достъп по принцип (той е откраднал хеш кодовете именно от нея). Затова и offline brute force атака срещу конкретен потребител остава като наличен проблем.
• SALT1+SALT2
  • Предимства: Всички предимства на SALT2, като в допълнение на това хакерът евентуално няма достъп до SALT1, което не му позволява да прави дори offline brute force атаки към паролата (трябва да ги прави към паролата И SALT1 едновременно).
  • Недостатъци: Достъп до сорс кода на приложението излага секретния низ SALT1 на показ и от там нататък защитата се свежда до нивото на тази на използването на SALT2.

Как би процедирал хакер, който е добил достъп до базата ни от данни? За него ще са налични хеш кода и SALT2. Естествено предполагаме, че самия той има акаунт в системата ни, следоветелно за един от откраднатите хеш кодове той знае паролата. Или от примерната формула горе следва, че хакерът знае hashedpassword, password и SALT2 за един от акаунтите. За останалите акаунти знае само hashedpassword и SALT2. За да започне да атакува други акаунти с offline brute force атака той все още трябва да намери SALT1. Следователно сведохме защитата ни до:

1. Хакерът трябва да направи offline brute force атака върху своя собствен акаунт, с цел намирането на SALT1. Ако този низ е много дълъг и използва много специални символи извън ASCII таблицата, то това може да отнеме огромно количество време. Нека това време е t1.
2. След като евентуално е намерил SALT1, хакерът трябва да генерира нова offline brute force атака за всеки един потребител отделно. Това също отнема голямо количество от време (в зависимост от дължината и сложността на конкретната парола), което ще отбележим средно като t2 за акаунт.
3. Ако паролите на нашите потребители са „сигурни“ (достатъчно дълги и използващи специални символи), а HASHCODE е достатъчно сигурен хеш алгоритъм, то практически увеличаваме драстично времето t2 и така свеждаме вероятността хакера да може да атакува даден акаунт до „практически невъзможно“.

Виждаме, че за хакването на един акаунт ще отнеме средно време t1 + t2, а на N акаунта t1 + N.t2. Дали обаче това е реално така и дали така записаната защита е достатъчна? Всъщност има допълнителни фактори, които досега въобще не отчитахме:

• Наистина ли е „непробиваем“ хеш алгоритъма? Какво ни гарантира, че в бъдеще няма да бъде открит пробив в него? И ако поддържаме голяма система с много потребители, то какво ще правим, ако евентуално е открит пробив в хеш алгоритъма? Смяната му в „production“ система не винаги е лесно действие.
• Вътрешнофирмена сигурност – невероятно ли е нашият администратор на базата данни да компрометира сигурността на системата и да изнесе данни? Или някой от локалната мрежа просто е успял да подслуша трафика между уеб сървъра и базата данни (а ние не сме го криптирали с SSL, за да спестим натоварване на сървърите, нещо което всъщност е нормална практика)? Изобщо защитена ли е системата ни срещу изнасяне на информация отвътре?

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

Всъщност в примера от предишната статия е допусната една огромна грешка, а именно: там изпращахме низа SALT1password директно в чист вид чрез SQL заявката към сървъра. Кой гарантира, че човекът добил достъп до базата данни няма и достъп до трафичните данни, които СУБД приема от приложението? Например тривиално това е нашият администратор! Тоест ние излагаме нашият хеш код SALT1 свободен за четене извън рамките на зоната на сигурност на сорс кода на приложението!

Сега набързо ще разгледаме поотделно двата проблема.

Хеш алгоритъмът е „пробит“

Всъщност няма нищо ново под слънцето – това се е случвало с известни и популярни в миналото алгоритми и нищо не предвещава, че няма да продължава да се случва. Алгоритъм, който днес смятаме за „най-доброто“ може още утре да се окаже „напълно ненадеждно“. И засега никой не може да ни гарантира, че това няма да е така.

Ето ви примерен сценарии – хакер е успял да източи всички хеш кодове на пароли от базата ни данни. В същия момент се оказва, че за хеш алгоритъма, който сме използвали е намерена ужасяваща (за нас) уязвимост и хакера спокойно започва да открива колизии на нашите хеш кодове за доста по-кратко време, отколкото сме предполагали, че ще може (ентропията е намалена). На този етап все още сме спокойни, защото колизиите сами по себе си не вършат работа – на хакера му трябва оригиналния низ, а не негова колизия. А нашият SALT1 е бил толкова дълъг, че предполагаме, че трудно ще стигне до оригиналния низ. Само, че „времето е пред него“. Рано или късно ще го открие и при достатъчно „пробит“ хеш алгоритъм може да се окаже така, че търсенето на колизии да отнема време доста по-малко от очакваното преди това от нас t1. И понеже алгоритъмът е един и същ – t2 също ще е драстично намалено. С други думи цялата ни защита е провалена от евентуалния провал на хеш алгоритъма.

Администраторът на базата данни ни краде / някой подслушва трафика между приложението и базата данни

Тук предполагаме, че хеш алгоритъмът НЕ е „пробит“. Но за сметка на това най-доверените ни хора крадат информация от нас. По-горе споменах, че сме допуснали голяма грешка като предаваме SALT1password директно в заявката. Да припомним как правихме това:

...
$pass = SALT.$pass;
...
$sql = "SELECT id FROM users WHERE user = '$user' ";
$sql .= "AND pass = SHA2(CONCAT('$pass',CAST(token AS CHAR)),256)";
$result = mysql_query($sql);
...

Ако потебителят е „pencho“, нашият SALT1 например е „sdagfdjkgf24243“ (бел.ред. това е доста къс salt!), паролата на потребителя е „Iv@ansSecPa$$“, а token (SALT2) в базата данни е „0.2579033621663531“, то ние най-официално изпратихме заявка до базата данни:

SELECT id FROM users
WHERE user = 'pencho'
AND pass = SHA2(CONCAT('sdagfdjkgf24243Iv@ansSecPa$$',
CAST(token AS CHAR)),256)";

Тъй като хакера знае token за потребител pencho, то възпроизвеждането на низа става елементарно:
sdagfdjkgf24243Iv@ansSecPa$$0.2579033621663531
Така виждаме, че човек с достъп до СУБД всъщност има достъп до низа SALT1. А това е напълно против нашата философия за SALT1! Със сигурност загубихме времето t1 и сведохме атаката до стандартната защита със SALT2.

Да „разбъркаме“ ли SALT1 с password по различен начин? – не е добро решение

При всички положения „SALT1password“ НЕ е правилният начин за добавяне на „сол от първи тип“ към паролите. Конкатенацията в началото или в края не води до значителна защита на данните – много лесно се изолира кое е „солта“ и кое е паролата.

Някои хора се досещат, че може не просто да долепят низовете един до друг, но и да ги „разбъркват“, да изместват символите в ASCII таблицата или изобщо да се опитат да скрият чрез бърз, но наивен алгоритъм начинът, по който са „смесени“ SALT1 и password. За съжаление дори да направим това ние не правим много – това, което му трябва на „хакера“ получил този низ е да провери как са миксирани данните при своя собствен акаунт (за който той знае своята собствена парола). Тоест едва ли ще му е трудно да открие начинът, по който сме го направили, ако сме подходили толкова елементарно.

Развивайки идеята си по-напред можем да достигнем до написването на наш собствен алгоритъм за симетрично криптиране или хеш алгоритъм. А защо? Дали той ще е по-труден за пробиване отколкото наличните? Малко вероятно е. Затова – НЕ, „разбъркването“ на SALT1 с паролата с някой наш собствен алгоритъм НЕ е добро решение, освен ако не сме наистина гениални математици и програмисти!

Да „разбъркаме“ и SALT2? – не по-добро от лошото решение

Преминаваме „една идея напред“ и решаваме да разбъркаме SALT1 със SALT2 и с паролата, но пак няма да имаме голям успех. Той знае SALT2 и паролата за своя си акаунт, следователно задачата му не е много по-трудна от тази в миналата точка… Наистина дали ще търси начина за миксиране между SALT1 с един низ или SALT1 и два познати низа реално се свежда до една и съща задача.

Изобщо смисълът на SALT2 е съвсем друг – да принудим хакера да прави отделни brute force атаки към всеки отделен потребител и да не може да се възползва от готова rainbow таблица, т.е. по този начин увеличаваме драстично необходимото време за атака. SALT2 не може да участва в защитата на SALT1, защото е видим и е наличен от страната на вече приетата за компрометирана база от данни.

Да хешираме паролата и SALT преди да ги изпратим към базата данни – добро решение

С други думи вместо

$pass = SALT.$pass;

да ги хешираме:

$pass = hash('ripemd160', SALT.$pass);

и така полученият хеш код да се изпрати към втория хеш алгоритъм към базата данни (с долепен SALT2 към него естествено):

$sql = "SELECT id FROM users WHERE user = '$user' ";
$sql .= "AND pass = SHA2(CONCAT('$pass',CAST(token AS CHAR)),256)";
$result = mysqli_query($link, $sql);

По този начин реално заявката придоби следният вид:

hashedpass = HASHCODE1 ( HASHCODE2(‘SALT1password’ + ‘SALT2’)

където последователността и мястото на извършване на операциите за хеширане е много важна! Трябва да отбележим следното:

• HASHCODE1 и HASHCODE2 е добре да са два различни хеш алгоритъма. По този начин разчитаме на сигурността на два различни алгоритъма, вместо на един единствен, т.е. „пробиването“ на единия не компрометира цялата система.
• HASHCODE2 се прилага от приложението, а НЕ от СУБД. Към СУБД предаваме само хешираните от HASHCODE2 данни, а SALT1 не го предаваме в чист вид към никакви външни канали.

Така постигнахме относително доста по-високо ниво на защита. За съжаление продължаваме да имаме недостатъка на SALT1, който имахме в началото – прочитането на сорс кода на програмата разкрива SALT1 в чист вид, което обезсмисля направеното действие с допълнителното хеширане. В случаят спечелихме само в това, че от страната на базата данни SALT1 не е наличен и задължихме хакера да го търси с offline brute force атака (от примерния код – срещу ripemd 160 хеш алгоритъм).

Да хешираме паролата и SALT с HMAC преди да ги изпратим към базата данни – също добро решение

Идеята е много сходна с предишната – вместо

$pass = SALT.$pass;

да използваме някой хеш алгоритъм с hmac с ключ SALT, например:

$pass = hash_hmac('ripemd160',$pass, SALT);

и така полученият хеш код да предадем към SQL сървъра, както го правихме преди:

$sql = "SELECT id FROM users WHERE user = '$user' ";
$sql .= "AND pass = SHA2(CONCAT('$pass',CAST(token AS CHAR)),256)";
$result = mysqli_query($link, $sql);

Този подход е много сходен с предшния, да не кажем направо, че е същия. В случая от използването на HMAC не печелим нищо от гледна точка на сигурността. Даваме този пример, защото често се дава в примерни кодове по различни сайтове. HMAC алгоритмите имат съвсем различно предназначение. Повече за HMAC прочетете тук.

При този метод продължаваме да имаме недостатъка при пробив с прочитане на сорс кода на приложението.

Симетричното криптиране – също добро решение

Вместо хеш алгоритъм можем да използваме (задължително силен) алгоритъм за симетрично криптиране – например AES256. Ето как трябва да променим примерния сорс код:

Файл salt.php (намира се в директория /…/htdocs/includes/):

<?php
	define('SALT', 'adsa34343SFhsjfdsF');
	// Допълнителен произволен низ за initialization vector
	define('IV', 'p9erRikVm123');
?>

Файл checklogin.php (намира се в директория /…/htdocs/includes/):

...
// Вместо "$pass = SALT.$pass;"
$pass = openssl_encrypt($pass,'aes-256-cbc',SALT,IV);
...

След което, както преди, правим конкатенацията със SALT2 и хешираме с SHA256 със заявка към базата от данни, по същия начин както го правихме преди. Естествено трябва да сме записали паролата в базата данни криптирана и хеширана по същия начин (това важеше и за предишните два метода). С този метод продължаваме да имаме недостатъка, че SALT1 ще стане известен при прочитане на сорс кода на приложението.

Резултати:

Доколко си помогнахме с използването на един от последните три метода? При „пробит“ хеш алгоритъм може евентуално да се изолира хешираният/криптираният $pass от SALT2 за някоя парола. Същото важи и при подслушването на трафика или поемането на контрол над СУБД – там тривиално ще се изолира хешираният/криптираният $pass от SALT2. Тази хеширана/криптирана парола обаче все още не върши никаква работа! Тя трябва да бъде декриптирана, за да може да бъде използвана. И по-точно трябва да бъде налучкан (предполагаемо възможно само чрез bruteforce) SALT1, за да може впоследствие да се правят нови brute force атаки и то за всеки един потребител поотделно (заради наличието на SALT2). В крайна сметка добавихме следните ползи към приложението:

• Защитата ни не зависи от един единствен алгоритъм за хеширане, а вече зависи от два различни хеш алгоритъма или от един хеш алгоритъм и един за симетрично криптиране. По този начин частично се подсигуряваме от евентуални открити сериозни проблеми с използвания основен хеш алгоритъм в бъдеще.
• Каквото и да става със сигурността на основния хеш алгоритъм, ние категорично си гарантирахме нуждата от минимално време t1 за brute force атака срещу SALT1.

Или по друг начин казано – ако хакерът има достъп само до базата данни (включително до цялото СУБД), то ние си гарантираме, че той ще трябва минимално да отдели време t1, за да пробие паролите ни. Все още не сме решили проблема със защитата на SALT1, който стои явно в сорс кода на приложението. Какво да направим ако друг вътрешен човек, като например програмист работил по приложението, еветуално се сдобие с ценния низ SALT1? Тогава ние продължаваме да разчитаме на основната защита, а именно хеш алгоритъм приложен върху паролата с конкатениран SALT2, което би отнело време t2 за акаунт. В крайна сметка си гарантирахме времето t1 + N.t2 за „хакване“ на N акаунта, като вече t1 не зависи от t2 и обратно. А нека припомним, че и двете сами по себе са си дълги времеви интервали, особено ако се използва множествено криптиране (т.е. допълнително забавяме всяка една операция от brute force атаката и така правим хеш алгоритмите бавни)!

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

Наистина „мерките за сигурност“ дискутирани в настоящата статия са малко „параноични“. Истината в реална практическа ситуация е, че е напълно достатъчно да подсигурим низовете си само със SALT2 и да разчитаме на времето t2 средно за всеки един акаунт. Тази допълнителна защита със SALT1 обаче не отнема кой знае колко процесорно време, а добавя още значително голямо допълнително време t1. Нищо не пречи да се възползваме, но трябва да го правим така, че да има смисъл да го правим, а не да се „самокомпрометираме“ още в самото начало, както беше в примера от предишната статия.