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

← →
wHammer © (2004-02-17 14:48) [0]

???

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

Там где темнее

← →
Незнающий (2004-02-17 14:50) [2]

Тогда где оное темное место?

← →
Fay © (2004-02-17 14:51) [3]

Нигде и никогда.

← →
VLAD-MAL (2004-02-17 14:51) [4]

Скорее всего, в зашифрованном виде, где угодно. Юзер вводит открытый пароль, тот шифруется и сравнивается с зашифрованным образцом.

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

Например в сейфе

← →
VLAD-MAL (2004-02-17 14:52) [6]

Скорее всего, в зашифрованном виде, где угодно. Юзер вводит открытый пароль, тот шифруется и сравнивается с зашифрованным образцом. - так, например, в InterBase/FireBird делается.

← →
Fay © (2004-02-17 14:54) [7]

В зашифрованном сейфе! Вводимый пароль тоже класть в сейф, шифровать и сравнивать с образцом зашифрованного_пароля_в_сейфе.
8)

← →
VLAD-MAL (2004-02-17 14:55) [8]

Удалено модератором

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

Вопрос странноватый.

1. Купили программу, кторая требует ввода пароля. Где его хранить? В темном шкафу конечно же!

2. Написали свою программу, которая спрашивает пароли у входящих. Где хранить пароли? Да там же где и базу учетных записей пользователей хранишь!

← →
wHammer © (2004-02-17 14:57) [10]

Можно-ли хранить зашифрованные пароли в отдельном поле таблицы "пользователи"? Не во что это не выльется в дальнейшем?

← →
VLAD-MAL (2004-02-17 14:59) [11]

Можно-ли хранить зашифрованные пароли в отдельном поле таблицы "пользователи"? Не во что это не выльется в дальнейшем? - ага, а прочитать, что тебе ответили, никак?

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

← →
Reindeer Moss Eater © (2004-02-17 15:00) [12]

Не во что это не выльется в дальнейшем?

В дальнейшем это может вылиться в dbase, text, doc, xsl, Paradox etc...

← →
Vlad © (2004-02-17 15:01) [13]

> VLAD-MAL (17.02.04 14:59) [11]

Расскажи, каким образом юзер может подменить таблицу (не файл БД) а именно таблицу !? :-)

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

Удалено модератором
Примечание: Offtopic

← →
SergSuper (2004-02-17 15:06) [15]

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

← →
Vlad © (2004-02-17 15:09) [16]

> VLAD-MAL (17.02.04 15:05) [14]

если это мне, то флейм тут не причем, я действительно считаю что в способе хранения паролей [10] ничего страшного нету

> SergSuper (17.02.04 15:06) [15]

А функция от пароля - это и есть пароль в зашифрованном виде.

← →
wHammer © (2004-02-17 15:09) [17]

> SergSuper (17.02.04 15:06) [15]
> Обычно пароли и не хранятся, а храниться некая функция от
> пароля, да такая что по ней трудно подобрать соответствующий
> пароль. При запросе пароля проверяется значение этой функции
> и сравнивается с запомненным

Если не затруднит, можно поподробнее...

← →
wHammer © (2004-02-17 15:10) [18]

> А функция от пароля - это и есть пароль в зашифрованном
> виде.

Если так, тогда все ясно.

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

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

← →
Nikolay M. © (2004-02-17 15:19) [20]

> wHammer © (17.02.04 15:10) [18]
> > А функция от пароля - это и есть пароль в зашифрованном
> > виде.
> Если так, тогда все ясно.

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

← →
Vlad © (2004-02-17 15:25) [21]

> Reindeer Moss Eater © (17.02.04 15:15) [19]
> Если к примеру для для файл-серверной БД, то правильнее
> хранить пароли вообще в открытом виде и не делать себе

Почему ? Какая разница в данном случае, файл серверная БД или клиент-серверная ?

← →
Reindeer Moss Eater © (2004-02-17 15:26) [22]

Vlad ©
Потому что есть физический доступ к файлу БД

← →
wHammer © (2004-02-17 15:27) [23]

> Reindeer Moss Eater © (17.02.04 15:15) [19]
> Ты бы сначала рассказал, для какой системы все это придумывается.
> Если к примеру для для файл-серверной БД, то правильнее
> хранить пароли вообще в открытом виде и не делать себе трудностей
> с шифрованием и т.д.

Система именно файл-серверная (Paradox), только если без шифрования, то пользователь может "вручную" открыть таблицу пользователей и узнать то, чего не надо.

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

Ну, вопрос уже решен, не так ли?
Подбери подходящую хэш-функцию - и - вперед!.

← →
Reindeer Moss Eater © (2004-02-17 15:30) [25]

Система именно файл-серверная (Paradox), только если без шифрования, то пользователь может "вручную" открыть таблицу пользователей и узнать то, чего не надо.

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

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

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

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

Reindeer Moss Eater © (17.02.04 15:30) [25]

Да, мощно ты всх задвинул...

← →
Reindeer Moss Eater © (2004-02-17 15:45) [28]

Допустим программа пишет логи,

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

← →
wHammer © (2004-02-17 15:50) [29]

Всех понял, спасибо за помощь.

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

> Reindeer Moss Eater © (17.02.04 15:45) [28]
> Что помешает мне писать/читать/удалять записи лога не пользуясь
> программой автора вопроса?

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

← →
Reindeer Moss Eater © (2004-02-17 15:59) [31]

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

Ты будешь наверное страшно удивлен, но поиск по миллионам файлов содержащих некоторые ключевые слова - это задача для компьютера, потому как он железный, а не для меня.
И решение этой задачи отнимет у компьютера N минут M секунд.

← →
Vlad © (2004-02-17 16:11) [32]

> Reindeer Moss Eater © (17.02.04 15:59) [31]

простой пример.
Допустим юзер собрался чего-то умышленно напортачить в своей программе. Для этого ему нужно: либо зайти под чужим паролем, либо зайти под своим, но потом затереть инфу из файла-лога.
Пытается узнать пароль - облом. Он зашифрован. Пытается найти файл лога (запускает поиск по ключевым словам) - опять ничего - лог пишется в двоичном формате (типа *.cds (TClientDataSet)) или в другом формате, не хранящему данные в виде текста.
Так как же решить эту задачу обычному юзеру ?

← →
Reindeer Moss Eater © (2004-02-17 16:21) [33]

Так как же решить эту задачу обычному юзеру ?

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

Если это возможно, то что помешает ему открыть таблицу окладов или контрактов?
Ах она тоже в двоичном виде клиент-датасета и нихрена не видна?

Стоп! Тогда ему и пароль, ничем не зашифрованный, а хранимый в двоичном пакете клиентдатасета недоступен для чтения.

Вопрос по новой: ну и нахрена шифровать его? Для практикума в использовании алгоритмов?

← →
Vlad © (2004-02-17 16:35) [34]

> Reindeer Moss Eater © (17.02.04 16:21) [33]

Я не то имел ввиду.
База - DBF. Открывается простым Excel"ем, все данные на ладони, но вот одно "но". Сделать юзер с ними ничего не может. Увидит набор таблиц, кучу идентификаторов, плюс кое-какую разрозненную информацию.
А ему, допустим, нужно платеж левый сделать, проводочки провести и прочее хозяйство. Естественно руками он это не сделает, т.к. не поймет что и куда нужно записать, какие ID куда расставить. Остается один выход - делать из программы. А она, хитрая, лог пишет, в нечитабельном формате и неизвестно в какой файл. И что ему делать ?

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

Естественно руками он это не сделает, т.к. не поймет что и куда нужно записать, какие ID куда расставить.

Это почему он это не сделает? Потому что кому-то так кажется?
А почему тогда кому-то этому кажется, что он ёкселем откроет базу пользователей и догонит где там пароль лежит?

Остается один выход - делать из программы.

Да не один, а один миллион.
Например на домашней копии программы. С известным собственным паролем и последующей перезаписью таблицы документов на рабочую базу.

А она, хитрая, лог пишет, в нечитабельном формате и неизвестно в какой файл. И что ему делать ?

На каждого такого мудреца есть вагон и маленькая тележка простоты. Лог он полезен когда он есть. А когда его нет, он бесполезен.
Файл лога доступен как минимум для записи как максимум - мы его просто удаляем, если можно только писать - пишем в него фразу "Hello World" и все

← →
Reindeer Moss Eater © (2004-02-17 16:48) [36]

И еще раз вопрос:

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

От кого эта мера, если она не нужна в случае юзера описанного тобой, и не спасает от юзера не пользующегося программой?
Мера предосторожности от марсиан?

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

> Это почему он это не сделает? Потому что кому-то так кажется?

Потому что он - бухгалтер на фирме, а не программист БД.

> А почему тогда кому-то этому кажется, что он ёкселем откроет
> базу пользователей и догонит где там пароль лежит?

Сам говоришь, поиск по ключевым словам (если пароль не зашифрован - то найдет)

> Например на домашней копии программы.

Опять облом, дистрибутива нет... БДЕ алиасы не настроены и прочее.

> Файл лога доступен как минимум для записи как максимум -
> мы его просто удаляем

Так как же его найти-то этот файл, если данные в нем в нечитабельном формате и сам он неизвестно где ?

← →
Reindeer Moss Eater © (2004-02-17 16:59) [38]

Потому что он - бухгалтер на фирме, а не программист БД.

И все таки еще раз: зачем от него шифровать пароли?

Сам говоришь, поиск по ключевым словам (если пароль не зашифрован - то найдет)

Я сказал, что пароль он искать не будет. Он будет искать таблицы с нужными ему данными. Помимо программы, которая ограничивает ему доступ к эти данным.

> Например на домашней копии программы.
Опять облом, дистрибутива нет... БДЕ алиасы не настроены и прочее.

Все файлы нужные программе лежат на томах доступных этому пользователю. Так что никакого облома не будет.
Про алиасы вообще молчу - лепет детский.

Так как же его найти-то этот файл, если данные в нем в нечитабельном формате и сам он неизвестно где ?

Поиск по дате последней модификации слыхал?
Захожу штатно в прогу со своим паролем и выхожу. Захожу и выхожу, захожу и выхожу.
Намек ясен?

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

← →
Vlad © (2004-02-17 17:00) [39]

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

Вот это в принципе выход. Вполне хорошая "защита от дурака"

← →
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 посте сказал, что смысла в шифровании нет. И его нет на самом деле.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вломать пароль - дело времени,
так что я тебе советую не заморачиватся
с местом хранения, может в папке с программой
и хранить, например 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. Конечно же не стоило.

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