toweroff
Nov 17 2011, 11:42
Вот возникла такая задача - из приложения получить доступ к базе
Казалось бы - ничего сложного, dbExpress в руки и вперед
НО!
Логин/пароль к базе будут храниться в exe-щнике, который очень просто распотрошить
Как нормальные люди решают подобные задачи?
ЗЫ
Пользователь будет в приложении вводить свои логин/пароль, приложение должно соединиться с базой, выщемить оттуда данные, в зависимости от данных приложение будет себя вести в соответствии с ними каким-то образом
AHTOXA
Nov 17 2011, 13:02
Может, пусть пользователь вводит свой пароль к базе, а уже там хранится всё остальное?
Тогда не возникнет нужды хранить пароль в exe-шнике.
toweroff
Nov 17 2011, 13:11
Цитата(AHTOXA @ Nov 17 2011, 17:02)

Может, пусть пользователь вводит свой пароль к базе, а уже там хранится всё остальное?
Тогда не возникнет нужды хранить пароль в exe-шнике.
ну тогда для этой базы нужно создавать кучу пользователей. Геморройно с точки зрения хостинга да и зачем?
там все дело в том, что всякие mysql_real_connect в качестве параметров требуют явно указать login/pass администратора базы
хочется замутить какой-то механизм, чтобы приложение лезло на сервер через какой-то PHP скрипт, исполняемый на сервере. Вот тут и пригодятся логины пользователей и т.д. которые они руками вводят, а админовские аккаунты никогда за сервер не выйдут
AHTOXA
Nov 17 2011, 17:54
Что есть куча пользователей с точки зрения базы? Те же самые записи базы данных

Или dbExpress не позволяет программно создавать пользователей?
Я к чему веду. Всяко в вашей программе будет интерфейс создания пользователей. Так пусть этот интерфейс вместо создания пользователей в специальной табличке базы данных создаёт их сразу как пользователей MySQL. Это решит ваши проблемы с хранением паролей.
А права конкретного пользователя после ввода пароля можно определять по правам пользователя MySQL на какую-либо таблицу.
По сравнению с хранением пароля в exe это видится более грамотным решением. ИМХО конечно.
toweroff
Nov 17 2011, 20:18
хмм.. видно, я не совсем точно описал вводные данные
есть пользователи, для которых априори будет нечто в базе (пользователь MySQL с правами, или запись в некой таблице о его данных)
нужно подсоединиться к базе из приложения (пользователь вводит логин/пароль), получить доступ ТОЛЬКО к тем данным, которые относятся к этому пользователю
пользователи создаются заранее, сам он не может зарегистрироваться
ну и 100% никакие логины/пароли в приложении не должны храниться
Цитата(toweroff @ Nov 17 2011, 15:42)

Вот возникла такая задача - из приложения получить доступ к базе
Казалось бы - ничего сложного, dbExpress в руки и вперед
НО!
Логин/пароль к базе будут храниться в exe-щнике, который очень просто распотрошить
Как нормальные люди решают подобные задачи?
Во первых сгенерить логин и пароль в виде случайных (и длинных) строк (что бы они не опознавались именно как осмысленные строки). Во вторых в exe'нике их зашифровать, что бы их не было видно именно в виде строк.
Если приложение ставится на компьютер отдельно, то можно при установке записать логин и пароль на компьютер (в реестр в зашифрованном виде, а ключ через CryptoAPI в локальное хранилище ключей), и отдельно само приложение (в нем уже никаких логинов/паролей не будет вообще)
Кстати, если на машине есть TPM, то можно ключ записать туда. Тогда даже сняв копию со всей системы нельзя будет перенести это на другой комп.
kolobok0
Nov 18 2011, 11:03
Цитата(toweroff @ Nov 18 2011, 00:18)

...нужно подсоединиться к базе из приложения (пользователь вводит логин/пароль), получить доступ ТОЛЬКО к тем данным, которые относятся к этому пользователю...ну и 100% никакие логины/пароли в приложении не должны храниться.
если нужен коннект от клиента к бд и только со своими правами (и нельзя хранить на клиенте явки-пароли), то тут АНТОХА всё прально написал. в точке где заводится клиент, его логин/пароль=логин/пароль к самой базе и права на базу=те которые вы прописываете при создании. механизм создания(скрипт) учётки в базе - на серваке.
но это решение (держать коннекты к базе от клиентов) - мягко говоря нагрузка на БД. при этом в будущем эту систему тяжело масштабировать и сопровождать.
удачи вам
(круглый)
toweroff
Nov 18 2011, 11:30
спасибо
нагрузки будет мало, очень мало
логин/пароль будет жестко прошит в девайсе, который будет отдаваться клиенту (для каждого свои). То есть перед тем, как девайс будет вручен клиенту, создается доступ к базе по логинау/паролю в этом девайсе. Потом пользователь подключил девайс, прога выудила из него эти логины и с этим начала ломиться к базе. Оттуда получает пару сотен байт и закрывает соединение
Соответственно, даже если выудить из девайса информацию о логине и пароле, не должно произойти следующего:
1. Получения сведений о других девайсах (точнее, данных, относящихся к ним)
2. Получения сведений, относящихся к этому девайсу, но входящих в "админовое" поле
Да, пользователи MySQL - интересный подход. Но!
Допустим, данные хранятся в нескольких таблицах. ID девайса, дата передачи. ID девайса, его "путешествия". ID девайса, ключи шифрования
Это так, образно
Вот скажите мне, можно правами пользователя MySQL навесить фильтр на ID? То есть логинится пользователь, к нему каким-то образом привязывается ID девайса
И к любым запросам, которые он будет делать к этим таблицам, будет автоматом добавлен фильтр по ID?
Если такое возможно, то таки да, есть смысл регулировать все пользователями MySQL и их правами. Если нет - тогда нужен друной путь...
AlexandrY
Nov 18 2011, 13:08
Цитата(toweroff @ Nov 18 2011, 13:30)

нагрузки будет мало, очень мало
Логичнее каждому пользователю создавать собственную базу данных или собственный набор таблиц.
toweroff
Nov 18 2011, 13:13
Цитата(AlexandrY @ Nov 18 2011, 17:08)

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

может есть какой-то способ создавать соединение, а запросы лепить из PHP... вот только как, да и правильно ли это...
Цитата
Вот скажите мне, можно правами пользователя MySQL навесить фильтр на ID?
Нет, только целиком на таблицы
У вас есть сервер, к которому коннектятся пользователи? Если да, то все пароли администратора должны быть в этом сервере, а пользовательские программы (клиенты) вообще не должны напрямую лезть в базу - а только через ваш сервер.
toweroff
Nov 18 2011, 14:02
Цитата(XVR @ Nov 18 2011, 17:57)

Если да, то все пароли администратора должны быть в этом сервере, а пользовательские программы (клиенты) вообще не должны напрямую лезть в базу - а только через ваш сервер.
вооот!!
именно это и есть
собссно вопрос-то в том, каким путем правильнее идти, чтобы это реализовать?
AlexandrY
Nov 18 2011, 14:42
Цитата(toweroff @ Nov 18 2011, 15:13)

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

Какого анализа?
Если самим юзерам не позворляется посмотреть что у других, то почему они должны позволять это делать какому-то администратору.
Неясна политика безопасности однако.
toweroff
Nov 18 2011, 14:47
Цитата(AlexandrY @ Nov 18 2011, 18:42)

Какого анализа?
Если самим юзерам не позворляется посмотреть что у других, то почему они должны позволять это делать какому-то администратору.
Неясна политика безопасности однако.
что значит "какому-то администратору"?
он-то как раз должен знать, что там эти пользователи делали. Причем простым селектом
AHTOXA
Nov 18 2011, 15:17
Цитата(toweroff @ Nov 18 2011, 17:30)

Вот скажите мне, можно правами пользователя MySQL навесить фильтр на ID? То есть логинится пользователь, к нему каким-то образом привязывается ID девайса
И к любым запросам, которые он будет делать к этим таблицам, будет автоматом добавлен фильтр по ID?
Если такое возможно, то таки да, есть смысл регулировать все пользователями MySQL и их правами. Если нет - тогда нужен друной путь...
Не выйдет. Права даются на отдельную таблицу.
Но. Можно создать для каждого пользователя отдельный VIEW типа "SELECT * FROM TABLE_FOR_ALL_USERS WHERE USER_ID = x", и дать ему полные права на этот вид. А на таблицу - не давать.
Тогда выйдет как надо - есть общая таблица для сбора статистики, а для каждого пользователя для неё отдельный вид.
AlexandrY
Nov 18 2011, 15:21
Цитата(toweroff @ Nov 18 2011, 16:47)

что значит "какому-то администратору"?
он-то как раз должен знать, что там эти пользователи делали. Причем простым селектом
Странный сценарий.
Администратор это тот кто создает, удаляет и архивирует таблицы и базы данных, смотрит логи. Сами данные он смотреть не может.
Это по логике.
Но о каком этапе жизни продукта говорим. О разработке или эксплуатации?
toweroff
Nov 18 2011, 15:26
Цитата(AHTOXA @ Nov 18 2011, 19:17)

Не выйдет. Права даются на отдельную таблицу.
Но. Можно создать для каждого пользователя отдельный VIEW типа "SELECT * FROM TABLE_FOR_ALL_USERS WHERE USER_ID = x", и дать ему полные права на этот вид. А на таблицу - не давать.
Тогда выйдет как надо - есть общая таблица для сбора статистики, а для каждого пользователя для неё отдельный вид.
как это я про VIEW забыл... давно с базами не работал... лет эдак 10

буду пробовать
самое главное, чтобы хостер разрешил добавление юзверей в базу, надо проверить
спасибо, буду тестить
AlexandrY
Nov 18 2011, 15:26
Цитата(AHTOXA @ Nov 18 2011, 17:17)

Не выйдет. Права даются на отдельную таблицу.
Но. Можно создать для каждого пользователя отдельный VIEW типа "SELECT * FROM TABLE_FOR_ALL_USERS WHERE USER_ID = x", и дать ему полные права на этот вид. А на таблицу - не давать.
Тогда выйдет как надо - есть общая таблица для сбора статистики, а для каждого пользователя для неё отдельный вид.
ИМХО. Легче триггера поставить которые бы реагировали на каждую запись в каждую собственную пользовательскую таблицу и писали дополнительно в общую для "анализов". Потом легче было бы разрулить проблемы с целостность данных, надежностью и защитой.
Потому как связавшись с параметрическими запросами придется их юзать при каждой мелкой работе с данными.
toweroff
Nov 18 2011, 16:04
Цитата(AlexandrY @ Nov 18 2011, 19:21)

Странный сценарий.
Администратор это тот кто создает, удаляет и архивирует таблицы и базы данных, смотрит логи. Сами данные он смотреть не может.
Это по логике.
Но о каком этапе жизни продукта говорим. О разработке или эксплуатации?
наверное, не так выразился
доступ нужен не тому, кто обслуживает базу как таковую, а пользователю, который может смотреть все записи
посмотрел
нет у меня прав на создание пользователей

на компе можно, на серваке phpmyadmin не дает создать юзверя. Буду хостера бодать
Цитата(toweroff @ Nov 18 2011, 18:02)

вооот!!
именно это и есть
собссно вопрос-то в том, каким путем правильнее идти, чтобы это реализовать?
Путем создания сервлета на сервере (если хостер предоставляет такой сервис). Если нет, то придется всю бизнес логику реализовывать на стороне клиента, что в принципе является большой дырой в безопасности и стабильности системы
toweroff
Nov 19 2011, 17:47
Цитата(XVR @ Nov 19 2011, 19:18)

Путем создания сервлета на сервере (если хостер предоставляет такой сервис). Если нет, то придется всю бизнес логику реализовывать на стороне клиента, что в принципе является большой дырой в безопасности и стабильности системы

а что такое сервлет?
пока реализовано добавление юзера, создание для него представления VIEW с фильтрацией по его ID с правами только SELECT
вроде нормально работает на локальной машине
в приложение вкручено API MySQL - libmysql, не стал я с ODBC, dbExpress и подобными вещами возиться
попробую потолкать хостера, чтобы разрешил мне создавать пользователей с назначением им таких прав
Цитата(toweroff @ Nov 19 2011, 21:47)

а что такое сервлет?

Это грубо говоря программа, работающая на хосте. Именно она общается с базой данных, а пользователи общаются с ней, база данных напрямую им вообще не доступна.
toweroff
Nov 21 2011, 09:56
Цитата(XVR @ Nov 21 2011, 13:05)

Это грубо говоря программа, работающая на хосте. Именно она общается с базой данных, а пользователи общаются с ней, база данных напрямую им вообще не доступна.
в целом это понятно. Гугл есть, на крайняк можно тут спросить
вопрос в другом - каким способом из приложения мне достучаться до этого сервлета?
пока единственное, что нашел - пользовать TIdHTTP. Оттуда формировать запрос, получать ответ.
Какими еще компонентами можно воспользоваться?
Или я вообще не в ту сторону повернулся и заморочки с MySQL - более простое и безопасное решение?
Цитата
вопрос в другом - каким способом из приложения мне достучаться до этого сервлета?
Со стороны клиента этот сервлет будет представлен некоторым URL. Запросы будут представлены параметрами (в URL) или частью пути (опять же в URL).
Цитата
пока единственное, что нашел - пользовать TIdHTTP. Оттуда формировать запрос, получать ответ.
Стандартный WEB браузер (DHTML/JS/Ajax - по желанию/Flash/Flex). Можно еще Java подключить (тогда вообще открывается масса возможностей для связи с сервлетом - JSON, CORBA, SOAP и т.д. и т.п.) Делать морду на Builder'е для Internet приложения - путь явно тупиковый.
Цитата
Или я вообще не в ту сторону повернулся и заморочки с MySQL - более простое и безопасное решение?
Если вы выставите MySQL базу в Internet, то готовьтесь к тому, что ее будут ломать всем Internet'ом (чисто из спортивного интереса)
PS. Задайте свой вопрос
тут
toweroff
Nov 21 2011, 12:36
Цитата(XVR @ Nov 21 2011, 14:28)

Делать морду на Builder'е для Internet приложения - путь явно тупиковый.
почему? мне всего-то нужно залогиниться, получить кусок инфы и разлогиниться
Цитата(XVR @ Nov 21 2011, 14:28)

Если вы выставите MySQL базу в Internet, то готовьтесь к тому, что ее будут ломать всем Internet'ом (чисто из спортивного интереса)
а вот тут правда Ваша, не подумал

если через Indy - лезу на спец.страницу, логинюсь, PHP выплюнет мне какие-то данные, индеец ее назад получит, я в программе обработаю
получается, ни куча пользователей MySQL не нужна, ни сервлеты
или я опять что-то упустил? опыта-то в таких делах никакого
Цитата
почему? мне всего-то нужно залогиниться, получить кусок инфы и разлогиниться
А инфа пусть пропадает? Или все же с ней нужно что то сделать

На чем писать (и в каком виде) сильно зависит от того, что нужно сделать. Вариант с WEB браузером хорош тем, что пользователю не надо будет ставить никаких специальных программ, и обновлять их (если что) тоже не надо.
Цитата
если через Indy - лезу на спец.страницу, логинюсь, PHP выплюнет мне какие-то данные, индеец ее назад получит, я в программе обработаю
Можно
Цитата
получается, ни куча пользователей MySQL не нужна, ни сервлеты
В этом случае ваша PHP страница и будет сервлетом (правда очень примитивным)
toweroff
Nov 21 2011, 15:16
Цитата(XVR @ Nov 21 2011, 19:06)

А инфа пусть пропадает? Или все же с ней нужно что то сделать

На чем писать (и в каком виде) сильно зависит от того, что нужно сделать. Вариант с WEB браузером хорош тем, что пользователю не надо будет ставить никаких специальных программ, и обновлять их (если что) тоже не надо.
Браузер не подходит. Будет такая схема - девайс подключается по USB, прога через libusb его видит, выпрашивает у него логин/пароль и с ними лезет на сервер. Цепляет оттуда что нужно, заливает это в девайс и отлепляется от сервера
Цитата(toweroff @ Nov 21 2011, 19:16)

Будет такая схема - ...
Угу, а какой нибудь GUI вообще нужен? Или никаких действий со стороны пользователя не ожидается (ну кроме самого факта запуска программы)?
Если GUI не нужен, то проще будет сделать консольное приложение, а для доступа к WEB странице загрузки/сервлета использовать wininet.dll Получится очень маленькая и компактная утилитка
toweroff
Nov 22 2011, 21:36
Посмотрите и покритикуйте, пожалуйста, вот такой механизм на PHP
набросал только скелет
все ляпы потом отрехтуются, важен именно порядок действий и их правильность
Код
<?php
session_start();
$current_time = time();
if (isset($_SESSION['counter']))
{
if ($_SESSION['counter']>1)
{
if ((time() - $_SESSION['time'])<60)
{
echo "Too many attemps. Please wait 60secs";
exit;
}
else
{
$_SESSION['time'] = time();
$_SESSION['counter'] = 0;
}
}
}
if (!isset($_SESSION['user_id']))
if (isset($_POST['auth_name'])) {
// здесь коннектимся к базе, запрашиваем пользователя с нужными логином/паролем
// ...
$result = mysql_query($query, $link);
if ($row = mysql_fetch_array($result, MYSQL_ASSOC))
{
session_start();
$_SESSION['user_id'] = $row['id'];
$_SESSION['ip'] = $_SERVER['REMOTE_ADDR'];
$_SESSION['test_string'] = $row['test_string'];
$_SESSION['name'] = $row["name"];
echo "Logged in as ".$row['name']."; ".$row['test_string'];
show_data();
}
else
{
if (isset($_SESSION['counter']))
{
$_SESSION['counter']++;
echo "Try: ".$_SESSION['counter'];
}
else
{
$_SESSION['counter'] = 0;
$_SESSION['time'] = time();
echo "Flag: invalid\n";
}
}
mysql_free_result($result);
mysql_close($link);
exit;
}
if (isset($_GET['action']) AND $_GET["action"]=="logout") {
session_start();
session_destroy();
echo "Flag: closed";
exit;
}
if (isset($_REQUEST[session_name()])) session_start();
if (isset($_SESSION['user_id']) AND $_SESSION['ip'] == $_SERVER['REMOTE_ADDR'])
{
echo "Flag: OK\n";
echo "Already logged as ".$_SESSION['name']."; ".$_SESSION['test_string'];
show_data();
exit;
}
else
{
session_start();
echo "Flag: autentification";
?>
<form method="POST">
<input type="text" name="auth_name"><br>
<input type="password" name="auth_pass"><br>
<input type="submit"><br>
</form>
<?php
}
exit;
?>
есть подозрение, что по action=logout нужно тоже проверять, были ли залогинены (то есть в сессии присутствует "id")
Цитата(XVR @ Nov 22 2011, 10:20)

Угу, а какой нибудь GUI вообще нужен? Или никаких действий со стороны пользователя не ожидается (ну кроме самого факта запуска программы)?
гуй будет, форма с кнопочками и логом
От юзверя действия, конечно, будут нужны - да/нет там всякие. Но в передаваемые данные он не вмешивается
С PHP не работал, но на первый взгляд все Ок. Есть только сомнение по поводу привязки к IP - если пользователь работает через proxy или из локальной сети без видимого снаружи IP, то все такие пользователи будут идти через один и тот же IP
Еще подозрительно выглядит session_start() в самом начале скрипта, но тут я не уверен, т.к. не в курсе, как в PHP устроена работа с сессиями
toweroff
Nov 23 2011, 14:45
а вот еще одна мысль...
1. Логин и пароль передаются в URL
2. А есть смысл тогда вообще сессию создавать?
3. Как сделать защиту от "долбежки" логинов/паролей? Тут нарисовался один алгоритм - если не залогинились, сохраняем в базу IP, счетчик и время. Если "долбились" чаще, чем нужно, так вообще не допускать до проверки логина/пароля, сразу отшибать, пусть ждут некоторое время
Цитата(toweroff @ Nov 23 2011, 18:45)

1. Логин и пароль передаются в URL
2. А есть смысл тогда вообще сессию создавать?
А это уж вам виднее. Смотря что вы собираетесь делать после входа в систему. Если просто отправить обратно пользователю файл и выйти, то очевидно сессию создавать не надо.
Цитата
3. Как сделать защиту от "долбежки" логинов/паролей? Тут нарисовался один алгоритм - если не залогинились, сохраняем в базу IP, счетчик и время. Если "долбились" чаще, чем нужно, так вообще не допускать до проверки логина/пароля, сразу отшибать, пусть ждут некоторое время
Вполне нормально
toweroff
Nov 23 2011, 15:36
XVR, спасибо за советы
наверное, остановлюсь на этом варианте.
Еще один вопрос остался, наверное...
Логины и пароли для каждого девайса будут генериться при производстве и заноситься в базу. Фактически, пользователь их знать не будет (спорно, конечно, все можно подсмотреть по трафику, но напрямую пользователю они передаваться не будут). Абсолютно случайные наборы символов
Есть смысл в базе хранить не пароли, а хэши (возможно, "подсоленые")?
Цитата(toweroff @ Nov 23 2011, 19:36)

Есть смысл в базе хранить не пароли, а хэши (возможно, "подсоленые")?
Зависит от степени необходимой защиты этих самых паролей. Plain Text - защита отсутствует, Хэши - средняя степень защиты, криптография (например
Диффи-Хеллман +
IDEA) - высшая степень защиты
Для просмотра полной версии этой страницы, пожалуйста,
пройдите по ссылке.