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

78

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

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

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

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

phpmysqlguy
источник
124
Я бы пошел еще дальше. Недостаточно зашифровать его. Вы хотели бы хешировать это. Таким образом, даже вы не сможете узнать, какие пароли у ваших пользователей открыты.
Санта
67
@Santa Хэширования пароля недостаточно. Вы должны добавить немного соли, чтобы рецепт был достаточно хорош ...
Бакуриу
16
Пожалуйста, ознакомьтесь с этой соответствующей публикацией Security.StackExchange: Как безопасно хешировать пароли?
Ади
10
Расстроенный администратор базы данных говорит ... выберите * у пользователя, а затем продает этот список за выходное пособие. Ничто не всегда безопасно.
Джон Рейнор
также security.blogoverflow.com/2011/11/…
David J. Liszewski

Ответы:

194

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

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

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

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

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

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

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

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

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

прецизионный самописец
источник
89
Или лучше, хэш это!
Blorgbeard
29
Этот. «У меня другие проблемы, если кто-то попадает в мою базу данных». Это ваша база данных, вы ожидаете проблем, если ее взломают. Но, сохраняя незашифрованные пароли, вы доставляете всем своим пользователям проблемы, возможно, со всеми другими их учетными записями. Как вы думаете, сколько людей используют разные пароли на каждом сайте?
Carson63000
13
Пожалуйста, следуйте советам Blorgbeard, возможно, прочитайте это . Шифрование паролей не обеспечивает защиту, когда ваш веб-сервер был взломан. Ключ для расшифровки паролей должен храниться где-то на сервере. Хэширование паролей означает, что даже в случае, если кто-то имеет полный доступ к машине, он не может легко восстановить пароли.
нарезанный
7
Зачем вам когда-либо шифровать пароли, если они не представляют никакой ценности для вашей системы? В какой момент времени вам придется расшифровывать пароли, кроме как для сравнения? @pdr, вы не должны говорить оператору о шифровании, вы должны сказать ему, чтобы он солил и хэшировал.
NobleUplift
4
Вы также хотите хешировать ответы на свои вопросы восстановления пароля. В противном случае они могут быть использованы для проникновения на другие сайты, как пароли.
Zan Lynx
64

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

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

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

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

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

david25272
источник
13
+1 за упоминание недовольных сотрудников. Легко не заметить, когда вы работаете в одиночном магазине или в небольшой компании, но в конечном итоге у вас будут люди, работающие с данными, которые вы лично не проверяли.
2
Написание foreach для циклического просмотра списка пользователей, а затем хеширования их паролей - это работа нескольких минут, и, честно говоря, 4000 - это почти ничего. php.net/manual/en/function.hash.php
Элин
3
Вы продолжаете переключаться между терминами «шифровать» с «хешем и солью» @ david25272. Не путайте два, которые совершенно разные. Теперь OP ищет алгоритм шифрования, а не алгоритм хеширования. Кроме того, это «соль и хеш», а не «хэш и соль». Вы не можете солить после того, как вы хэш.
NobleUplift
1
Также @phpmysqlguy, прочитайте мой ответ для предложений по солению и хеш- алгоритмам.
NobleUplift
36

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

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

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

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

Шон Максомт
источник
9
Вы делаете то, что я считаю самым важным: ВЫ и ваши работники не должны иметь доступа к паролю пользователя. Кто заботится о хакере, так это люди, владеющие данными, которые касаются пользователей.
Адам Дэвис
1
+1 за то, что как разработчик / администратор у вас не должно быть доступа к паролям ваших пользователей. Это само по себе является достаточной причиной.
Мэтт
21

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

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

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

Карл Билефельдт
источник
18

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

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

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

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

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

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

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

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

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

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

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

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

NobleUplift
источник
+1 за хеш плюс соль. Крекинг хэши без солей ооочень легко.
Код Maverick
3
Вы знаете, что находится на другой стороне радужного стола @CodeMaverick? Горшок с золотом.
NobleUplift
В контексте хеширования паролей MD5 не имеет известных уязвимостей, кроме быстрых, и это относится и к SHA-2. Использование медленной итерированной конструкции гораздо важнее, чем выбор SHA-2 вместо MD5.
CodesInChaos
4
«Прочитайте всю эту страницу, прежде чем хешировать свои пароли» - на этой странице упоминается, что вам не следует использовать циклы хэширования, а метод хэширования, который был специально разработан так медленно, как необходимо, такой как PBKDF2.
jhominal
2
Используйте SCrypt или PBKDF2, оба из которых предназначены для очень дорогой работы с точки зрения памяти или процессора. Используйте случайно сгенерированную соль, которую вы храните в записи пользователя. Не выполняйте несколько раундов хэширования, это только приводит к проблемам коллизий.
Tom.dietrich
14

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

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

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

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

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

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

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

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

  1. Знание хеша напрямую не обеспечивает аутентификацию.
  2. Обратный расчет пароля из хеша нецелесообразен.
  3. Использование радужных таблиц (длинных списков паролей и их вычисленных хешей) становится более сложным, поскольку полученный хеш зависит как от имени пользователя, так и от пароля.
Майкл Шоу
источник
6
Как правило, вместо имени пользователя рекомендуется использовать случайную соль.
CodesInChaos
Вау, отличный улов @CodesInChaos. Я не заметил этого при первом прочтении вопроса. Да, ваша соль должна генерироваться случайным образом. Это не должен быть какой-то сумасшедший блоб, хранящийся в MySQL (и это было бы плохо, потому что тогда он не был бы переносимым). В противном случае +1 за слова о том, что только пользователь должен знать пароль пользователя.
NobleUplift
Хорошо, обновленный ответ, чтобы предложить, что у приложения есть свое собственное случайное значение соли.
Майкл Шоу
4
Нет, приложение не имеет к стоимости соли либо. Для каждого сохраненного хэша должно быть другое строго строго случайное значение соли. (Вы храните соль рядом с этим хешем.) Это то, что защищает от статистических атак. Если вы использовали один и тот же хеш для всего приложения, то одни и те же хэши открытого текста с тем же значением. Это гораздо хуже, чем использовать имя пользователя в качестве хэша.
Бен Фойгт
Это не веб-сервис, но аутентификация SSH по ключевой паре действительно использует «чистое» решение, где сервер хранит открытый ключ, а пользователь аутентифицируется с помощью закрытого ключа.
cpast
10

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

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

Томас Порнин
источник
+1 за знание разницы между шифрованием и хэшированием.
NobleUplift
8

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

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

Элин
источник
2
К сожалению, я использую PHP 5.3.3, поэтому ваши предложения не будут применяться
phpmysqlguy
4
с 5.3.3 до 5.3.8 большая часть обновления?
gbjbaanb
Есть ли шанс, что вы в Red Hat? Потому что они перенесли исправление в bcrypt. Если нет, то используйте SHA256 вместо brcypt.
Элин
1
Шифрование и хеширование - это разные вещи. Хеш пароли, не шифруйте их. Вам никогда не нужно знать их. Вам нужен только пользователь, чтобы иметь возможность использовать пароль, чтобы доказать, кто он / она. Хеширование (с солью) позволяет это. Шифрование, особенно симметричное шифрование неверно, так как позволяет восстанавливать пароли.
Поль де Вриз
Одна вещь, которую я добавлю, состоит в том, что хорошо в функции password_hash () в php 5.5+ является то, что она по умолчанию обрабатывает соление и так далее. Раньше вам нужно было пойти дальше и использовать что-то вроде библиотеки ircmaxell, которая поддерживает его (он написал реализацию 5.5). Не думайте, что вы можете создать случайную соль самостоятельно. Это очень тяжело и лучше оставить специалистам; действительно легко получить случайные, но не единообразные результаты, которые можно использовать.
Элин
7

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

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

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

AngCaruso
источник
+1 за упоминание как соления, так и хеширования, а также не упоминания о шифровании, которое даже не относится к этому вопросу.
NobleUplift
2

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

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

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

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


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

DVK
источник
2

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

Ролен Ко
источник
1
это не добавляет ничего достойного того, что уже было опубликовано в предыдущих ответах
комнат
3
+1. Он фактически сказал «хеширование», а не шифрование, как многие другие. Кроме того, он прямо противоречил ОП, который сказал, что хочет, чтобы открытый текст паролей входил в учетные записи других пользователей.
NobleUplift
0

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

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

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

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

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

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

Уэсли Лонг
источник
-1

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

piet.t
источник
1
На самом деле, если OP продвинулся еще на один шаг и зашифровал в JavaScript, то хеш будет отправлен по проводам и никогда не будет отображаться в запросе.
NobleUplift
1
В этом случае злоумышленнику также нужно будет отправить хеш через провод. Хэш будет функционировать как сложный, но незашифрованный пароль, не так ли? (Правка: нет, если его нужно было каждый раз солить другой солью, а соль поступала с сервера. Я думаю)
RemcoGerlich
1
@RemcoGerlich Ключевая концепция известна как одноразовый номер, который используется, чтобы избежать повторной атаки .
-1

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

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

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

Alpha1983
источник
2
Кто хранит пароли с использованием асимметричного шифрования? Это криптография с открытым ключом, которая означает, что даже после того, как я зашифрую свой пароль, ее можно расшифровать и прочитать, если кто-нибудь когда-нибудь получит мой закрытый ключ. С хэшированием я и только я знаю свой пароль (если я не запишу его или не положу в диспетчер паролей, где фактически используется асимметричное шифрование).
NobleUplift
Пожалуйста, проверьте страницу википедии на предмет криптографии с открытым ключом: en.wikipedia.org/wiki/Public-key_cryptography «Криптография с открытым ключом, также известная как асимметричная криптография»
Alpha1983
2
... да, я сказал это using asymmetric encryption? That's public-key cryptography. Какова ваша позиция?
NobleUplift
-1

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

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

lobati
источник
1
кажется, это не дает ничего существенного за 14 предыдущих ответов
комнат
Я не согласен, иначе я бы не опубликовал это. Я не уверен, что вижу, как ваши высказывания с негативными комментариями дополняют беседу, кроме того, что не поощряют людей к участию.
Лобати
ну, не знаю, читали ли вы другие ответы до того, как опубликовать свои, но в моем чтении все пункты здесь уже были сделаны (и в соответствии с моим чтением лучше представлены) в другом месте. Например, пункт об ошибке в вопросе был сделан более 2 месяцев назад в этом и в этом ответе. Пункт о хешировании паролей был сделан как минимум в 7 других ответах. Пункт о создании резервных копий и учете возможных проблем в других частях системы был также сделан давно. Etc и т.д.
комар
Связанная с ошибкой точка отличалась от моей. Они утверждали разницу в значении между хешированием и шифрованием, тогда как я говорил, что ошибочно думать, что базу данных можно считать «безопасной». Я до сих пор не вижу других ответов, обсуждающих другие части программного обеспечения и их взаимодействие, небезопасных, и я не делал никаких замечаний по поводу резервного копирования.
Лобати
«Предположим , вы будете взломан» - вот как это было написано в ответ разместил более 2 месяцев назад
комара