"Базата данни за паролите ни беше откраднато вчера. Но не се притеснявайте: паролите ви са били шифровани. "Ние редовно виждаме изявления като тази онлайн, включително вчера, от Yahoo. Но трябва ли наистина да приемем тези уверения на стойност?
Реалността е, че базата данни за пароли е компромис сте безпокойство, без значение как една компания може да се опита да я върти. Но има няколко неща, които можете да направите, за да изолирате себе си, без значение колко лоши са практиките на компанията за сигурност.
Ето как компаниите трябва да съхраняват пароли в идеален свят: Създавате акаунт и давате парола. Вместо да съхранява самата парола, услугата генерира "хеш" от паролата. Това е уникален пръстов отпечатък, който не може да бъде обърнат. Например, паролата "парола" може да се превърне в нещо, което прилича повече на "4jfh75to4sud7gh93247g ...". Когато въведете паролата си за вход, услугата генерира хеш от нея и проверява дали стойността на хеш съответства на стойността, съхранена в базата данни. В нито един момент услугата ни не запише самата парола на диска.
За да определите действителната си парола, атакуващият с достъп до базата данни трябва предварително да изчисли хешове за общи пароли и след това да провери дали те съществуват в базата данни. Атакуващите правят това с таблици за търсене - огромни списъци с хешове, които съответстват на пароли. Хешовете могат да бъдат сравнени с базата данни. Например, хакерът би разбрал хеш за "парола1" и след това да види дали някакви акаунти в базата данни използват този хеш. Ако те са, атакуващият знае, че паролата им е "password1".
За да се предотврати това, услугите трябва да "солират" своите хешове. Вместо да създават хеш от самата парола, те добавят произволен низ в предната или в края на паролата, преди да я закачат. С други думи, потребител ще въведе паролата "парола" и услугата ще добави солта и хеш парола, която прилича повече на "password35s2dg." Всеки потребителски акаунт трябва да има свой собствен уникален сол и това ще гарантира, че всеки потребителски акаунт ще имат различна хеш стойност за тяхната парола в базата данни. Дори ако няколко профила са използвали паролата "password1", те ще имат различни хешове поради различните стойности на солта. Това би победило нападателя, който се опита да преизчисли хеш за пароли. Вместо да могат да генерират хешове, които се прилагат към всеки потребителски акаунт в цялата база данни наведнъж, ще трябва да генерират уникални хешове за всеки потребителски акаунт и неговата уникална сол. Това ще отнеме много повече време за изчисление и памет.
Ето защо услугите често не се притесняват. Услуга, използваща правилните процедури за сигурност, трябва да каже, че използват солени пароли за хешове. Ако те просто казват, че паролите са "хеширани", това е по-тревожно. LinkedIn например използваха паролите си, но не ги солеха - затова беше голяма работа, когато LinkedIn загуби 6,5 милиона хеш пароли през 2012 година.
Това не е най-трудното нещо за внедряване, но много уебсайтове все още успяват да я объркат по различни начини:
Компаниите не винаги ще ви разкажат цялата история, така че дори и да казват, че паролата е била разбита (или хеширана и осолена), възможно е те да не използват най-добрите практики. Винаги грешка от страна на предпазливост.
Вероятно стойността на солта присъства и в базата данни с пароли. Това не е толкова лошо - ако се използва уникална солева стойност за всеки потребител, нападателите ще трябва да похарчат огромни количества енергия от процесора, нарушавайки всички тези пароли.
На практика толкова много хора използват очевидни пароли, че вероятно ще е лесно да се определят паролите на много потребителски профили. Например, ако хакерът знае вашата хеш и те знаят солта ви, те лесно могат да проверят дали използвате някои от най-често срещаните пароли.
Ако нападателят го е извадил за вас и иска да пропусне паролата ви, той може да го направи с груба сила, стига да е наясно със стойността на солта, която вероятно правят. С локалния, офлайн достъп до бази данни с пароли, нападателите могат да използват всички груби атаки, които искат.
Възможно е и други лични данни да изтекат, когато бъде откраднат базата данни с пароли: Потребителски имена, имейл адреси и др. В случай на изтичане на Yahoo, бяха изтеглени и въпроси за сигурността и отговорите - които, както всички знаем, улесняват кражбата на достъпа до някого.
Каквото и да каже службата, когато базата данни за пароли е откраднато, най-добре е да приемем, че всяка услуга е напълно некомпетентна и действа по съответния начин.
Първо, не използвайте повторно пароли на няколко уебсайта. Използвайте мениджър на пароли, който генерира уникални пароли за всеки уебсайт. Ако нападателят успее да установи, че паролата ви за дадена услуга е "43 ^ tSd% 7uho2 # 3" и използвате тази парола само на този конкретен уебсайт, те не са научили нищо полезно. Ако използвате една и съща парола навсякъде, те могат да имат достъп до другите ви профили. Това е колко сметки на хората стават "опростени".
Ако дадена услуга се компрометира, не забравяйте да промените паролата, която използвате там. Трябва също да промените паролата на други сайтове, ако го използвате отново там - но не трябва да правите това на първо място.
Също така трябва да обмислите използването на двуфакторен идентификатор, който ще ви защити, дори ако нападателят научи вашата парола.
Най-важното нещо не е повторното използване на пароли. Базите данни с компрометирана парола не могат да ви навредят, ако използвате уникална парола навсякъде - освен ако не съхраняват нещо друго, което е важно в базата данни, например номера на вашата кредитна карта.
Image Credit: Marc Falardeau на Flickr, Wikimedia Commons
