If-Koubou

Защо трябва да се притеснявате, когато базата данни за пароли на услугата е изтекла

Защо трябва да се притеснявате, когато базата данни за пароли на услугата е изтекла (Как да)

"Базата данни за паролите ни беше откраднато вчера. Но не се притеснявайте: паролите ви са били шифровани. "Ние редовно виждаме изявления като тази онлайн, включително вчера, от Yahoo. Но трябва ли наистина да приемем тези уверения на стойност?

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

Как трябва да се съхраняват паролите

Ето как компаниите трябва да съхраняват пароли в идеален свят: Създавате акаунт и давате парола. Вместо да съхранява самата парола, услугата генерира "хеш" от паролата. Това е уникален пръстов отпечатък, който не може да бъде обърнат. Например, паролата "парола" може да се превърне в нещо, което прилича повече на "4jfh75to4sud7gh93247g ...". Когато въведете паролата си за вход, услугата генерира хеш от нея и проверява дали стойността на хеш съответства на стойността, съхранена в базата данни. В нито един момент услугата ни не запише самата парола на диска.

За да определите действителната си парола, атакуващият с достъп до базата данни трябва предварително да изчисли хешове за общи пароли и след това да провери дали те съществуват в базата данни. Атакуващите правят това с таблици за търсене - огромни списъци с хешове, които съответстват на пароли. Хешовете могат да бъдат сравнени с базата данни. Например, хакерът би разбрал хеш за "парола1" и след това да види дали някакви акаунти в базата данни използват този хеш. Ако те са, атакуващият знае, че паролата им е "password1".

За да се предотврати това, услугите трябва да "солират" своите хешове. Вместо да създават хеш от самата парола, те добавят произволен низ в предната или в края на паролата, преди да я закачат. С други думи, потребител ще въведе паролата "парола" и услугата ще добави солта и хеш парола, която прилича повече на "password35s2dg." Всеки потребителски акаунт трябва да има свой собствен уникален сол и това ще гарантира, че всеки потребителски акаунт ще имат различна хеш стойност за тяхната парола в базата данни. Дори ако няколко профила са използвали паролата "password1", те ще имат различни хешове поради различните стойности на солта. Това би победило нападателя, който се опита да преизчисли хеш за пароли. Вместо да могат да генерират хешове, които се прилагат към всеки потребителски акаунт в цялата база данни наведнъж, ще трябва да генерират уникални хешове за всеки потребителски акаунт и неговата уникална сол. Това ще отнеме много повече време за изчисление и памет.

Ето защо услугите често не се притесняват. Услуга, използваща правилните процедури за сигурност, трябва да каже, че използват солени пароли за хешове. Ако те просто казват, че паролите са "хеширани", това е по-тревожно. LinkedIn например използваха паролите си, но не ги солеха - затова беше голяма работа, когато LinkedIn загуби 6,5 милиона хеш пароли през 2012 година.

Лоши практики за пароли

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

  • Съхраняване на пароли в обикновен текст: Вместо да се притеснявате от хеширането, някои от най-лошите нарушители може просто да изхвърлят паролите в обикновен текст в база данни. Ако такава база данни е компрометирана, вашите пароли очевидно са компрометирани. Няма значение колко силни са те.
  • Hashing на паролите, без да ги осоляваме: Някои услуги могат да разбият паролите и да се откажат от тях, като изберат да не използват соли. Такива бази данни за пароли биха били много уязвими към таблиците за търсене. Атакуващият може да генерира хешове за много пароли и след това да провери дали те съществуват в базата данни - те биха могли да направят това за всеки акаунт наведнъж, ако не се използва сол.
  • Повторно използване на соли: Някои услуги могат да използват сол, но могат да използват отново една и съща сол за всяка парола за потребителски акаунт. Това е безсмислено - ако една и съща сол се използва за всеки потребител, двама потребители с една и съща парола биха имали същата хеш.
  • Използване на къси соли: Ако се използват соли от само няколко цифри, би било възможно да се генерират таблици за търсене, които включват всяка възможна сол. Например, ако една солидна цифра беше използвана като сол, атакуващият може лесно да генерира списъци с хешове, които включват всяка възможна сол.

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

Други притеснения

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

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

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

Възможно е и други лични данни да изтекат, когато бъде откраднат базата данни с пароли: Потребителски имена, имейл адреси и др. В случай на изтичане на Yahoo, бяха изтеглени и въпроси за сигурността и отговорите - които, както всички знаем, улесняват кражбата на достъпа до някого.

Помощ, какво трябва да направя?

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

Първо, не използвайте повторно пароли на няколко уебсайта. Използвайте мениджър на пароли, който генерира уникални пароли за всеки уебсайт. Ако нападателят успее да установи, че паролата ви за дадена услуга е "43 ^ tSd% 7uho2 # 3" и използвате тази парола само на този конкретен уебсайт, те не са научили нищо полезно. Ако използвате една и съща парола навсякъде, те могат да имат достъп до другите ви профили. Това е колко сметки на хората стават "опростени".

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

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

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

Image Credit: Marc Falardeau на Flickr, Wikimedia Commons