Решение по паролю для локальной базы данных, передаваемое между клиентом и сервером
Я работал над проектом, который использует базу данных sqlce, которая отправляется между клиентом, который должен работать в автономном режиме, и сервером, который хранит информационную базу данных, база данных защищена паролем.
Сложность в том, что у нас есть бизнес-требование, чтобы пользователям не приходилось обновляться до последней версии перед тем, как сообщать информацию в базе данных sqlce, и, возможно, даже несколько поколений отстают от последней версии клиента и возможного обновления пароль, необходимый серверу для доступа к сообщаемой информации в базе данных.
Наше текущее решение — иметь один и тот же статический пароль в исходном коде на клиенте и сервере и сохранять их одинаковыми для обратной совместимости.
Мой вопрос касается безопасного способа синхронизации пароля между клиентом и сервером и обеспечения обратной совместимости для старых баз данных или возможности получить какой-либо параметр из базы данных, чтобы узнать, какой пароль должен совпадать.
Мы используем sql ce 3.1 и C ++ на данный момент. решения той же проблемы в других технологиях (SQLight? C #? Java?) приветствуются, так как я думаю, что проблема может быть применена в других проектах.
Я надеюсь, что моя проблема ясна и что есть много ответов, если есть что-то, что мне нужно уточнить, просто спросите меня!
Решение
Вам необходимо шифрование с открытым ключом с обменом ключами. У нас есть сервер безопасности (Java-программа с интерфейсом SOAP), который поддерживает это. Существуют коммерческие продукты, которые удовлетворяют этому требованию — вам придется интегрировать их в свою систему. Пароли никогда не должны быть жестко закодированы повсюду.
Другие решения
Я предлагаю пользователям, у каждого пользователя, которые входят в SQL, есть свой пользователь в базе данных, и поэтому он может сохранить свой пароль. Вы, как код, выполняющий какие-либо действия после сеанса пользователя, можете управлять своим паролем с помощью настраиваемой строки подключения, которая хранится в файле конфигурации, и какой-то пользователь инструмента может обновить его, так что, например, администратор всегда может изменить пароль своего / ее База данных и ваш код могут работать правильно. с другой стороны, если у вас есть дизайн сервер / клиент, то сервер может использовать доверенное соединение и поддерживать свою безопасность через зарегистрированного пользователя и никогда не требовать сохранения пароля в коде.
Итак, несколько вещей.
1) Никогда не кодируйте пароли в исходном коде жестко, кто-то вроде меня их найдет
2) Сервер не должен заходить в базу данных на стороне клиента, клиент всегда должен отчитываться перед сервером.
Теперь, вооружившись этой информацией, я перестроил бы мои настройки так:
Каждый клиент отправляет ежедневную, еженедельную или любую другую метрику времени, которую вы используете для получения отчетов. Это облегчает любые проблемы, связанные с управлением паролями. Кроме того, благодаря этому сервер может вести белый список разрешенных клиентов, что предотвращает отправку сообщений неавторизованным или недействительным клиентам на главный сервер. Теперь, используя это, не имеет значения, насколько далеко отстает клиент, поскольку серверу, безусловно, все равно, и ваша структура обмена сообщениями не должна так сильно меняться. Если это произойдет, вы, вероятно, должны заставить клиентов обновить.