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

← →
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]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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