А вот как сделано: регистрируешься на каком-нибудь сайте,

← →
Ega23 © (2008-04-02 10:54) [0]

вводишь пароль и ответ на контрольный вопрос. Если забыл пароль - присылают вопрос, ответил - высылают пароль.
Собственно, вопрос: а как тогда этот пароль хранят? Не в открытом же виде...

← →
Kolan © (2008-04-02 10:55) [1]

> а как тогда этот пароль хранят? Не в открытом же виде&#133

В зашифрованом.

← →
Рамиль © (2008-04-02 10:58) [2]

В большинстве случаев высалают новый пароль. А старый это от лукавого.

← →
Ega23 © (2008-04-02 11:02) [3]

> В зашифрованом.
>

интересует алгоритм, который в обе стороны действует.

← →
Kolan © (2008-04-02 11:03) [4]

> интересует алгоритм, который в обе стороны действует.

xor :)

← →
Eraser © (2008-04-02 11:08) [5]

> Ega23 © (02.04.08 11:02) [3]

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

← →
Kolan © (2008-04-02 11:09) [6]

> лучше действительно не хранить пароль ни в каком виде

Это, а как тогда при входе проверять пароль?

← →
Eraser © (2008-04-02 11:09) [7]

> Kolan © (02.04.08 11:09) [6]

по хэшу

← →
tesseract © (2008-04-02 11:22) [8]

> Это, а как тогда при входе проверять пароль?

В *nix и windows тоже пароли не храняться. Везде хэши.

← →
Kolan © (2008-04-02 11:23) [9]

> по хэшу

Согласен, неподумал.

← →
Ega23 © (2008-04-02 11:31) [10]

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

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

← →
Kolan © (2008-04-02 11:34) [11]

> Вот сижу, мучуюсь&#133

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

← →
Оригинал (2008-04-02 11:34) [12]

> Мне права пользователей на определённые действия каким-то
> макаром шифровать надо.

Права пользователей на какие действия и в какой системе?

← →
DVM © (2008-04-02 11:35) [13]

> Если забыл пароль - присылают вопрос, ответил - высылают
> пароль.
> Собственно, вопрос: а как тогда этот пароль хранят? Не в
> открытом же виде...

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

← →
Ega23 © (2008-04-02 11:40) [14]

> Права пользователей на какие действия и в какой системе?

Ну, условно говоря, так:
есть таблица неких бизнес-действий (Просмотр такого-то отчета, модификация таких-то данных и т.п.). Есть аккаунты пользователей. Вот надо связать аккаунт с бизнес-действиями. При этом разрешено действие, или нет - должно хранится в зашифрованном виде.
Казалось бы самое очевидное - md5(пароль + код действия + true (или false)).
всё прохавается на ура. Только вот администратор тогда права пользователя никак увидеть не сможет... :)

← →
Kolan © (2008-04-02 11:44) [15]

> Только вот администратор тогда права пользователя никак
> увидеть не сможет&#133 :)

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

← →
Ega23 © (2008-04-02 11:49) [16]

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

Ещё раз: права пользователя на бизнес-действия являются секретной информацией. Т.е. сторонний человек, имея прямой доступ к БД, не должен узнать, разрешено ли юзеру с ID=18 бизнес-действие с кодом 55.

← →
tesseract © (2008-04-02 11:53) [17]

> Т.е. сторонний человек, имея прямой доступ к БД, не должен
> узнать, разрешено ли юзеру с ID=18 бизнес-действие с кодом
> 55.

Ну так шифруй. RC4 например - достаточно шустрый алгоритм.

← →
Kolan © (2008-04-02 11:54) [18]

> сторонний человек
>md5(пароль + код действия + true (или false)).

А, тут скобочки на все.

← →
Alien1769 © (2008-04-02 11:55) [19]

> Ещё раз: права пользователя на бизнес-действия являются
> секретной информацией. Т.е. сторонний человек, имея прямой
> доступ к БД, не должен узнать, разрешено ли юзеру с ID=18
> бизнес-действие с кодом 55.

Так шифруй информацию пользователей по главному паролю создателя базы и все !

← →
Дмитрий С (2008-04-02 11:57) [20]

> Только вот администратор тогда права пользователя никак
> увидеть не сможет... :)

Администратор отснифить пароль может. А если еще ЭТО написано на PHP, то и изменить код кое где =)

А так ведь ты же придумал, в чем проблема то???

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

← →
Ega23 © (2008-04-02 12:00) [21]

> Кстати а как в твоем случае наградить пользователя правами
> не зная его пароля??

Дык в этом-то и проблема... :)

← →
Ega23 © (2008-04-02 12:01) [22]

Кстати, дело даже хуже. Практически любой пользователь должен иметь возможность посмотреть свои текущие права. Изменить - нет, а вот просмотр - пожалуйста.

← →
Оригинал (2008-04-02 12:02) [23]

> Т.е. сторонний человек, имея прямой доступ к БД, не должен
> узнать, разрешено ли юзеру с ID=18 бизнес-действие с кодом
> 55.

Перемешать по некоторому алгоритму строку с правами (например битовую маску прав). Права на расшифровку-прямое выполнение ХП должен иметь только администратор, выполнение ХП разрешено только из прикладного ПО.

← →
Kolan © (2008-04-02 12:02) [24]

> Кстати, дело даже хуже.

По сути это одно и тоже. Используя хеш ты не можешь восстановить назад все. А [17] неподходит?

← →
Оригинал (2008-04-02 12:04) [25]

Непонятно только, чего тут в трепе ветка делает-)

← →
Оригинал (2008-04-02 12:11) [26]

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

← →
Kolan © (2008-04-02 12:13) [27]

> Наверное даже проще можно сделать.

Так а как это спасет от прямого доступа к БД, когда я могу наплевать на ХП. Взять и поспотреть что там в таблице UserRight лежит?

← →
Ega23 © (2008-04-02 12:14) [28]

> Наверное даже проще можно сделать.
> Зашифрованная средствами БД ХП должна выдавать список прав
> только админу. Зарегистрированным пользователям - только
> список их прав.
> Тех, кто не зарегистрирован в БД для использования конкретных
> бизнес-процессов, вообще не получают информации.

Она тупо не спасёт от прямого селекта из таблицы прав.

← →
Оригинал (2008-04-02 12:14) [29]

> Kolan © (02.04.08 12:13) [27]
> > Наверное даже проще можно сделать.
>
> Так а как это спасет от прямого доступа к БД, когда я могу
> наплевать на ХП. Взять и поспотреть что там в таблице UserRight
> лежит?

Перемешать по некоторому алгоритму строку с правами (например битовую маску прав).

← →
Оригинал (2008-04-02 12:14) [30]

> Ega23 © (02.04.08 12:14) [28]
>
> > Наверное даже проще можно сделать.
> > Зашифрованная средствами БД ХП должна выдавать список
> прав
> > только админу. Зарегистрированным пользователям - только
>
> > список их прав.
> > Тех, кто не зарегистрирован в БД для использования конкретных
>
> > бизнес-процессов, вообще не получают информации.
>
>
> Она тупо не спасёт от прямого селекта из таблицы прав.

Перемешать по некоторому алгоритму строку с правами (например битовую маску прав).

← →
Оригинал (2008-04-02 12:15) [31]

Реальный список прав можно получить только через ХП.

> Перемешать по некоторому алгоритму строку с правами (например
> битовую маску прав).

Кстати да. Тогда создасться впечатление, что с правами ничего не делали, но все будет неправильно.

А функцию перемешивания я бы на клиенте сделал.

← →
Оригинал (2008-04-02 12:17) [33]

> А функцию перемешивания я бы на клиенте сделал.

Тогда алгоритм можно определить.

> Перемешать по некоторому алгоритму строку с правами (например
> битовую маску прав).

Шифрование через неясность порочно по своей сути.

Может сделать так:

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

Правда тут есть несколько тонких моментов, надо над ними подумать.

← →
Оригинал (2008-04-02 12:41) [35]

> Рамиль © (02.04.08 12:36) [34]
>
> > Перемешать по некоторому алгоритму строку с правами (например
>
> > битовую маску прав).
>
> Шифрование через неясность порочно по своей сути.

Вряд ли. Алгоритм перемешивания достаточно хранить в секрете и всё.
Не нужно усложнять жизнь. Лучше минимальная достаточность.

Интересно. Но есть проблема: под "администратором" я называю того пользователя (или группу пользователей), которым доступно бизнес-действие "изменение прав пользователей"

← →
Оригинал (2008-04-02 12:45) [37]

> Ega23 © (02.04.08 12:42) [36]
> Интересно. Но есть проблема: под "администратором" я называю
> того пользователя (или группу пользователей), которым доступно
> бизнес-действие "изменение прав пользователей"

Ну так если администраторы доолжны иметь доступ, надо им дать соответствующие права, включив в отдельную группу.

← →
Дмитрий С (2008-04-02 12:45) [38]

А если сделать так:

В таблицу аккаунтов добавляется еще два поля:
login_count - увеличивается при каждом входе пользователя
login_count_cs - вычисляется при каждом входе на основе пароля и поля login_count.

Таблица прав пользователей организована как ты сказал:
md5(account_id + right_id + password)

При добавлении какого либо права пользователю в таблицу прав добавляется запись:
md5(account_id + right_id + login_count_cs)

А при каждом входе клиентская часть ищет (перебором видимо придеться, надеюсь прав не так много=) ) все строки, которые соответствуют
md5(account_id + right_id + login_count_cs)
и переделывает их в формат
md5(account_id + right_id + password), зная, конечно пароль (А пароль пользователь только что ввел, для того чтобы войти).

Тем самым у администратора будет очень мало шансов, что либо узнать =)

Можно упростить схему...
Добавлять в таблицу записи вида
md5(account_id + right_id)
и также, при входе пользователя, конвертировать их.

> Ega23 © (02.04.08 12:42) [36]

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

> Вряд ли. Алгоритм перемешивания достаточно хранить в секрете
> и всё.
> Не нужно усложнять жизнь. Лучше минимальная достаточность.
>

Вот-вот. Также думают все правительственные структуры и корпорации :(

> Также думают все правительственные структуры и корпорации
> :(

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

А вот как сделано: регистрируешься на каком-нибудь сайте, Найти похожие ветки