День добрый.

Для работы с неким приложением на сервере, используется javaws клиент. Этот же клиент стучится в БД согласно прописанных в конфиге настроек. Для всех юзеров проверка прав производится клиентом (согласно данных в БД), но юзер БД всегда используется один и тот же. Поскольку конфиг клиентского приложения ничем не защищен, а юзер БД обладает большими правами, возник вопрос: как лучше было бы скрыть логин-пароль юзера ДБ?
Исходя из того, что сейчас он вообще никак не скрыт - даже тупое дешифрованием из конфига по паролю, зашитому в код, было бы уже полетом в космос. Но! Возможно, "за те же деньги" можно получить более достойный вариант? Например, скидывать процессу на сервере логин/пароль юзера, тот проверяет его, и, если юзер валидный, - отправляет ответом логин-пароль к базе. А далее - все по плану (но тут возникает вопрос шифрования сетевого траффика - иначе во многом теряется смысл).
Кто может что умное присоветовать? Особенно было бы интересно узнать, какие варианты использются вами в реальной жизни.

Всем спасибо.

==========================
ну что, мартышка, - допрыгалась?

Deadyимхо самое действенное - отказаться от толстого клиента. проблема сразу перестанет существовать

Не вариант.

BlackWallЗависит от используемой БД и реализации взаимодействия с ней.
Скажем, для оракла, если вся логика в хранимых процедурах или пакетах, можно создать N пользователей в БД (реально ли?), а сами процедуры должны выполняться в контексте пользователя-владельца схемы БД. Соответственно, для соединения с БД использовать уникальные логины и пароли. Шифрование - несимметричный алгоритм или симметричный с предварительным обменом ключами между сервером и клиентом. Первый вариант помедленее будет. Хранение ключа на клиенте есть плохо.

По пунктам:
1. БД - оракл, но логика размазана между бд и клиентом. И, честно говоря, не очень понимаю как это клеится к вопросу (без наездов, действительно не осознал).
2. N юзверей - это порядка сотни-другой. Гораздо сподручнее держать одного универсального БД юзера для всей этой грвардии.
3. Шифрование.. Тогда получается так:
* Запросить клиентом с сервера паблик кей <А>.
* Сгенерить (можно и одноразовый) ключ (чего-нить симметричного) <B> исходя из логина/пароля юзверя.
* Зашифровать логин/пароль юзверя + ключ <B> ключем <А>. Отправить на сервер.
* Получить зашифрованный ключем <B> логин-пароль доступа к БД, если юзер был валиден.
Вроде, все.
На правду похоже?

Врочем, можно вместо ключа <B> для че-нить симметричного, можно послать с клиента публичный ключ для чего нить нессиметричного :). Тогда протокол вообще можно на одном алгоритме посторить.
===========================
ну что, мартышка, - допрыгалась?

BlackWall
Пункт 3 - в принципе оно, но могу быть модификации например под только что описанную схему.
По поводу последнего поста не согласен. Публичный ключ может быть только у сервера. Нет смысла на клиенте хранить свою пару ключей:) Упрощать некуда.
По поводу паблик кея на клиенте это верно.. Его генерить, по-ходу, не получится.
А хранить глупо.
Сенкс.

wessenМожно на сервер воткнуть томкат с единственным сервлетом, который возвращает параметры для соединения с БД, Томкат настроить на протокол https. И будет все по стандартам без изобретания велосипеда и максимум 100 строк кода.
Томкат там крутится, и выглядит предложение логично, но, вот, вопрос - кто-нить делал это в реальности?
Ну, так, чисто из любопытства.

wessen T800
но, вот, вопрос - кто-нить делал это в реальности?


:)) А чего там делать то? Работы на час. При условии конечно, что вы знакомы с сервлетами и с классами URL, URLConnection или apache http client.
Тут другой вопрос. Если вам нужно всего лишь скрыть логин/пароль, чтобы например пользователь не воспользовался ими в том же sql plus, то зачем тогда городить весь этот огород?

Вот хорошее решение

T800
дешифрованием из конфига по паролю, зашитому в код


Не, сервлет под это дело я напишу. Не за час, ибо давно это было, но неважно. Решение мне однозначно импонирует. Меня, право, несколько озадачил ваш вопрос "Зачем".
Ответ прост: чтобы пользователь (или кто бы то ни было другой) не воспользовался логин/паролем и неважно из каких побуждений. Не мог, и - все тут. А шифрование по паролю, зашитому в код такого же порядка трудоемкости, как и запрос на сервер - будь то процесс или сервлет.

Так что солнечному миру - да, да, да. Шифрованию по зашитому паролю - ... ;)

Другое дело, что если кто отказался в свое время от этой затеи и предпочел другой путь (по каким- то неизвестным нам причинам) - вот что было бы интересно.

mayton T800...Меня, право, несколько озадачил ваш вопрос "Зачем".
Ответ прост: чтобы пользователь (или кто бы то ни было другой) не воспользовался логин/паролем и неважно из каких побуждений. Не мог, и - все тут...
Здесь имеет место какое-то противоречие. Если ему (пользователю) нужен доступ к БД - создаёте ему отдельную учётку с минимальным набором привелегий.

Если вы говорите - "Не мог, и - все тут..." - возникает предположение, что ваша система спроектирована неправильно либо вы сами до конца не понимаете, что собственно вам нужно и зачем.

И вообще, все ваши действия по изобретению собственного протокола передачи пароля (или ключа) - не более чем шаманство. Вы не первый, кто на этот грабель наступает. Возможно для вашего предприятия это "покатит" (в силу различных причин) но тогда разрешите вас поздравить с полным провалом и дискредитацией. Постарайтесь хотя-бы чтобы ваши коллеги не догадались о ваших проделках.
По поводу неправильно спроектированной системы - это действительно так. Далеко не все идеально, в том числе и этот момент с юзерами БД. Так уж получилось, что юзер БД, используемый клиентом имеет достаточно много прав. Не вижу простого пути обойти сей момет (что есть - то есть) - а, вот, скрыть юзера дб - задача вполне выполнимая.
Насчет собственного протокола передачи логина пароля - ну, вообще-то это общепринятый протокол передачи конф. данных по открытому каналу (обычно сеансовых ключей). Кроме того, это можно сделать абсолютно безопасно, но дело не в этом - на то я и топик поднял, чтобы спросить - а как правильно-то?
К вам лично вопрос: решали ли вы когда бы то ни было задачу сокрытия логина/пароля юзера дб на клиентской машине? Есть ли способ избежать этого, при условии, что приложение, например, должно уметь выполнять некоторые операции, но права эти сами по себе опасные и не хотелось бы, чтобы данный аккаунт был общеизвестен.

Спасибо.

Leonidv T800<..>Кроме того, это можно сделать абсолютно безопасно, <..>
Оффтоп, но все же.
Избегайте слова "абсолютно", когда речь идет о защите информации. Особенно при использовании "общепринятых" протоколов.
Готов обсуждать, если вы знакомы (хотя бы) с этим
Было бы интересно.