Проблема с хранением паролей к БД

Разрабатывается многопользовательское web-приложение. В рамках приложения пользователи делятся на группы с различными правами доступа к компонентам приложения.
Есть необходимость группы пользователей приложения отобразить на БД, тоесть на основании необходимых для группы функций на БД создавать группу в БД с правами только на необходимые элементы (таблицы, функции, представления и пр).
Тк администратор приложения может изменять права доступа групп, то есть необходимость также организовать параллельное изменения прав групп(ролей) БД.

предполагаемый алгоритм исполнения приложения относительно авторизации
1. старт приложения производится под пользователем с правами только на чтение полей логина и хеша пароля таблицы пользователей БД (никаких других прав у этого пользователя нет)
2. если авторизация успешна, то приложение получае логин и пароль соответствующей роли в БД и пересоединяется под ними
3. дальнейшее выполнение программы происходит под соответствующей ролью

Проблема с хранением паролей к БД - для пересоединения с базой пароли необхоимо хранить в открытом доступе. Собственно вопрос в том - как хранить пароль ролей к БД, чтобы при несанкционированном доступе (взлом ftp, sshили sql инъекция) злоумышленник не смог получить эти пароли, а приложение могло

Если это SQL-Inj то добавить к таблице какой-нибудь длинный и непонятный префикс + почистить information_schema (там отображаются имена таблиц).
Злоумышленник попросту не сможет подобрать префикс. Если попытается сделать это автоматически, то я думаю в логах легко можно будет заметить аномальную активность.
Если это ftp, то хранить базы выше уровня доступа ФТП + запретить для баз удаленный доступ.
SSH лучше вообще закрыть, хотя есть и другие способы защиты.

Цитата ("zakazchik_kiev"):

...как хранить пароль ролей к БД, чтобы при несанкционированном доступе (взлом ftp, sshили sql инъекция) злоумышленник не смог получить эти пароли, а приложение могло

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

Цитата ("Illarion_SA"):

Пароли в БД необходимо хранить в зашифрованном виде

Это не панацея.

MD5 or SHA1 хеширование

А нужны ли танцы вокруг базы данных?
ИМХО, лучше БД оставить в покое и использовать на уровне приложения продуманный ACL, который можно крутить и перенастраивать как угодно, без лишних мучений.

Каждый пользователь принадлежит к определенной группе, группе или пользователь принадлежит роли.

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

Вы бы уточнили для начала СУБД, если это вшивый MySQL, то тут все также (конечно если у вас есть свой сервер), напишите все на хранимках, дайте им нужные права, ограничите по айпи доступ учетной записи приложения, в чем проблема то?) Даже если я получу пароль от БД веб-приложения, но в настройках СУБД этот аккаунт может конектится только по локалхосту, то злоумышленнику это ничего совершенно не даст, потому что банально он не сможет его использовать. Для этого ему придется работать от имени локалхоста (залив експлоит, или сиквель-инъекцией).

Цитата ("Miller_time"):

Это не панацея.

Разумеется, нет. Взлом любой системы защиты это всегда лишь вопрос времени и/или денег. Тем не менее, метод одностороннего шифрования (или хеширования) паролей обладает тем преимуществом, что даже если хакер получит доступ к содержимому БД и к исходным текстам всех програм, для угадывания пароля ему придется потратить времени достаточно много, чтобы "игра не стоила свеч". С другой стороны, предложенные Вами методы, не обеспечивают устойчивости системы защиты от доступа к исходным текстам, взлома (или обхода) ftp/ssh серверов и - в общем случае - защиты от хакера получившего к серверу доступ "root". Эти ситуации являются достаточно вероятными если сайт "живет" на каком-либо виртуальном или разделенном сервере и к таким сценариям лучше готовиться заранее.

Проблема в том что между запросами нужно где-то хранить пароль в открытом виде, так как это пас от БД. Поступило предложение использовать comet server. Кто-то что-то может сказать на эту тему?

Цитата ("zakazchik_kiev"):

Проблема в том что между запросами нужно где-то хранить пароль в открытом виде, так как это пас от БД.

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

Таблица USER:
- <id пользователя>
- <логин>
- <хэш пароля пользователя> - используется для аутентификации
- <ключ1> - генерируется при создании пользователя, этот ключ закодирован с использованием пароля пользователя (можно использовать любой стойкий симметричный алгоритм шифрования), и используется только для доступа к паролю БД роли.
- <ключ2> - этот же самый ключ, но только закодированный ключем админа, к этому полю доступ на SELECT и UPDATE имеет долько админ (реализовано средствами БД), используется для перешифровки ключа1 если админ меняет пароль пользователя.

Таблица USER_ROLE:
- <id пользователя>
- <id роли>
- <пароль роли> - зашифровано с использованием ключа1 пользователя

Как это работает:

1. Сценарий получения пароля БД роли пользователем:
1.1. Коннект. Пользователь коннектится к БД с минимальными правами, при этом он имеет доступ на операцию SELECT только к таблице USER и USER_ROLE.
1.2. Аутентификация. Проверяется логин и хэш пароля, если не подходит - соединение закрывается и выводится сообщение об ошибке.
1.3. Расшифровка ключа1. Расшифровываем ключ1 с использованием пароля пользователя.
1.4. Получение пароля БД роли. Расшифровываем пароль БД роли с использованием ключа1.

2. Сценарий смены своего пароля пользователем (считаем, что пользователь уже законнектился и авторизовался, и таблица USER доступна для операций SELECT и UPDATE):
2.1. Расшифровка ключа1 с использованием старого пароля. См. пункт 1.3.
2.2. Шифрование ключа1 с использованием нового пароля.
2.3. Создание хэша нового пароля пользователя.
2.4. Сохранение нового хэша и ключа1 в БД.

3. Сценарий смены пароля пользователя админом (считаем, что админ уже законнектился и авторизовался, и таблица USER доступна для операций SELECT и UPDATE):
3.1. Расшифровка ключа2 с использованием пароля админа.
3.2. Шифрование ключа2 с использованием нового пароля пользователя, и сохранение в качестве ключа1.
3.3. Создание хэша нового пароля пользователя.
3.4. Сохранение нового хэша и ключа1 в БД.

4. Сценарий создания нового пользователя админом (считаем, что админ уже законнектился и авторизовался, и таблицы USER и USER_ROLE доступны для операций SELECT и INSERT):
4.1. Запрос логина и пароля нового пользователя.
4.2. Создание хэша нового пароля пользователя.
4.3. Генерация ключа1 и ключа2 (это может быть любая случайная последовательность байт, или символов, и т.д.).
4.4. Кодирование ключа1 с помощью пароля пользователя.
4.5. Кодирование ключа2 с помощью пароля админа.
4.6. Сохранение данных в таблице USER.
4.7. Получение пароля БД роли с использованием пароля админа и ключа1 админа. См. 1.3. и 1.4.
4.8. Кодирование пароля роли с использованием ключа1 пользователя.
4.9. Сохранение в таблице USER_ROLE.

5. Сценарий смены пароля БД роли админом (считаем, что админ уже законнектился и авторизовался, таблица USER доступна для операций SELECT, и таблица USER_ROLE доступна для операций SELECT и UPDATE):
5.1. Запрос нового пароля роли.
5.2. Для каждого пользователя, использующего данную роль: расшифровка ключа2, шифрование нового пароля роли с использованием ключа2, сохранение этого зашифрованного пароля роли в USER_ROLE для данного пользователя.

Вообще, всю эту логику желательно перенести в хранимые процедуры (чтобы минимизировать риск того, что хакер, получив доступ к приложению, может внедрить в него свой код для получения паролей), также желательно использовать шифрование всех данных (так как если данные не зашифрованы, хакер может извлечь их из БД даже не зная никаких паролей, если физически получит доступ к файлам базы данных), также имеет смысл дополнительно проверять с помощью триггеров текущего пользователя при изменении данных (чтобы он мог изменять только соответствующие ему данные, например, даже получив доступ к БД на уровне консоли, мог менять пароль только себе, и не мог менять другим пользователям), и имеет смысл регулярно (например ежедневно или еженедельно) автоматически перегенерировать ключ1 и ключ2 каждого пользователя, и т.д. Каждый подобный шаг будет повышать уровень безопасности, но это отдельная и довольно обширная тема.

Цитата ("zakazchik_kiev"):

Поступило предложение использовать comet server. Кто-то что-то может сказать на эту тему?

Это к данной задаче не имеет никакого отношения.