Где лучше хранить пароли пользователей для доступа к программе?

← →
Vlad © (2004-02-17 17:06) [40]

> С табличкой "Крутая непробиваемая защита на файл-серверной
> технологии"

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

← →
Vlad © (2004-02-17 17:06) [41]

← →
Reindeer Moss Eater © (2004-02-17 17:08) [42]

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

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

← →
Vlad © (2004-02-17 17:12) [43]

> Reindeer Moss Eater © (17.02.04 17:08) [42]
> А я еще раз говорю, что нет никакого смысла шифровать пароли
> при файл-серверной технологии.

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

← →
Anatoly Podgoretsky © (2004-02-17 17:13) [44]

Пароли вообще шифровать нет смысла, при любой технологии, зачем чтобы из вскрыли?

← →
VLAD-MAL (2004-02-17 17:15) [45]

wHammer © (17.02.04 15:50) [29]
Всех понял, спасибо за помощь.
Смотрит человек со стороны, и умиляется, как люди о нем заботятся...

← →
Vlad © (2004-02-17 17:18) [46]

> Anatoly Podgoretsky © (17.02.04 17:13) [44]

Уходя из дома не стоит запирать дверь на ключ. Все равно, тот кому надо - откроет :-)

← →
Reindeer Moss Eater © (2004-02-17 17:19) [47]

Кстати, так и не получил разумного решения этой задачи для обычного юзера.

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

Если он открыл таблицу с учетными записями и увидел там открытый пароль, значит он может это проделать со всеми таблицами.
Если он этого не сумел, мы напрасно шифровали пароль.
Далее.
Что бы убрать свои следы из системы он может просто удалить файл лога, заменить его принесенным из дома, или испортить его содержимое. Впрочем это мало относится к теме ветки.

Я в 19 посте сказал, что смысла в шифровании нет. И его нет на самом деле.

← →
Anatoly Podgoretsky © (2004-02-17 17:23) [48]

Vlad © (17.02.04 17:18) [46]
Очень просто нет двери, не чего открывать. Про сигнаттуры, ака хеш несколько раз сказали. А ты предлагаешь ключ под коврик положить.

← →
Vlad © (2004-02-17 17:36) [49]

> Anatoly Podgoretsky © (17.02.04 17:23) [48]

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

← →
Reindeer Moss Eater © (2004-02-17 17:42) [50]

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

Ну где смысл?
Свой пароль он знает.
Открывает таблицу пользователей.
Делает апдейт любого юзера, присваивая ему свой пароль из таблицы (зашифрован он там или открыт - нет разницы).
Все.
У него есть логин/пароль любого юзера.

← →
Reindeer Moss Eater © (2004-02-17 17:44) [51]

Что вы говорите?
Он не умеет открывать таблицы и делать апдейты, ибо он - бухгалтер?
Так он тогда не увидит незашифрованные пароли в таблице.

Зачем их шифровать?

← →
Vlad © (2004-02-17 17:46) [52]

> Reindeer Moss Eater © (17.02.04 17:42) [50]

А это уже касается методов шифрования. Кто мешает зашифровать так чтоб криптованый пароль от одного пользователя при простой перестановке не работал для другого ?

← →
stud © (2004-02-17 17:47) [53]

> Если он открыл таблицу с учетными записями и увидел там
> открытый пароль, значит он может это проделать со всеми
> таблицами.
> Если он этого не сумел, мы напрасно шифровали пароль.
> Далее.
> Что бы убрать свои следы из системы он может просто удалить
> файл лога, заменить его принесенным из дома, или испортить
> его содержимое. Впрочем это мало относится к теме ветки.

от таких юзеров шифрованные пароли или какие еще не слушком надежная защита.
защита должна соответствовать уровню взломщиков. а от бухгалтера можно закрыть базу грозным рыком ))

← →
Vlad © (2004-02-17 17:52) [54]

> Так он тогда не увидит незашифрованные пароли в таблице.

Поиск по ключевым словам обычный юзер делать не умеет ? :-)
Ладно, по второму кругу начинаем разговор, бред уже пошел.
Я вынужден бежать домой.
Reindeer Moss Eater, не относись слишком серьезно к спору, нервы дороже :-)

← →
Reindeer Moss Eater © (2004-02-18 14:15) [55]

Кто мешает зашифровать так чтоб криптованый пароль от одного пользователя при простой перестановке не работал для другого ?

Никто не мешает.
Так же как никто не мешает поменять у атакуемой учетной записи не только пароль, но и имя.
Логон в программу будет с родными именем и паролем, а в лог полетят ID главбуха.

Или просто заменить ID своей учетной записи в таблице пользователей работая с ней как с двоичным файлом.

← →
Val © (2004-02-18 14:22) [56]

>Vlad © (17.02.04 15:01) [13]
скажите, а что вас смутило в возможномти подмены таблицы?

← →
Mike_Goblin © (2004-02-18 21:53) [57]

Лучше всего хранить пароли и имена в отдельной таблице с именем USERS в открытом виде. Как это сделали на моей новой работе. После того как за 20 секунд я поднял свои привилегии в программе на максимальный уровень народ задумался. И стал писать туда хеш. Помогло еще минут на 5. Потому как поле с хешем доступно на update. Тогда народ написал хранимую процедуру
обрабатывающую подключение. Через 3 минуты я опять стал админом системы, потому что для вызова процедуры программа делала коннект к базе с логином админа и его паролем.

Вывод из этой истории:
Настоящие программисты пишут аутентификацию пользователей сами (которую потом довольно просто сломать), а всякие там ламеры пользуются стандартными средствами аутентификации сервера и нигде не хранят пароли.

← →
dr Tr0jan © (2004-02-19 06:50) [58]

Поэтому и компоненты надо свои писать, а не у кого-то тырить!

← →
Danilka © (2004-02-19 07:53) [59]

Ключевая фраза: "нигде не хранят пароли".
Кто так не считает - когда-нибудь получит пинок по мягкому месту.

Вломать пароль - дело времени,
так что я тебе советую не заморачиватся
с местом хранения, может в папке с программой
и хранить, например myprog.db, главное зашифровать
хорошенько.

← →
N169 (2004-02-19 10:32) [62]

Необязательно хранить пароль, даже в зашифрованном виде.
Можно делать так: на основе пароля формировать псевдослучайную последовательность, брать из неё кусок и считать его контрольную сумму (md5, например).
Её можно хранить хоть где.
При сравнении паролей проделывать ту же операцию и сравнивать контрольную сумму старого пароля и нового.
Ввиду сложности алгоритма, юзер подделать пароль не сможет.
Для юзеров (не хакеров, не крякеров!) такая защита в самый раз.

[62] N169 (19.02.04 10:32)
почитай, плиз, ветку :))

Такая защита убираецца за пару минут: зная контрольную сумму своего пароля, пишешь его любому юзверю и логинишся с его именем и своим паролем.

← →
N169 (2004-02-19 10:52) [64]

Я предлагал вычислять КСМ не пароля, а ПСП, построенной на основе пароля.
Если в алгоритм формирования ПСП привнести параметры, специфичные для конкретного компа (s/n физического диска, например, номер секретного guid-а в реестре и т.д.), то подобрать не получится.
Смотрите глубже! :)

>Reindeer Moss Eater © (17.02.04 17:08) [42]
>А я еще раз говорю, что нет никакого смысла шифровать пароли >при файл-серверной технологии.
Пароли шифровать смыс есть, нет смысла этим злоупотреблять. :))
Шифровать нужно не пароли по одиночке, а всю таблицу как файл. А в самой таблице хранить их можно и открыто. Только делать расшифровку в памяти, а не на винте.
В данные напрямую пользователь не полезет - сложная система всегда имеет кучу служебных поле плюс индексы, которые рухнут.

← →
Sirgfine (2004-02-27 04:21) [66]

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

Сергей Суровцев ©

Нет никакого смысла. Нет нет и нет.
Еще раз и на пальцах:

Q. Почему хочется шифровать пароли?
A. Потому что боимся пользователя, могущего посмотреть содержимое таблицы аккаунтов с помощью sqlexplorer.exe.
Потому что он узнает чужой пароль и получит в программе доступ к данным, к которым не должен иметь доступ

Q. Если такой пользователь нашелся, то что ему мешает иметь доступ к данным (к которым он доступа иметь не должен) с помощью того же sqlexplorer.exe?
A. Ничто не мешает.

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

Q. А стоило ли вообще шифровать пароли, если пользователь, от которого мы пытаемся защититься, ВООБЩЕ НА ПАРОЛИ НЕ СМОТРИТ?
A. Конечно же не стоило.

Где лучше хранить пароли пользователей для доступа к программе? Найти похожие ветки