шифровать пароль, не?

банальный ответ

спросить в толксах

KDE/Gnome хранит в своей какой-то замуте пароли.

>KDE/Gnome хранит в своей какой-то замуте пароли.

бумажник кажись называется

еслиб еще кроссплатформенное, хотя в офтопике кажется чето тоже такое есть, еще думал шифровать, но блин имея на руках прогу в случае чего расшифровать легко будет

А хэши от паролей хранить не?

>А хэши от паролей хранить не?

и шо? я мускулу хэш отправлю вместо пароля?

я думал чел вводит и коннектится

>я думал чел вводит и коннектится

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

ldap?

>ldap?

интересный вариант, в моем случае не подходит, но на будущее учту, спасибо

А кто мешает в обычном конфиге хранить? Права доступа поставить - и всё.

>А кто мешает в обычном конфиге хранить? Права доступа поставить - и всё.

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

Банальный ответ

>спросить в толксах

Не-не-не. ХРАНИТЬ в толксах. Пусть клиентская машина стучится в инет и берёт пароль из специально темы в толксах :-]

Не, пусть создаёт тему с вопросом. Анонимусы подскажут.

>Анонимусы подскажут.

анонимусы у меня в игноре

>и шо? я мускулу хэш отправлю вместо пароля?

Мускул какой версии? Если >=5.0, то именно хэш ему и отправь -- http://dev.mysql.com/doc/refman/5.0/en/old-client.html

>Мускул какой версии? Если >=5.0, то именно хэш ему и отправь -- http://dev.mysql.com/doc/refman/5.0/en/old-client.html

мммм, или я неправильно вопрос сформулировал, или я чего то не знаю

вот смотри, подключаемся к mysql:
db.setHostName(server);
db.setDatabaseName(database);
db.setUserName(user);
db.setPassword(pass);

вот этот pass надо или спрашивать каждый раз, или один раз ввести и хранить где-то, по ссылке немного не то

Ok. Начнём с простого. Какой язык? Какая платформа? Какой тулкит для работы с MySQL?

с++, linux, qt4, mysql 5

>с++, linux, qt4, mysql 5

Я бы написал своего наследника (назовём его, например, HashedMYSQLDriver) от QMYSQLDriver в котором вручную (через C'шный интерфейс mysqlclient) создавал бы MySQL-соединение, используя хэш. Потом бы передавал созданное соединение родителю (QMYSQLDriver, у него есть соотв. конструктор).

В основной программе я бы создавал экземпляр и передавал его статической функции QSqlDatabase::addDatabase ( описание тут -- http://doc.trolltech.com/4.4/qsqldatabase.html#addDatabase-2 ) и от неё получал бы экземпляр QSqlDatabase, через который бы и работал. Собственно, весь код получения экземпляра QSqlDatabase можно засунуть в какую-нибудь фабрику.

Но тут есть одна проблема: C'шная функция mysql_real_connect() принимает пароль Plain-Text'ом и в документации (http://dev.mysql.com/doc/refman/5.0/en/mysql-real-connect.html) указано, что она осуществляет взятие хэша уже внутри. Из решений навскидку могу предложить посмотреть исходники mysql_real_connect(), и на их основе написать свою функцию mysql_real_connect_2(), которая будет делать то-же самое, но будет принимать хэш.

Если есть вопросы -- задавайте. "Кого поразил убогостью мысли -- извиняйте" (с) ...

большое спасибо, я думал по сети тоже передается Plain-Text'ом, а так уже намного проще жить

>большое спасибо

На здоровье, обращайтесь;)

>я думал по сети тоже передается Plain-Text'ом, а так уже намного проще жить

Дык по первой приведённой мной ссылке (первое предложение):

>MySQL 5.0 uses an authentication protocol based on a password hashing algorithm...

>MySQL 5.0 uses an authentication protocol based on a password hashing algorithm...

каюсь, невнимательно читал

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

Если прогу не нужно автозагружать -- то на бумажке в сейфе, или в памяти. Секурно -- хранить безвылазно в каком-то криптооборудовании, но тут вопрос совместимости с методами аутентификации. Остальные случаи эквивалентны файлу с паролями, т.ч. нечего заморачиваться -- выставь права, включи аудит, если не лень -- настрой что-то типа selinux-а на чтение только одной прогой, лучше всё равно не будет.

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

З.Ы. если честно, не очень понимаю почему этого изначально нет в libmysqlclient-dev

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

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

>почему этого изначально нет в libmysqlclient-dev

По описанной выше cvb причине -- это не добавляет "секретности". Зато, как мы видим, может создавать иллюзию таковой -- что ещё опаснее.

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

>хэш необратимый, то есть вытащить из него пасс

Читай ещё раз: если тебе достаточно хеша, то и потенциальному взломщику тоже.

>Читай ещё раз: если тебе достаточно хеша, то и потенциальному взломщику тоже.

черт, а ведь он может сделать то же самое что и я...
не подумал
ты прав, оставлю как есть

создай пользователя в mysql без пароля но с правами ограниченными ровно для достаточной работы программы

>создай пользователя в mysql без пароля но с правами ограниченными ровно для достаточной работы программы

не прет, посторонние не должны ниче видеть

А ограничить доступ для определённого IP ?

или же храни шифрованые данные

Постановка задачи какая-то странная. Если на клиенте есть пароль, зашифрованый или нет, то вытащить его оттуда не составит труда. Считай что в твоем клиентском приложении есть кнопка "запустить mysql клиент и приконнектить его к базе".

Если ты не доверяешь клиенту, то должен настраивать секьюрити в БД или, что лучше, вообще не давать клиенту SQL а перейти на набор каких нибудь вызовов а-ля веб сервисы или RPC или что-то такое, где клиенту будет предоставлены только явно тобой заданные операции.