Защита конфиденциальных данных в БД, стоит ли использовать H2? - PullRequest
1 голос
/ 09 сентября 2011

В данный момент я разрабатываю веб-приложение, и одно из требований заключается в защите учетных данных пользователей и их ролей. Теперь, кроме обычного pwd хэширования + соль + .... Я думал поместить эти конкретные таблицы в зашифрованную базу данных H2, а остальные данные - в базу данных MySQL. Преимущества H2 в моем случае: хранение в памяти, что означает более быстрый доступ; зашифрованные БД, поэтому дополнительный уровень безопасности на случай взлома сервера.

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

Спасибо

Ответы [ 3 ]

1 голос
/ 19 сентября 2011

Хорошо, я получил свой ответ на форуме безопасности, для интересующихся, это ссылка https://security.stackexchange.com/questions/7062/securing-sensitive-data-in-a-db-is-using-h2-worth-it

0 голосов
/ 09 сентября 2011

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

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

0 голосов
/ 09 сентября 2011

Я не думаю, что это действительно добавляет соответствующий уровень безопасности.

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

И еще: это несколько усложняет вашу настройку, что само по себе может привести к множеству проблем с безопасностью («Почему компонент A не может прочитать этот файл? О, я просто сделаю его доступным для чтения во всем мире»).Простота может быть хороша для безопасности.

...