Надежно хранить пользовательские данные в MySQL? - PullRequest
2 голосов
/ 26 июля 2010

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

Но возникает две проблемы - # 1 - гораздо медленнееПри поиске в БД и # 2 ключ шифрования будет по-прежнему сохраняться в сценарии Perl, который будет шифровать данные, предоставленные пользователем, поэтому, если кто-то получит доступ ко всему серверу, он все равно сможет расшифровать все данные.

Итак, мне было интересно, что используют такие службы, как Twitter, Facebook, Hotmail и т. Д. Для безопасного хранения данных?

Кстати: как я уже говорил, я работаю с Perl / MySQL.

Спасибо всем приятным людям!

Ответы [ 4 ]

1 голос
/ 26 июля 2010

Вам следует избегать шифрования всего в базе данных. По крайней мере, вам придется выяснить, какие поля используются для поиска, отношений, сортировки и т. Д., И оставить их незашифрованными. Вы должны учитывать уровни шифрования в зависимости от того, от кого вы скрываете данные. Также будет полезно, если вы четко понимаете разницу между односторонним хешированием (MD5, SHA), симметричным шифрованием и асимметричным шифрованием.

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

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

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

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

При шифровании всей файловой системы главное не беспокоиться о снижении производительности. Насколько я видел, это требует, чтобы человек вводил правильный пароль при загрузке ОС, а для этого требуется физический доступ, и люди, которым можно доверять, знают пароль, находящийся настолько близко к серверам, насколько этого требует SLA. В этом все равно что установить пароль bios или пароль grub. Если вы действительно зашифруете свою файловую систему, обязательно проверьте это или найдите способ обойти это.

1 голос
/ 26 июля 2010

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

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

К счастью, пароли легко защитить.Используйте односторонний хеш, такой как SHA1, с солью (для защиты от таблиц rainbox) и никогда не сохраняйте действительный пароль в вашей БД.Храните соленый хэш.Затем, когда пользователь входит в систему, вы можете проверить значение pw, которое они вам дают, по отношению к хэшированному, чтобы убедиться, что оно совпадает без необходимости хранить то, что в действительности представляет их pw.

0 голосов
/ 26 июля 2010

У вас есть несколько вариантов:

  1. Вы можете зашифровать данные на среднем уровне
    • Вы можете зашифровать базу данных

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

0 голосов
/ 26 июля 2010

Смотрите мой ответ здесь .Суть в том, что вы можете повысить безопасность, но нет 100% надежного способа избежать компрометации (частично) информации о вашем пользователе, если ваше веб-приложение полностью сломано.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...