Начал разработку backend'а веб приложения с использованием nodeJS + express.js + MongoDB.
Необходимо хранить безопасно часть данных пользователей, с так называемой "двойной" защитой.
Есть идея создать 2 докера, на одном будет крутится основное приложение, а на втором поместить базу данных с информацией. Второй докер не имеет доступ к внешней сети. Подтягивание информации из 2го докера в 1й осуществляется с применением защищенной коммуникации ( как ее осуществить, пока не придумал, может быть есть идеи?). Насколько такой подход безопасен, какие подходы применяете вы?
UPD: защититься полноценно способа не нашел, через docker'ы идея не дает нужной безопасности, решил использовать мастер ключ, у каждого пользователя он свой, данные каждого пользователя будут зашифрованы, ключ у каждого будет свой и храниться в системе не будет.
sim3x, шифрование подразумевается, однако данные пароли будут необходимы API для доступа к сервисам от которых данные пароли были получены. Страх в том, что пользователи доверят свои пароли, а после взлома сервера, у меня смогут увести все пароли, пытаюсь придумать, есть ли возможный способ защититься
Обновил коммент. Любой популярный алгоритм криптографического хеширования, как например md5 или sha (md5 устарел, sha - их много, есть устаревшие, лучше всего bcrypt), позволит не хранить пароли в исходном виде. Угонщик базы может подобрать хеш, либо остаться с носом. Кому надо, подберёт, и быстро, но как защита от дурака, сгодится. Для обучения и понимания азов тоже сгодится.
Подтягивание информации из 2го докера в 1й осуществляется с применением защищенной коммуникации
Филипп Сорокин, да, но если я разотру по sha, то как мой сервис потом сможет воспользоваться этим паролем (это будет предусматриваться соглашением с пользователем)
sim3x, серьёзно, как защита от дурака. Конечно, этого недостаточно. Обновил. Про sha-1 это Вы сами написали, я писал обо всех sha. Сейчас загуглил sha-256 и sha-512, и о них пишут, как о довольно безопасных.
sim3x, грамотный специалист безусловно выход, но проект делаю с 0, финансирования нет никакого, поэтому пока пытаюсь разобраться самостоятельно. Может есть хорошая литература, которую вы могли бы посоветовать?
sim3x, ок, спасибо за совет, учту. И с интересом послежу, какие предложения или ответы последуют по сабжу дальше. Для средненького проекта свой безопасник может быть слишком круто. Обновил. И Вы старайтесь не искажать слова людей, даже в мелочах.
bal_square, т.е. "где-то там" есть некий сервис "Рога-и-Копыта", и пользователь доверяет вам свой пароль от Рогов-и-Копыт.
Вижу два возможных случая:
(1) ваш сервис получает доступ к Рогам-и-Копытам под чутким руководством пользователя, а пароль хранится просто для удобства. Тогда всё просто: пароль от Рогов-и-Копыт вы шифруете паролем пользователя на вашем сервисе. При подключении пользователя к вам он вводит свой пароль (передаётся по защищенному каналу), вы проверяете пароль по хешу, и паролем (не хешем) расшифровываете пароль от Рогов-и-Копыт. Пользователь разлогинился от вас, вы разлогинились от Рогов-и-Копыт. Вплоть до следующего подключения пользователя пароль не может быть скомпрометирован.
(2) ваш сервис ломится на Рога-и-Копыта в фоне или по расписанию, независимо от статуса пользователя (залогинен или нет). Тогда всё сложно. Вы действительно вынуждены хранить пароль в открытом виде. В этом случае вам потребуется многоуровневая защита, сложная и дорогая. Для вас цель защиты будет - изолировать вашу систему от любого несанкционированного доступа. При этом (строго обязательно!) и для вас будет существенно усложнен доступ к вашей собственной системе (как пример, первое что приходит в голову - 2-факторная аутентификация для возможности администрирования).
Sanes, Я не переживаю о хранении паролей.
Просто пароль это такая штука решение о хранении которой принимает только его владелец, а не левые лица.
Поэтому сервису хранить пароль пользователя не должен.
Sanes, вовсе нет, если в БД хранятся не пароли а их криптографические хеши, вы пароли сами не восстановите, и кроме этого получить контроль, не зная реальный пароль пользователя, не получится
АртемЪ, обратите внимание на то, что сверяя в приложении хеши пароля вместо самого пароля, вы избавляетесь от головной боли по краже базы данных и компрометации паролей пользователей.
АртемЪ, бывает ситуация, когда необходима история паролей для исключения повторяющихся или похожих паролей(напр., применяется в ldap). Или вы это относите к ситуации с пользователем?
Роман Мирр, да, историю хешами можно. А вот на предмет схожести пароль уже не проверишь. Поэтому в таких случаях пароли хранятся с использованием обратимого шифрования.
АртемЪ, довольно популярное требование безопасности для того, чтобы пользователь свой пароль "password123" не сменил по требованию на пароль "Password123" и успокоился :)
Вообще говоря, следует хранить не пароли пользователей, а их криптографический хеш пароля, по одному из нескомпрометированных криптографических протоколов, например SHA-256, SHA-512 (теоретическм скомпромитированы).
Как я понял из первой ссылки, основная проблема была в доступе извне, я подразумеваю, что docker не имеет доступа во внешнюю сеть, однако возможность попасть в докер с самим приложением, а потом достучаться ко 2му докеру, т.к. предполагаются, что они будут взаимодействовать, я вот думаю можно ли сделать проверку при доступе ко 2му контейнеру или этот подход изначально обречен?
Роман Мирр, а вы пробовали хранить криптографические хеши паролей а не сами пароли в БД. тогда сами по себе пароли пользователей остались бы нескомпрометированными, однако из-за тотального преобладания тотальной безграмотности разработчиков БД и программиств в области криптографии, в мире почти все базы данных хранят пароли в открытом виде, в том числе и на публичных ресурсах (трекерах, форумах)
