Где и как лучше хранить пароль к БД?

← →
nobody (2010-09-21 13:50) [0]

Есть приложение (ERP-система) на базе Oracle.
В БД в отдельной таблице заведены все пользеры, которые имеют доступ в это приложение, между которыми раздаются права на функционал приложения.
Само приложение ходит в базу под одной учетной записью.
Сейчас этот пароль зашит в коде. Где и как лучше его хранить, чтобы можно было менять пароль без перекомпиляции.
Рассматриваю вариант в ини-файле, зашифрованный любым алгоритмом
какие еще могут быть варианты?

← →
DiamondShark © (2010-09-21 13:52) [1]

> какие еще могут быть варианты?

SSPI-authentication

← →
Ega23 © (2010-09-21 14:31) [2]

> Рассматриваю вариант в ини-файле, зашифрованный любым алгоритмом

А ключ ты где будешь хранить?

← →
Mystic © (2010-09-21 14:45) [3]

> А ключ ты где будешь хранить?

Да хоть в самом приложении! Все требования выполнены, программа не требует перекомпиляции :)

← →
Petr V. Abramov © (2010-09-21 14:49) [4]

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

← →
nobody (2010-09-21 15:15) [5]

> делай нормальную авторизацию, которая исключит хранение
> секретного пароля на клиентской машине.

а можно с этого момента более подробно?

← →
nobody (2010-09-21 15:26) [6]

> шифруй, не шифруй, все равно получишь взлом.

Да мне не нужна защита от влома. Для этого есть отдел СБ.
Меня интересует, как можно менять пароль на базу без перекомпиляции целевого приложения

← →
YurikGL © (2010-09-21 15:33) [7]

> а можно с этого момента более подробно?

Делай учетную запись для каждого пользователя...

← →
Ega23 © (2010-09-21 15:34) [8]

> Меня интересует, как можно менять пароль на базу без перекомпиляции
> целевого приложения

Просить пользователя ввести его руками.
Либо брать из файла настроек.
Либо построить трёхзвенку, чтобы клиент вообще не знал, с каким типом хранилища данных он работает, и где это хранилище располагается.

← →
Petr V. Abramov © (2010-09-21 15:39) [9]

> а можно с этого момента более подробно?
>

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

← →
Игорь Шевченко © (2010-09-21 17:35) [10]

> или, что лучше, используй оракловую

каким образом ?
если учесть, что "Само приложение ходит в базу под одной учетной записью"

← →
Petr V. Abramov © (2010-09-21 17:37) [11]

> Игорь Шевченко © (21.09.10 17:35) [10]

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

← →
nobody (2010-09-21 17:59) [12]

> но никто ж не мешает принять православие начать ходить под
> разными.

надо заводить 1300 пользеров.
как вы себе это представляете? а раздачу прав на функционал в ста формах?...

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

← →
Игорь Шевченко © (2010-09-21 18:09) [13]

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

а сообщить его пользователям, чтобы вводили, никак ?

← →
YurikGL © (2010-09-21 18:22) [14]

> надо заводить 1300 пользеров.
> как вы себе это представляете? а раздачу прав на функционал
> в ста формах?...
>

Большое подозрение, что этот процесс можно тем или иным образом автоматизировать и не повторять для каждого пользователя. Зато получится гораздо более правильное решение...

← →
Petr V. Abramov © (2010-09-21 18:35) [15]

> Игорь Шевченко © (21.09.10 18:09) [13]

а нафик его вводить, если у всех один? тогда без пароля проще.

> надо заводить 1300 пользеров.

табличку с ФИО в кадрах взять, из экселя залить в оракл в какую-нить техническую, и скриптом создать юзеров, в качестве логина использовать ФИО. С полными тезками и однофамильцами разобраться лично, их не так много. Это например.

> а раздачу прав на функционал в ста формах?...
>

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

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

на 1300 компах менять?
вынеси в реестр, в ини-файл, на корпоративный сайт - толку от него все равно нет.

← →
Игорь Шевченко © (2010-09-21 21:12) [16]

> а нафик его вводить, если у всех один? тогда без пароля
> проще.

Правильно, из инишника читать

← →
nobody (2010-09-22 11:42) [17]

> а сообщить его пользователям, чтобы вводили, никак ?

пользователи потом залезут напрямую в базу и поправят ее ручками:)

если заводить пользователей в базе, то потом нужно переписывать кучу кода, который раздает права на функционал в коде. Сейчас по номеру группы и названию формы вычитываются из общей таблицы названия контролов и соответствующие флаги доступа по ним. Привязка к названиям компонентов меня не устраивает, хотя бы по номеру тега сделать бы...
Потом как организовать структуру пользователей в центры, департаменты, отделы, сектора? Где хранить данные самого пользователя - номер мобильно, эл. почту, должность - на это все уже есть готовая структура, которая работает
И перелопатить все структуру заново и переписать весь код , который развивался с 2001-го, никто не даст.
Да, согласен, если создавать с нуля, то надо заводить каждого в базу и создавать для него роли, и аудит по нему вести штатными средствами.
Но в существующей разработке это просто нереально.

← →
Sergey13 © (2010-09-22 12:20) [18]

> [17] nobody (22.09.10 11:42)

При такой постановке вопроса зачем вообше менять пароль?

> [0] nobody (21.09.10 13:50)
> чтобы можно было менять пароль без перекомпиляции.

Что бы в час "Ч" 1300 пользователей просто обломилась?

← →
Игорь Шевченко © (2010-09-22 13:45) [19]

> пользователи потом залезут напрямую в базу и поправят ее
> ручками:)

Хранить в инишнике в зашифрованном виде

> Игорь Шевченко © (22.09.10 13:45) [19]
> Хранить в инишнике в зашифрованном виде
>

еще раз: баловство.
расшифрованный пароль за минуту снимается OCI-трейсером. бесплатным-шароварным. скачанным из инета за еще одну минуту.

← →
nobody (2010-09-22 16:30) [21]

> Хранить в инишнике в зашифрованном виде

да, пожалуй так и сделаем.
осталось решить вопрос, как обновлять этот инишник...

> еще раз: баловство.
> расшифрованный пароль за минуту снимается OCI-трейсером.
> бесплатным-шароварным. скачанным из инета за еще одну минуту.
>

учет подобных инцидентов прописан в должностных инструкциях СБ.
Мы не преследуем цель защиты от взлома.

А зачем шифровать?

> расшифрованный пароль за минуту снимается OCI-трейсером.
> бесплатным-шароварным. скачанным из инета за еще одну минуту.
>

Он снимается отовсюду, если не использовать OS Authentification. А ее нельзя использовать по условиям задачи автора.

> осталось решить вопрос, как обновлять этот инишник...
>

пусть СБ обновляет

> Игорь Шевченко © (22.09.10 16:41) [23]

> Он снимается отовсюду, если не использовать OS Authentification.
> А ее нельзя использовать по условиям задачи автора.

если сделано эээ.... не как у автора, а как ораклом задумано, снимать свой собственный пароль как смысла нету, какой Authentification ни ставь.

> Игорь Шевченко © (22.09.10 17:03) [26]

к тому что может кто одумается или в другой раз по граблям не пойдет, и мир станет совершеннее :)

Где и как лучше хранить пароль к БД? Найти похожие ветки