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

У меня есть веб-сервис. Прямо сейчас у меня на сервере хранятся пароли в виде простого текста в таблице MySQL . Я знаю, что это не лучшая практика, и именно поэтому я работаю над этим.

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

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

Если пароли были зашифрованы, вы можете просто восстановить предыдущую базу данных. Это правильное мышление?

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

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

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

И кто знает что еще? Что если они используют один и тот же пароль в Google? Или PayPal? Что если это даст хакеру доступ к девичьей фамилии их матери или последним 4 цифрам их кредитной карты?

Что если это попадет на другие аккаунты? Не пытайтесь пройти через систему поддержки пользователей и получить больше информации .

Просто ... просто нет. Это личная информация вашего пользователя, и вам не нужно ее видеть. Это также ваша репутация. Зашифруй это.

РЕДАКТИРОВАТЬ: один дополнительный комментарий, чтобы спасти любого будущего читателя от прочтения каждого ответа и комментария ...

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

Более простое и столь же эффективное решение состоит в том, чтобы случайно посолить и хэшировать пароль. Одного хеширования недостаточно; если ваш пользователь использует общий пароль, он появится в таблицах обратного хеширования, которые легко доступны при простом поиске в Интернете.

Если вас взломали, вы можете восстановить сайт из резервных копий и исправить его. Но у хакера все еще есть пароли для всех учетных записей! Существуют задокументированные реальные примеры этого (Sony, Linked-in), где, если бы таблицы паролей были должным образом хешированы и посолены, быстро и быстро было бы намного проще защитить и восстановить службу.

Это , вероятно, хорошая идея , чтобы предположить , вы будете быть взломан, а также разработать стратегию резервного копирования и шифрования конфиденциальных данных с помощью этого предположения в виду. И защищать нужно не только хакеров. Недовольные, нечестные или просто невежественные сотрудники могли выдавать пароли в виде простого текста.

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

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

Кроме того, как сказала Элин, не пытайтесь свернуть свое собственное хеширование (или шифрование). Используйте стандартную библиотеку.

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

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

Видите, даже если люди должны использовать разные пароли в разных системах, реальность такова, что нет .

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

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

Кроме того, не все компромиссы дают вам полный доступ к оболочке. Что если уязвимость, использованная злоумышленником, является просто инъекцией SQL в usersтаблицу только для чтения ? Оставление паролей незаметным просто дало ему полный доступ.

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

Я должен опубликовать здесь ответ на ошибку в самом вопросе. Вы спрашиваете, должны ли пароли быть зашифрованы. Никто не шифрует пароли; никто, за исключением сервисов и программ, таких как Firefox Sync и Roboform, единственной целью которых является шифрование паролей.

Давайте посмотрим на определения:

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

И хеширование:

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

Другими словами, шифрование - это двустороннее преобразование, а хеширование - это одностороннее преобразование, поэтому, если вы не расшифруете, чтобы просмотреть их позже, это не шифрование.

Кроме того, не просто хэш, соль ! Прочитайте всю эту страницу, прежде чем хешировать свои пароли.

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

И обязательно используйте раунды хеширования . Не хэшируйте один раз, хешируйте несколько раз.

Подумайте о прочтении этой страницы, чтобы обезопасить свой процесс входа

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

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

Здесь поставлен важный принцип. Есть только один человек, который имеет какое-либо дело, зная пароль пользователя. Это пользователь. Не их жена / муж, их доктор или даже их священник.

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

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

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

Более распространенным решением будет:

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

Исходная строка затем перезаписывается в памяти, и с этого момента соленый хеш сохраняется в базе данных или сравнивается с записью базы данных.

Ключевые аспекты, которые обеспечивают безопасность здесь:

1. Знание хеша напрямую не обеспечивает аутентификацию.
2. Обратный расчет пароля из хеша нецелесообразен.
3. Использование радужных таблиц (длинных списков паролей и их вычисленных хешей) становится более сложным, поскольку полученный хеш зависит как от имени пользователя, так и от пароля.

Вам необходимо «зашифровать» (на самом деле, «хеш», для правильного представления о хешировании) пароли в качестве второго уровня защиты : это предназначено для предотвращения эскалации злоумышленника, который получил представление о базе данных только для чтения, это в доступ для чтения-записи и, точно, начинают изменять данные. Частичные нарушения, доступные только для чтения, происходят в реальном мире, например, в результате некоторой атаки с использованием SQL-инъекции со стороны учетной записи, имеющей доступ только для чтения, или путем извлечения сброшенного жесткого диска или старой резервной ленты из корзины. Я написал подробно на эту тему там .

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

Я не буду повторять то, что говорили другие люди, но при условии, что у вас PHP 5.3.8 или выше, вам следует использовать нативный PHP bcryptдля хранения ваших паролей. Это встроено в PHP. Если у вас PHP 5.5, вы можете использовать лучшую доступную константу пароля. Вы также можете использовать библиотеку, чтобы 5.3.8 или лучше вели себя как 5.5.

Вопрос переполнения стека Как вы используете bcrypt для хеширования паролей в PHP? объясняет это, и другие ответы там объясняют больше. Пожалуйста, не пытайтесь делать это самостоятельно.

Я согласен с ответом от pdr по причинам, указанным в этом ответе.

Я хотел бы добавить следующее: вы должны сделать это, потому что это легко сделать и общепринятым в качестве наилучшей практики для любого приложения. Точнее, пароли всегда должны быть засолены и хэшированы перед записью в любое постоянное хранилище. Вот хорошая ссылка на важность засолки и выбора хорошего криптографического хэша (который также предоставляет бесплатный исходный код на нескольких популярных языках): https://crackstation.net/hashing-security.htm

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

Сценарий, который я могу придумать, состоит в том, что вы взломаны

Еще один сценарий, о котором вам нужно подумать: кто-то подсунул вашему администратору базы данных (или тому, кто еще может выполнить запросы на выборку в вашей базе данных) $ 100, чтобы дать им пароли пользователей. Или социальные инженеры, стажеры, чтобы сделать это.

Затем они используют эти пароли для входа в Gmail пользователя ... или на коммерческий сайт ... (потому что люди ... менее умны, скажем так - и используют один и тот же пароль на всех сайтах).

Затем гневный пользователь подает в суд на вашу компанию за раскрытие своего пароля.

НИКТО (включая сотрудников вашей компании) не должен читать простой текстовый пароль. Когда-либо. Для этого нет законной деловой или технической необходимости.

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

Что ж, удивительно, что никто еще не упомянул об этом, но как насчет ФИЗИЧЕСКОЙ безопасности вашей базы данных?

Возможно, у вас настроена лучшая в мире ИТ-безопасность, но это не мешает любому, кто может получить физический доступ к вашим носителям. Что произойдет, когда ваша команда выиграет Суперкубок сегодня днем, и в центре города, где находится ваш офис / хостинг-провайдер, вспыхнет небольшой бунт? (Учитывая, что это Сиэтл против Денвера, двух крупных областей ИТ в США, я не думаю, что это неразумно). Толпа врывается в ваше здание, и хотя власти перегружены, кто-то захватывает часть вашего оборудования с базой данных, содержащей пароли в виде открытого текста?

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

Что происходит, когда ваш ИТ-отдел забывает стереть старые диски RAID, которые содержали вашу БД, когда они выполняют запланированные замены, прежде чем «раздавать» старые диски стажерам, а затем их соседи по общежитию находят то, что осталось, и выясняют, могут ли они » продать "это и никогда не прослеживается до них?

Что происходит, когда ваш сервер БД перегружает материнскую плату, ИТ-специалисты восстанавливают образ на ваш новый сервер, и «каркас» старого сервера попадает в кучу утилизации? Эти диски все еще хороши, и эти данные все еще там.

Любой порядочный архитектор знает, что безопасность не является чем-то, что вы позже «используете» с помощью брандмауэров и политик операций. Безопасность должна быть фундаментальной частью проекта с самого начала, и это означает, что пароли хэшируются в одном направлении, НИКОГДА не передаются без шифрования (даже внутри ваших собственных центров обработки данных) и никогда не восстанавливаются. Все, что можно извлечь, может быть взломано.

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

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

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

Вот почему пароли хранятся с использованием асимметричных протоколов шифрования, чтобы вы могли проверять их, не считывая их.

Я думаю, что есть фундаментальный недостаток в этом вопросе. Дело в том, что нет такой вещи, как «безопасная база данных». Следует принять как данность, что где-то в вашей системе есть недостатки, которые могут позволить злоумышленникам получить доступ к произвольным данным на ваших серверах. Heartbleed - отличный тому пример, будучи подвигом, который был в дикой природе более двух лет, прежде чем его заметили исследователи. Возможно, вы сделали все, что знаете, как сделать, чтобы защитить данные, но вы не можете учитывать все другие части программного обеспечения, которые вы используете на своих серверах, и сложные способы их взаимодействия.

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