Как защитить учетные данные базы данных для клиент-серверного приложения на базе сервера-сервера

Question

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

Я делаю последний год проекта УДАЛЕННОЙ СИСТЕМЫ ГОЛОСОВАНИЯ. Разработка клиентского приложения с использованием java , которое позволяет публичным пользователям входить в приложение с использованием LOGINID & LOGINPASS (предоставляется каждому избирателю избирательной комиссией или около того) , Клиентское приложение затем отображает список кандидатов, участвующих в выборах, и имеет переключатели для выбора одного из них. После выбора пользователь может затем нажать кнопку «CAST VOTE», чтобы «отдать голос».

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

Я не могу действительно использовать файлы PROPERTIES или файл CONFIG и защищать их с помощью функций ОС, поскольку они также могут быть прочитаны конечными пользователями (так как они являются администратором / владельцем ОС)

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

Есть ли альтернатива для этого? Любое решение? Если есть, не могли бы вы предоставить подробную информацию о нем или как его реализовать?

Спасибо.

Answer 1

С обычным клиент-серверным приложением вы не подключаетесь напрямую от клиента к серверу базы данных. Скорее, клиент подключается к серверу (используя LOGINID и LOGINPASS в качестве аутентификации), который затем подключается к серверу базы данных.

Это означает, что клиент не хранит никакой информации о базе данных, а сервер обеспечивает весь доступ к ней.

Answer 2

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

Сделайте это веб-сервисом перед базой данных и просто сделайте два вызова (оба аутентифицированы loginuser & loginpass)

GET / пользователь / _self

Это вернет некоторую информацию о пользователе, так что вы сможете поприветствовать его и проверить, знают ли они его пароль.

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

ПОЧТА / кандидаты / кандидат

Это будет регистрировать голосование от вошедшего в систему пользователя.

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

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

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

Обратите внимание:

• В клиентском приложении нигде нет паролей
• Клиент и сервер проверяют друг у друга открытый ключ пользователя
• Пароль пользователя отправляется (при условии аутентификации BASIC) по проводной связи, но этот провод является SSL-протоколом.
• Вы можете использовать аутентификацию DIGEST через SSL, что означает, что пароль пользователя никогда не передается по проводам.

Answer 3

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

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

Помните, что «любой секретный ключ, который вы встраиваете в программу, может быть восстановлен лицом, имеющим полный доступ к этой программе, лучшее, что вы можете сделать, - это потратить на это много времени». Посмотрите этот вопрос на stackexchange, чтобы узнать, почему https://security.stackexchange.com/questions/35235/how-to-effectively-save-database-password-inside-desktop-application.

Это основная причина, почему DRM всегда побеждал во всей истории вычислений.

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

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

Answer 4

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

Написать серверное приложение (php, servlets?), К которому пользователь может подключиться, и это приложение может обновлять БД.

Если вы не знаете, как это сделать, серьезно, вам не следует писать приложение для голосования.