Почему вы должны беспокоиться, когда база данных паролей службы утечка

«Наша база паролей была украдена вчера. Но не волнуйтесь: ваши пароли были зашифрованы ». Мы регулярно видим подобные заявления в Интернете, в том числе вчера, от Yahoo. Но должны ли мы действительно принять эти гарантии за чистую монету??

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

Как хранить пароли

Вот как компании должны хранить пароли в идеальном мире: вы создаете учетную запись и предоставляете пароль. Вместо хранения самого пароля служба генерирует «хеш» из пароля. Это уникальный отпечаток пальца, который нельзя отменить. Например, пароль «пароль» может превратиться в нечто, похожее на «4jfh75to4sud7gh93247g…». Когда вы вводите свой пароль для входа, служба генерирует из него хеш и проверяет, соответствует ли значение хеша значению, хранящемуся в базе данных. Ни при каких условиях служба сама не сохраняет свой пароль на диск.

Чтобы определить ваш действительный пароль, злоумышленник, имеющий доступ к базе данных, должен предварительно вычислить хеши для общих паролей, а затем проверить, существуют ли они в базе данных. Злоумышленники делают это с помощью таблиц поиска - огромных списков хэшей, соответствующих паролям. Затем хэши можно сравнить с базой данных. Например, злоумышленник узнает хэш для «password1», а затем увидит, используют ли какие-либо учетные записи в базе данных этот хэш. Если это так, злоумышленник знает, что его пароль - «password1».

Чтобы предотвратить это, сервисы должны «засолить» свои хеши. Вместо того, чтобы создавать хеш из самого пароля, они добавляют случайную строку в начало или конец пароля перед его хэшированием. Другими словами, пользователь вводит пароль «пароль», а служба добавляет соль и хэш-пароль, который больше похож на «password35s2dg». У каждой учетной записи пользователя должна быть своя уникальная соль, и это гарантирует, что каждая учетная запись пользователя будет иметь другое значение хеша для их пароля в базе данных. Даже если бы несколько учетных записей использовали пароль «password1», они имели бы разные хэши из-за разных значений соли. Это победит злоумышленника, который попытался предварительно вычислить хэши для паролей. Вместо того, чтобы создавать хэши, которые применяются сразу к каждой учетной записи пользователя во всей базе данных, им придется генерировать уникальные хеши для каждой учетной записи пользователя и ее уникальной соли. Это займет гораздо больше времени вычислений и памяти.

Вот почему службы часто говорят не беспокоиться. Служба, использующая надлежащие процедуры безопасности, должна сказать, что она использует хэши с солеными паролями. Если они просто говорят, что пароли «хэшированы», это больше беспокоит. Например, LinkedIn хэшировал свои пароли, но они их не засолили, поэтому было очень важно, когда LinkedIn потерял 6,5 млн хешированных паролей в 2012 году..

Неправильные пароли

Это не самая сложная вещь для реализации, но многим веб-сайтам все еще удается испортить это различными способами:

Хранение паролей в простом текстеВместо того, чтобы беспокоиться о хешировании, некоторые из худших нарушителей могут просто сбросить пароли в виде простого текста в базу данных. Если такая база данных скомпрометирована, ваши пароли, очевидно, скомпрометированы. Не важно, насколько они сильны.
Хеширование паролей без их посолаНекоторые сервисы могут хэшировать пароли и отказываться от них, предпочитая не использовать соли. Такие базы паролей будут очень уязвимы для таблиц поиска. Злоумышленник может сгенерировать хэши для многих паролей, а затем проверить, существуют ли они в базе данных - он может сделать это сразу для каждой учетной записи, если соль не использовалась.
Повторное использование солей: Некоторые службы могут использовать соль, но они могут использовать одну и ту же соль для каждого пароля учетной записи пользователя. Это бессмысленно - если бы для каждого пользователя использовалась одна и та же соль, два пользователя с одинаковым паролем имели бы одинаковый хеш.
Используя Короткие Соли: Если используются соли только из нескольких цифр, было бы возможно создать таблицы поиска, которые включали бы каждую возможную соль. Например, если в качестве соли использовалась одна цифра, злоумышленник мог легко создать списки хэшей, которые включали все возможные соли.

Компании не всегда будут рассказывать вам всю историю, поэтому даже если они скажут, что пароль был хеширован (или хеширован и засолен), они, возможно, не будут использовать лучшие практики. Всегда ошибаться на стороне предостережения.

Другие проблемы

Вполне вероятно, что значение соли также присутствует в базе данных паролей. Это не так уж и плохо - если бы для каждого пользователя использовалось уникальное солт-значение, злоумышленникам пришлось бы потратить огромное количество ресурсов процессора, взломав все эти пароли..

На практике так много людей используют очевидные пароли, что было бы легко определить пароли многих учетных записей пользователей. Например, если злоумышленник знает ваш хеш, а он знает вашу соль, он может легко проверить, используете ли вы самые распространенные пароли..

Если у злоумышленника есть это для вас и он хочет взломать ваш пароль, он может сделать это с грубой силой, пока он знает солидную ценность - что, вероятно, он и делает. Благодаря локальному автономному доступу к базам паролей злоумышленники могут использовать любые атаки методом перебора.

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

Помогите, что мне делать?

Что бы ни говорил сервис, когда его база данных паролей украдена, лучше предположить, что каждый сервис полностью некомпетентен, и действовать соответственно.

Во-первых, не используйте пароли на разных сайтах. Используйте менеджер паролей, который генерирует уникальные пароли для каждого сайта. Если злоумышленнику удается обнаружить, что ваш пароль для службы «43 ^ tSd% 7uho2 # 3», и вы используете этот пароль только на этом конкретном веб-сайте, он не узнает ничего полезного. Если вы используете один и тот же пароль везде, они могут получить доступ к другим вашим учетным записям. Это то, сколько учетных записей людей становится «взломанным».

Если служба действительно скомпрометирована, обязательно смените пароль, который вы там используете. Вам также следует сменить пароль на других сайтах, если вы будете использовать его там снова - но вы не должны делать это в первую очередь.

Вам также следует рассмотреть возможность использования двухфакторной аутентификации, которая защитит вас, даже если злоумышленник узнает ваш пароль.

Самое главное не повторное использование паролей. Скомпрометированные базы паролей не повредят вам, если вы везде будете использовать уникальный пароль - если только они не хранят в базе данных что-то еще важное, например номер вашей кредитной карты.

Изображение предоставлено: Марк Фалардо на Flickr, Wikimedia Commons