Форум программистов «Весельчак У»
  *
Добро пожаловать, Гость. Пожалуйста, войдите или зарегистрируйтесь.
Вам не пришло письмо с кодом активации?

  • Рекомендуем проверить настройки временной зоны в вашем профиле (страница "Внешний вид форума", пункт "Часовой пояс:").
  • У нас больше нет рассылок. Если вам приходят письма от наших бывших рассылок mail.ru и subscribe.ru, то знайте, что это не мы рассылаем.
   Начало  
Наши сайты
Помощь Поиск Календарь Почта Войти Регистрация  
 
Страниц: [1]   Вниз
  Печать  
Автор Тема: Защита соединения к базе данных  (Прочитано 9968 раз)
0 Пользователей и 7 Гостей смотрят эту тему.
SCRIBE
Гость
« : 03-08-2016 06:34 » 

Всем привет господа.

Тут у меня появился рабочий вопрос, пока не нагуглил ничего толкового.
Есть клиентское приложение, оно подключается к удаленной базе на каком-то сервере, для подключения естественно нужен логин и пароль.
Как его не отдать на съедение людям сующим всюду свой нос?))
Замысел сделать аутентификацию через эту базу, в смысле на ней уже хранятся все логины и пароли, а для самого подключения к базе используется всего один такой, системный какой-то.
Нехороший человек же зайдет на базу, и вуаля, все как на ладоне, нехорошо  Улыбаюсь
Надо как-то скрыть/зашифровать это дело.

Буду рад за любую помощь.
Записан
Sla
Команда клуба

ua
Offline Offline
Пол: Мужской

WWW
« Ответ #1 : 03-08-2016 07:19 » 

SSL тунели
Записан

Мы все учились понемногу... Чему-нибудь и как-нибудь.
SCRIBE
Гость
« Ответ #2 : 03-08-2016 10:02 » 

Пробежался я поверхностно по этому SSL, для подключения используются сертификаты в виде файлов, что мешает другому человеку использовать эти же файлы для подключения из другого приложения?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #3 : 03-08-2016 10:23 » new

Удаленная база - худшее, что можно придумать. Сделай сервис авторизации. SSL нужен только для защиты трафика.
Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
SCRIBE
Гость
« Ответ #4 : 03-08-2016 10:33 » 

Сервис авторизации типа запросы к серверу (допустим PHP)? Который сам уже подключится к базе и проверит логин с паролем?
Записан
RXL
Технический
Администратор

ru
Offline Offline
Пол: Мужской

WWW
« Ответ #5 : 03-08-2016 15:00 » 

Да.
Более того, можно вместо пароля передавать результат некой хеш-функции с его участием, на серверной стороне повторять хеширование и сравнивать уже хеши. Это безопаснее.
Если в начале сессии сервер авторизации задаст еще рандомную одноразовую последовательность для хеширования, то хеш-пароль будет еще более надежен.
« Последнее редактирование: 03-08-2016 15:01 от RXL » Записан

... мы преодолеваем эту трудность без синтеза распределенных прототипов. (с) Жуков М.С.
SCRIBE
Гость
« Ответ #6 : 04-08-2016 11:44 » 

Cпасибо за помощь, так и сделаю, а то выдернуть строку подключения из программы минутное дело.
Записан
x77
Модератор

ro
Offline Offline
Пол: Мужской
меняю стакан шмали на обратный билет с Марса.


« Ответ #7 : 24-08-2016 17:17 » 

любая вменяемая защита может быть построена только на принципе "отторжения" ключа, т.е. пароли никогда не хранятся в программе. и вообще нигде не хранятся. но есть ситуации, когда надо получить доступ к БД до авторизации, например, в окне логина мы хотим получить список пользователей _до_, собственно, их авторизации в БД. пользователь выбирает себя в списке и вводит свой пароль. вот для таких целей используется разделение прав доступа на уровне СУБД. делается, например, "гостевой" пользователь, который имеет право вызвать одну единственную хранимую процедуру. эта процедура возвращает список пользователей. в программу "вшиваются" пароли для гостевого юзера, и даже если юный кулхацкер эти пароли найдет - флаг ему в руки, в лучшем случае он сможет получить список пользователей. а для реальной авторизации по-прежнему будет нужен введенный руками пароль/хэш/pgp-ключ/et cetera.

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

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

зы. ну а для "автоматических" логинов - однозначно PGP-ключи. огромный их бонус по сравнению со всем прочим - это то, что юзер сам не знает свой пароль. и их без проблем можно привязывать и к IP, и к mac-адресу, и к чему угодно, так что даже если некий гипотетический джедай их спер - если он не спер и весь компьютер "правильного" пользователя заодно, и не подключился из того же сегмента сети - ему это не поможет. круче этого только двух-фазная авторизация по паролю на смс/почту. т.к. емэйл, как и номер телефона - уникальный идентификатор, и в этом случае злоумышленнику придется спереть еще и их, до кучи.
« Последнее редактирование: 24-08-2016 18:35 от x77 » Записан

Страниц: [1]   Вверх
  Печать  
 

Powered by SMF 1.1.21 | SMF © 2015, Simple Machines