Реальность заключается в том, что база данных паролей компрометирует являются беспокойство, как бы компания ни пыталась его закрутить. Но есть несколько вещей, которые вы можете сделать, чтобы изолировать себя, независимо от того, насколько плохи методы безопасности компании.
Как хранить пароли
Вот как компании должны хранить пароли в идеальном мире: вы создаете учетную запись и предоставляете пароль. Вместо того, чтобы хранить сам пароль, служба генерирует «хэш» из пароля. Это уникальный отпечаток, который нельзя отменить. Например, пароль «пароль» может превратиться в нечто похожее на «4jfh75to4sud7gh93247g …». Когда вы вводите свой пароль для входа в систему, служба генерирует хеш из него и проверяет, соответствует ли хеш-значение значению, хранящемуся в базе данных. Ни в коем случае служба никогда не сохраняет ваш пароль на диск.
Чтобы предотвратить это, службы должны «солить» свои хэши. Вместо того, чтобы создавать хэш из самого пароля, они добавляют случайную строку к фронту или концу пароля перед его хэшированием. Другими словами, пользователь вводит пароль «пароль», и служба добавит соль и хэш-пароль, который больше походит на «password35s2dg». Каждая учетная запись пользователя должна иметь свою собственную уникальную соль, и это гарантирует, что каждая учетная запись пользователя будет иметь другое значение хэша для своего пароля в базе данных. Даже если несколько учетных записей использовали пароль «password1», у них были бы разные хэши из-за разных значений солей. Это победит злоумышленника, который пытался предварительно вычислить хэши для паролей. Вместо того, чтобы создавать хэши, которые применялись к каждой учетной записи пользователя во всей базе данных сразу, им приходилось создавать уникальные хэши для каждой учетной записи пользователя и ее уникальной соли. Это потребует гораздо большего времени вычисления и памяти.
Вот почему службы часто говорят, чтобы не волноваться. Служба, использующая надлежащие процедуры обеспечения безопасности, должна сказать, что они использовали хэш-листы соленых паролей. Если они просто говорят, что пароли «хэшируются», это более тревожно. Например, LinkedIn хэшировал свои пароли, но они не соляли их, поэтому было очень сложно, когда LinkedIn потеряла 6,5 миллиона хэшированных паролей в 2012 году.
Плохие пароли
- Хранение паролей в обычном тексте: Вместо того, чтобы беспокоиться о хэшировании, некоторые из самых злоумышленников могут просто сбрасывать пароли в текстовой форме в базу данных. Если такая база данных скомпрометирована, ваши пароли, очевидно, скомпрометированы. Неважно, насколько они сильны.
- Хеширование паролей без их соления: Некоторые службы могут хешировать пароли и отказаться от них, предпочитая не использовать соли. Такие базы паролей были бы очень уязвимы для поисковых таблиц. Злоумышленник может генерировать хэши для многих паролей, а затем проверять, существовали ли они в базе данных - они могли сделать это для каждой учетной записи сразу, если соль не использовалась.
- Повторное использование солей: Некоторые службы могут использовать соль, но они могут повторно использовать одну соль для каждого пароля учетной записи пользователя. Это бессмысленно - если одна и та же соль использовалась для каждого пользователя, два пользователя с одним и тем же паролем имели бы такой же хеш.
- Использование коротких солей: Если используются соли всего нескольких цифр, можно было бы генерировать таблицы поиска, которые включали бы все возможные соли. Например, если одна цифра использовалась в качестве соли, злоумышленник мог бы легко создавать списки хешей, которые включали всю возможную соль.
Компании не всегда расскажут вам всю историю, поэтому, даже если они скажут, что пароль был хэширован (или хеширован и солен), они могут не использовать лучшие практики. Всегда ошибайтесь с осторожностью.
Другие проблемы
Вероятно, значение соли также присутствует в базе паролей. Это не так уж плохо - если для каждого пользователя использовалось уникальное значение соли, злоумышленникам пришлось бы тратить огромные суммы мощности процессора, нарушающие все эти пароли.
На практике многие люди используют очевидные пароли, что, вероятно, будет легко определить многие пароли учетных записей пользователей. Например, если злоумышленник знает ваш хэш, и они знают вашу соль, они могут легко проверить, используете ли вы некоторые из наиболее распространенных паролей.
Если у злоумышленника это для вас и вы хотите взломать свой пароль, они могут сделать это с грубой силой, если они знают ценность соли, что они, вероятно, делают.Благодаря локальному, автономному доступу к базам данных паролей, злоумышленники могут использовать все атаки грубой силы, которые они хотят.
Другие личные данные также могут протекать при краже базы данных паролей: имена пользователей, адреса электронной почты и т. Д. В случае утечки Yahoo были также пропущены вопросы безопасности и ответы, которые, как мы все знаем, упрощают кражу доступа к чьей-то учетной записи.
Помощь, что я должен делать?
Независимо от того, что говорит служба, когда украдена его база данных паролей, лучше предположить, что каждая услуга полностью некомпетентна и действует соответствующим образом.
Во-первых, не используйте повторно пароли на нескольких веб-сайтах. Используйте менеджер паролей, который генерирует уникальные пароли для каждого веб-сайта. Если злоумышленнику удается обнаружить, что ваш пароль для службы «43 ^ tSd% 7uho2 # 3», и вы используете этот пароль только на этом конкретном веб-сайте, они ничего не узнали. Если вы используете один и тот же пароль повсюду, они могут получить доступ к вашим другим учетным записям. Это то, как многие люди становятся «взломанными».
Вы также должны рассмотреть возможность использования двухфакторной аутентификации, которая защитит вас, даже если злоумышленник узнает ваш пароль.
Самое главное не повторять использование паролей. Исправленные базы паролей не могут повредить вам, если вы используете уникальный пароль везде - если они не хранят в базе данных что-то еще важное, например номер вашей кредитной карты.
