| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: Базы данных и репортинг > MySQL только из моей программы |
| Автор: RinOSpro 23.4.2009, 16:52 |
| Всем привет! Есть БД на MySQL, есть моя программа. Можно ли сделать как ни будь, так что бы сервер соединялся только с моей программой, при этом, к нему нельзя было подключится из других (phpMyAdmin, и т.п.) Сделайте пожалуйста зеркало на ветку по MySQL. |
| Автор: Kbl4AH 23.4.2009, 16:59 | ||
а ты другим логин/пароль не говори |
| Автор: RinOSpro 23.4.2009, 17:12 |
| Kbl4AH смешно База много пользовательская. Есть моменты когда одни пользователи могут в просматривать только свои записи. В программе естественно стоит условие. Но вот теперь представим что кто то особо умный кто имея пароль подключился к БД через phpMyAdmin и посматрел все что ему не положено было бы смотреть. Поэтому я и хочу ограничиться подключением только из своей программы. Есть идеи? |
| Автор: RinOSpro 23.4.2009, 17:56 |
| Kbl4AH есть 10 пользователей. У каждого есть логин и пароль. Есть определенный набор дейсвий которые они могут выполнять. Права расставлены. Есть скажем таблица Messages. Пользователи могут и должны работать с этой таблицей, но только со своими записями. Смотреть и уж тем более изменять чужие они не должны. Через программу так оно и есть. Но проблема в том что можно зайти не через мою программу (( а через phpMyAdmin к примеру. |
| Автор: Kbl4AH 23.4.2009, 21:51 | ||
так я про это же... твой пользователь значит должен иметь права на запись в Messages, а другой пользователь (любой кроме тебя) не должен заходить под твоим логином/паролем, а должен заходить под своими и не должен иметь прав чтения Messages... БД ведь не знает через какое приложение к ней подцепились... она только знает кто подцепился и какие он имеет права... ЗЫ. и я совсем не представляю как ты собираешься скрыть свои данные скажем от админа БД... |
| Автор: RinOSpro 24.4.2009, 09:30 |
| Kbl4AH раз не понял проблему и не можешь сказать что то по существу! Просьба не засорять топик бесполезными сообщениями. Тем более что: |
| Автор: Bose 24.4.2009, 12:25 | ||
Тогда лучше не давать пользователям прав на прямое чтение этой таблицы(!). А создать View или Stored Procedure, которая будет возвращать, только те записи, которые разрешено видеть текущему пользователю. В программе выводить данные через этот View/Stored Procedure. |
| Автор: Poseidon 24.4.2009, 12:38 |
| Сделай эти логины и пароли данными доступа к программе. А логин и пароль доступа к БД зашей в саму программу. На основании введенного логина и делай фильтрацию. Вот и получишь что пароль к БД будет "знать" только твоя программа, а пользователи будут иметь доступ к этой программе по своим, персональным логинам, никак не связанным с доступом к БД. |
| Автор: RinOSpro 24.4.2009, 13:03 |
| Bose как вариант да, но это не решает проблему, ведь я образно привел одну таблицу хотя на деле их поболее. Вот еще если если на таблицу нет прав, а на хранимку поставить, то разве будет работать хранимка? Poseidon пароль из программы вытащить не так уж и сложно. |
| Автор: Poseidon 24.4.2009, 14:12 |
| Ну если так рассуждать, то и сервер не так уж сложно заставить думать, что к нему подключается именно твоя программа, когда на самом деле это не так. Против взлома ты вообще не защитишься. |
| Автор: insoft 24.4.2009, 14:13 |
| RinOSpro а метод шифрования данных тебе не подойдёт? потому что пароль как ты не крути никак не спрячешь, администратор в любом случае должен его знать.. |
| Автор: RinOSpro 24.4.2009, 14:28 | ||
| insoft как реализовать шифрование средствами MySQL? ps Администратор я. Добавлено через 3 минуты и 58 секунд
Для начала надо научить его так думать)) Я вот пока не знаю как) И пока не услышал) Единственное что более похоже на реальное использование, так это хранимки или вьюхи. Добавлено через 9 минут и 26 секунд С таблицей Messages ни чего нельзя делать ни читать ни писать. Читать можно через View а как писать? Через хранимки? |
| Автор: RinOSpro 24.4.2009, 14:50 | ||||
| Хотя через вьюхи тоже не получится ((( Вот смотрите:
Мы создали пользователя и отключили у него все права (даже на чтение)!!! теперь он не может даже видеть базу по SHOW DATABASE! Но если мы включим ему разрешение на SELECT то потом для отдельных таблиц перекрыть не сможем. тк нельзя перекрыть права более высокого уровня.
|
| Автор: Poseidon 24.4.2009, 15:02 |
| RinOSpro, думаю тут только средствами php получится. На подобии как данный форум реализован. Т.е., как вариант, делаешь php-скрипт, который лезет в БД и возвращает данные. А программой же ты эти данные получаешь и обрабатываешь. Прокраммой, кстати, может стать и браузер. Но можно и свою научить. Иначе я не вижу варианта как защититься от взлома и получения пароля и при этом ограничить доступ. Да, при использовании php можно ведь поставить в настройках сервера мускула доступ только с локалхоста. Тогда точно поотваливаются всякие майадмины и прочее. |
| Автор: RinOSpro 24.4.2009, 16:25 | ||
Обратил внимание на это 'user'@'%'? это значит что юзеры могут подключаться с любого хоста. Программа написана на Delphi то есть в процессе написания. Хотя на счет 3 звенной авторизации идея хороша! Пользователь не имеет пароля к БД но имеет пароль авторизации, который в месте с логином отправляется в скрипт кторый в свою очередь возвращается пароль к БД и программа коннектиться. http://ipicture.ru/ плюсы: человек не сможет подключится к БД тк этот пароль не является паролем БД. минусы: снифер еще ни кто не отменял, проще будет получить даже чем из зашифрованного экзешника. сложно будет поддерживать много пользователей. Так народ, хорошие идеи стали появляться)) Высказываем не стесняемся) |
| Автор: Bose 25.4.2009, 01:15 | ||||
Честно скажу, я с MySql в таком плане работал. А вообще, я подразумевал, что можно выдать права на SELECt из вьюх/хранимов, не давая юзерам прав на чтение таблиц. А для вьюх и хранимок выдать права на работу с таблицами. Модификация данных через триггеры/хранимки (если в MySql такое есть). Ещё возможен вариант, когда пользователь вводит пароль, пароль шифруется(или тупо берётся хэш) каким-то образом, и к БД подключается уже с помощью зашифрованного пароля. Но при создании пользователя/смене пароля, введённый пользователем пароль тоже должен быть зашифрован. Таким образом, зная свой пароль пользователь может войти в программу, но не может подключится к БД, потому что работа с БД ведётся уже через другой пароль. Который, зная алгоритм, может быть получен из пользовательского. |
| Автор: RinOSpro 27.4.2009, 09:35 |
| Bose да тоже не плохой вариант |
| Автор: Bose 27.4.2009, 23:47 | ||
Нет. Идея в том, что зашифрованный пароль передаётся прямо на сервер. И пароль нигде не расшифровывается. |
| Автор: Keeper89 28.4.2009, 00:21 | ||
+ т.е. на сервере хранятся сами хеши или другие зашифрованные пароли. |
| Автор: RinOSpro 28.4.2009, 10:41 |
| Bose хм... тогда я ни чего не понял... Вот смотри есть ADOConnection там есть параметры login password. И куда подсовывать зашифрованнный пароль? |
| Автор: Bose 28.4.2009, 11:30 |
| Например: Есть юзер, который знает свой логин: user1 и пароль test1 Есть функция шифрующая пароль. Зашифрованный пароль test1 будет выглядеть например так: 1tset. В базе данных создаётся аккаунт для этого пользователя: логин: user1 пароль: 1tset (уже зашифрованный) Получается, программа стартует, юзер вводит логин: user1 и пароль: test1. Программа шифрует этот пароль и получает 1tset. В ADOConnection передаётся user1 и 1tset. Получается, что если юзер подключается к БД через программу, то всё ок. А если захочет напрямую, то ничего у него не выйдет. |
| Автор: Kbl4AH 28.4.2009, 11:54 |
| Bose, так ведь в екзешнике пароль этот посмотреть можно... RinOSpro, наверное, это имеет ввиду... |
| Автор: Keeper89 28.4.2009, 12:06 |
| Мне кажется, Bose имеет ввиду шифрование паролей пользователей, а не соединения ADO. Добавлено через 2 минуты и 12 секунд В этом случае есть 2 варианта:
|
| Автор: RinOSpro 28.4.2009, 12:26 |
| Kbl4AH в точку =) В отладчике можно будет увидеть это зашифрованный пароль. Bose когда я на лету буду шифровать и передавать в ADOConnection пароль то человек отлаживающий программу скажем через OllyDbg тоже ее увидит 1tset тот самый пароль передающийся на сервер. Но в целом очень даже не плохой метод =) Легко реализуемый. |
| Автор: Bose 29.4.2009, 00:00 | ||||
Ну знаешь со всех сторон соломки не подстелишь! И вообще, какова вероятность того, что кто-то из пользователей: 1) умеет пользоваться phpMyAdmin 2) догадается каким образом сделана защита 3) будет специально дебажить программу в OllyDbg(кстати, а как им пользоваться 4) будет иметь время и желание для того чтобы этим заниматься 5) всё вышеперечисленное вместе взятое
В том и прелесть, что легко реализуемый. |
| Автор: RinOSpro 29.4.2009, 09:20 |
| Bose я боюсь утечки пароля), а уж желающие поломать найдутся)) специфика ПО такая)) Ну может в голове у когото родилась еще какая гениальная идея? )) |
| Автор: Bose 29.4.2009, 23:57 | ||
Тогда как вариант - сервер приложений. Пароль передаётся туда и шифруется уже там. В этом случае доступ к базе данных вообще можно закрыть снаружи. |
| Автор: RinOSpro 30.4.2009, 16:02 | ||
Не совсем понял смысл "сервера приложений"... Ты предлагаешь 3-х звенную архитектуру? Типа DataSnap, SOAP? Нет такой вариант не подходит. Единственное что возможно так это криптор написанный на php (хотя бы скроем алгоритм шифрования) что бы усложнить жизнь взломщикам. |
| Автор: Bose 30.4.2009, 22:26 | ||
да. ну как знаешь. |