В опщем следующая задача.
Нужно при запуске программы выводить окно в котором можно выбрать пользователя и ввести пароль.
Программа работает с БД.
Где хранить пароли?
Если в базе то к ней нужно подключение. И если зашивать подключение злоумышленик может каким нибудь образом продебажить и найти строку подключения в опщем дайте какие нибудь идеи как сделать нормальный вход в систему
22 апреля 2009 в 3:02
Эта – имеет и не одно
20 апреля 2009 в 21:03
задачу поставить можно
но не факт, что она имеет решение
14 апреля 2009 в 11:02
Хм…
1) Если сервер в ActiveDirectory то вполне реально выделить группу которой разрешен вход на MsSQL.
2) Полностью защитить от реверсера нельзя, но максимально затруднить – вполне возможно… тут даже не знаю что подсказать… полиморф + многопоточность + антиотладочные приемы.
3) Отправлять по сети в незашиврованном виде = самоубийство.
4) Можно написать сервис на том же серваке где стоит СУБД который будет хранить пароли/авторизовать юзеров и раздавать им права…
5) Кстате хранимая процедура это идея… только учетка должна разрешать доступ ТОЛЬКО к этой процедуре, и текст ее нужно хорошо проработать чтобы исключить sql-injection.
14 апреля 2009 в 3:00
спасибо большое ВСЕМ)))
14 апреля 2009 в 3:00
а субд MS SQL SERVER 2000
14 апреля 2009 в 1:02
2 Юрий Лисичкин
Какие заказчики? Какой анализ? Ты еще не авторизировался…
) Пока можешь токо почитать хэши паролей. 
13 апреля 2009 в 21:02
>> Например узнать точный список заказчиков и объем продаж компании >> конкурента, провести анализ и разработать свой план развития =)
Угу, берем учетку, все дефолтные права которой – дернуть нашу процедурку аутентификации. Если процедурка успешно пароль сверила, выдаем сессии роль с грантами на доступ к боевым объектам БД. Если не сверила, хоть обузнавайся, СУБД к данным не пустит.
13 апреля 2009 в 20:01
>> как можно насрать с правами на чтение?
Например узнать точный список заказчиков и объем продаж компании конкурента, провести анализ и разработать свой план развития =)
а ля гер ком а ля гер ( или как то так %) )
13 апреля 2009 в 18:05
как можно насрать с правами на чтение? и что, что он узнает хэш?
13 апреля 2009 в 16:05
Что за база?
А то если Oracle EE, то подобные задачи там решаются легко и непринужденно.
13 апреля 2009 в 16:04
На примере MS SQL Server..
Напишите хранимую процедуру проверки логина и пароля.
Создайте пользователя (на сервере) с правом выполнить только эту процедуру (разрешения на чтение информации у него нет). Далее выбрасывайте форму-логин, подключитесь к базе от имени этого (бесправного) пользователя и вызовите хранимую процедуру.Если всё хорошо – программе можно раздать роль приложения..
13 апреля 2009 в 14:02
А СУБД какая ?
13 апреля 2009 в 13:04
>> Доступ на чтение и на запись – совершенно разные вещи
Один хрен… "злоумышленнику" может вполне хватить чтения информации из базы данных…
в конце концов он же не школьник прыщавый, который дальше "поднасрать" не мыслит =)
13 апреля 2009 в 13:01
Доступ на чтение и на запись – совершенно разные вещи…
13 апреля 2009 в 10:01
ну чтобы вытянуть пароль из базы к ней уже нужно подключение
значит нада зашивать подключение
и даже если создать пользователя который буит иметь доступ только к таблице с паролями все равно как то шатковато.
А вдруг злоумышленниг вытянет строку подключения и получит доступ к таблице с паролями и удалит из нее все )
13 апреля 2009 в 10:00
пароль хранить например в БД, но не в чистом виде, а в зашиформаном. Например, пропустить сначала через SHA1, чтоб необратимый был, а потом через Base64, чтоб ужасно не выглядел ).
Далее при логине пользователя делать ту же операцию и сравнивать результат с тем, что хранится в базе.