Да, сравнението на низове (и/или търсене в индекс) може по принцип да разкрие колко еднакви водещи байта хешът на паролата е съхранен в базата данни и този, изчислен от въведената парола.
По принцип нападателят може да използва това, за да научи итеративно префикс на хеша на паролата, байт по байт:първо намира хеш, който споделя първия си байт с хеша в базата данни, след това такъв, който споделя първите си два байтове и т.н.
Не, това почти сигурно няма да има значение.
Защо? Е, поради редица причини:
-
Атака във времето може позволи на нападателя да научи част от хеша на паролата на потребителя. Добре проектирана схема за хеширане на пароли (с помощта на сол и разтягане на клавиши ), обаче, трябва да остане сигурен (приемайки, разбира се, че самите пароли не са лесно познати), дори ако нападателят знае цялото хеш на паролата. По този начин, дори ако атаката във времето е успешна, самите пароли ще бъдат безопасни.
-
За да извърши атаката, нападателят трябва да изпрати пароли, чиято хеш стойност знае. Стойността на хеша зависи от солта. По този начин, освен ако нападателят по някакъв начин вече не знае солта, тази атака не е възможна.
(Вярно е, че в повечето анализи на сигурността на схемите за хеширане на пароли се приема, че солта е публична информация. Това обаче е само защото такива анализи предполагат най-лошия сценарий, споменат по-горе, при който нападателят вече е получил копие на цялата потребителска база данни, соли и хешове и всичко останало. Ако нападателят все още не знае хеша, няма причина да предполагаме, че ще знае солта.)
-
Дори ако нападателят познава солта, за да извърши итеративната атака, описана по-горе, той ще трябва да генерира пароли, които хешират до стойност с желания префикс. За всяка защитена хеш функция единственият практичен начин да направите това е чрез пробна грешка, което означава, че времето, необходимо за това, нараства експоненциално с дължината на префикса.
Това на практика означава, че за да се извлекат достатъчно много битове от хеша, за да може да се извърши офлайн атака с груба сила срещу него (което не е задължително да са всички; просто повече от ефективното количество ентропия в парола), нападателят трябва да извърши приблизително толкова изчисления, колкото е необходимо, за да разбие самата парола. За добре разработена схема за хеширане на пароли и сигурно избрана парола това не е възможно.
-
Какво може итеративната атака дава на нападателя, по принцип, е способността да извършва по-голямата част от изчисленията с груба сила локално в техния край, като същевременно подава сравнително малък брой пароли на вашата система. Въпреки това, дори това е валидно само ако получат подробна и надеждна информация за времето обратно от всеки изпратена парола. На практика атаките в реално време са изключително неефективни и изискват много (често хиляди или милиони) заявки за получаване на някои полезна информация изобщо. Това много вероятно ще отмени всяко потенциално предимство в производителността, което атаката по време може да предостави на нападателя.
Тази точка се усилва, ако използвате правилна схема за хеширане на пароли за разтягане на ключове, тъй като такива схеми са умишлено проектирани да бъдат бавни. По този начин сравнението на низове в базата данни вероятно ще отнеме незначително време в сравнение с хеширането на паролата на първо място и всички вариации във времето, причинени от него, ще бъдат загубени в шума.
