C, PHP, VB, .NET

Има два вида добавяне на salt към парола. Първия вид е залепването на допълнителен код към паролата и криптирането им заедно (като този код остава известен само и единствено в приложението). Това е популярно също като "глобален salt". Ето какво би се получило след използването на изключително популярната за повечето англоговорящи потребители парола "password":

<?php
	define(SALT, "fd321sfds%#%");

	function saltencrypt($password, $salt){
		return md5($salt.$password);
	}

	echo md5("password");
	echo "<br>";
	echo saltencrypt("password", SALT);
?>

Първият отпечатан на екрана hash ще бъде разпознат от всяка налична rainbow таблица. При втория сме добавили един сложен символен низ (внимание - в примера е изключително къс, а трябва да е много по-дълъг!) в началото и сме почти убедени, че не съществува rainbow таблица, в която той да участва в някаква комбинация. Както забелязвате този символен низ е статичен (дефиниран е като константа). Той трябва да бъде пазен в скрипта за автентикация, защото е нужно да го използваме при сравняване на потребителската парола. Този salt символен низ трябва да бъде пазен изключилено строго.

И все пак можем да достигнем до вариант чрез brute force атака хакера да открие низа на свой собствен акаунт, а от там да открие и въпросния SALT, след което да си генерира нова rainbow таблица с него. Поради тази причина е много важно да миксираме salt с паролите по такъв начин, че да не се забелязва очевиден начин за тяхното разделяне. Така дори да открие първоизточника (ключа), хакера ще продължава да бъде в неведение за това как точно да генерира нова rainbow таблица, с която да търси. Добър вариант за това е да се използва симетрично криптиране, като паролата е стойността, а salt е ключа (обн. 25.03.2012г. - в тази статия е показано как).

При използването на "глобален salt" има редица проблеми и слаби места. Например при него сериозен проблем е този с повтарящите се пароли. Винаги е възможно двама потребители в системата да използват една и съща парола. Нормално е да се досетим, че записаните в базата данни криптирани версии също ще съвпадат. Въпреки, че в повечето случаи е практически безполезна, това все пак е допълнителна информация за атакуващия, чрез която все пак му даваме насока за търсене. Също така за да разбие паролите хакера трябва да направи само един единствен brute force на своя собствен акаунт. В момента, в който открие глобалния salt, той вече е готов да направи пълноценна rainbow таблица, от което следва разбиване на много други пароли от системата.

За избягване на тези проблеми се използва вторият вид salt. Той се състои в допълнителна уникална характеристика за потребителя, която използваме като допълнителна част от ключа за хеш кода. Това може да бъде най-обикновено случайно число, което отново долепваме до нашата парола или пък потребителското име, user id и т.н. В базата данни трябва да пазим както криптираната парола, така и въпросните допълнителни данни, като е много важно те да не могат да бъдат променяни (или ако ги променяме, то трябва да обновяваме и паролата). С тази техника самите хешове в базата данни ще изглеждат различни дори при еднакви пароли. И най-вече постигнахме това, че хакерът ще трябва да генерира самостоятелна rainbow таблица за всеки отделен потребител (обн. 18.03.2012г. - функционалността в базов вид е реализирана в статията AES256-CBC криптиране - в нея вижте файла checklogin.php заедно с дефиницията и съдържанието на базата от данни).

Използвайки втория вид salt в приложението си ние направихме така, че практически обезсмисляме извършването на атаки с rainbow таблици и гарантираме, че могат да се извършват само bruteforce атаки за всяка една парола поотделно (за които нужното време е много повече). При това забележете, че намирането на ключ от колизия не му върши никаква работа - на него му трябва оригиналния ключ!

Добавянето на глобалния вид salt към втория (по-важния!) вид пък ни дава едно ценно допълнително време. Ако със salt от първи тип (глобалния) на хакера са необходими N на брой brute force операции (N са операциите на brute force атаката, с които е успял да открие произволния низ използвайки своята собствена парола), след което трябва да генерира достатъчно голяма dictionary rainbow таблица, с която да успее да намери паролите на ЧАСТ от потребителите (тези потребители, които използват сложни пароли тъй или иначе изискват brute force атака), то с използването на втория тип salt ще са му нужни средно N + M.K на брой операции, за да разбие паролите в системата, където K e броят на потребителите, а M е средното време необходимо за генериране на brute force атака към самата парола. Или казано по друг начин - обезсмислихме rainbow таблиците, което е достатъчен успех на този етап.

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

Задача: Реализирайте скрипт за автентикация, който работи с пароли чрез първия вид salt и база данни.

Задача: Реализирайте скрипт за автентикация, който работи с пароли чрез втория вид salt и база данни.

Задача: Реализирайте скрипт за автентикация, който работи и с двата вида salt едновременно.

Задача: Реализирайте скрипт за автентикация, който работи и с двата вида salt едновременно, като се използва и множествено криптиране.