Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, cadet354, Вы писали:

C>>Здравствуйте, gandjustas, Вы писали:

G>>>Скорости чего? А причем тут чтение с диска?
C>>для сравнения, что раундрип до сервера с ссесией это быстро.
G>Быстро по сравнению с чем?
по сравнению со считываем информации с локального диска.
G> Откуда ты чтение с диска взял? В аутентификационной куке передается вся необходимая информация, дополнительно никуда обращаться не надо.
вот я и клоню к этому, что экономия на спичках.

C>>>>>>стаковерфлоу
G>>>>>Он кстати использует куки, а не сессию.
C>>>>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь.
G>>>А причем тут пользовательская информация? я про аутентификацию говорю
C>>еще раз, я задал вопрос, что храниться в строке вида, т.к. в моей практике я с этим не сталкивался (делал вручную, без использования Membership и прочего стандартного набора)
C>>

C>> .ASPXAUTH=6E33EDE68296CCF4AAAEB1EC84586F346B221991DC2F3A03545B666E9F32E22CAD6A7EE2A19C5438C57A7B4DB447BDBBD18562E679DAFA50E610D832772722AD64DC0726196121451796D9407FB257EF

C>>sunshine ответил
C>>

C>>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.

C>>я выразил сомнение в целесообразности хранения имени пользователя и других пользовательских данных в куках, т.к. на практике это может расшифровываться в разумное время.
G>Время расшифровывания не зависит от того какие данные хранятся.
это понятно.

Здравствуйте, gandjustas, Вы писали:

G>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей.

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

Вы предлагаете так все и оставить, не менять модель безопасности .Net?

Лично я всегда хранил в кукисах: ID пользователя + 32 байтных случайных ключ. Все! Остальная изформация из базы данных + кеширование на сервере. Кукисы только для https. Всегда знал что стандартная система ни к черту: ну студент какой придумал (или человек просто не выспался) а остальные не обратили внимания.

G>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.

Это, молодой человек, называется экономия на спичках. Если у вас несколько серверов -- продумайте грамотно взаимодействие.

Здравствуйте, 0K, Вы писали:

0K>Здравствуйте, gandjustas, Вы писали:

G>>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей.

0K>И вы что, серьезно предлагаете хранить всю эту информацию в кукисах ради якобы снижения нагрузки на сервер?
Она и так хранится, для этого пару настроек в web.config надо сделать.

0K>Вы предлагаете так все и оставить, не менять модель безопасности .Net?
Модель отлично работает, реализация подкачала.
Это именно баг реализации что злоумышенник может определить правильно ли расшифровалась кука или нет.

0K>Лично я всегда хранил в кукисах: ID пользователя + 32 байтных случайных ключ. Все! Остальная изформация из базы данных + кеширование на сервере. Кукисы только для https. Всегда знал что стандартная система ни к черту: ну студент какой придумал (или человек просто не выспался) а остальные не обратили внимания.
Да ты у нас самый умный, мы это прекрасно знаем.

HTTPS кстати никак не помогает против такой атаки

G>>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.
0K>Это, молодой человек, называется экономия на спичках. Если у вас несколько серверов -- продумайте грамотно взаимодействие.
так уже продумали — не использовать сессию, я об этом и говорю.

Здравствуйте, 0K, Вы писали:

0K>Лично я всегда хранил в кукисах: ID пользователя + 32 байтных случайных ключ. Все! Остальная изформация из базы данных + кеширование на сервере.
Кстати хороший пример.

Вот у тебя в кеше лежат данные чтобы показать страницу, но на каждой странице надо вывести имя пользователя (не логин). Условия все те же: ферма.

1)Бегать за ними на сервер — неэффективно, снижает пропускную способность.
2)Держать в кеше — тоже не очень полезно, если человек зайдет ровно один раз, кроме того кеширование в ферме также требует включения мозга.
3)Сессия — вообще ужас, см выше.

А вот передавать вместе с кукой — идеально (имхо).

Здравствуйте, gandjustas, Вы писали:

0K>>Вы предлагаете так все и оставить, не менять модель безопасности .Net?
G>Модель отлично работает, реализация подкачала.

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

G>Это именно баг реализации что злоумышенник может определить правильно ли расшифровалась кука или нет.

Сколько еще багов реализации осталось конкретно в этой, отлично работающей модели?

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, gandjustas, Вы писали:

0K>>>Вы предлагаете так все и оставить, не менять модель безопасности .Net?
G>>Модель отлично работает, реализация подкачала.

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

Прошу пардона, двух, конечно же

Здравствуйте, kochetkov.vladimir, Вы писали:

KV>Здравствуйте, gandjustas, Вы писали:

0K>>>Вы предлагаете так все и оставить, не менять модель безопасности .Net?
G>>Модель отлично работает, реализация подкачала.

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

Насколько я понимаю любая система безопасности сильна настолько насколько сильно её самое слабое звено.

G>>Это именно баг реализации что злоумышенник может определить правильно ли расшифровалась кука или нет.
KV>Сколько еще багов реализации осталось конкретно в этой, отлично работающей модели?
Ну серьезный нашли пока только один, и то довольно легко исправимый.

Здравствуйте, cadet354, Вы писали:

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

так тебе и говорят что кука _не_ читается с диска

Здравствуйте, gandjustas, Вы писали:

G>Ну серьезный нашли пока только один, и то довольно легко исправимый.
уже прошло больше 12 дней,update все нет, под степень "довольно легко исправимый" не попадает.

Здравствуйте, mogadanez, Вы писали:

M>так тебе и говорят что кука _не_ читается с диска
я _это_ знаю, я не утверждал _что_ кука читается с диска, пример со временем чтения с локального диска я привел для сравнения скорости.