Здравствуйте, gandjustas, Вы писали:
0K>>Вы предлагаете так все и оставить, не менять модель безопасности .Net? G>Модель отлично работает, реализация подкачала.
У этой модели есть один, но очень существенный недостаток: она создает зависимость безопасности всей системы (в части, касающейся аутентификации и авторизации) от качества реализации всего лишь одной криптографической функции. Получается куча яиц в одном лукошке, что увеличивает связанные с реализацией любой из актуальных для этой функции угроз риски до небес.
G>Это именно баг реализации что злоумышенник может определить правильно ли расшифровалась кука или нет.
Сколько еще багов реализации осталось конкретно в этой, отлично работающей модели?
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, cadet354, Вы писали:
C>>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>>просто хранить session_id
G>>>Накладные расходы в режиме фермы представляешь? C>>хранение одного ключа?
G>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей. G>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.
все хорошо в теории, только вот на практике оказалось хреново (причем как я понял таже проблема есть и у Оракла и т.д.) G>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети.
рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска G>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии.
в любом случае это происходит если ссесия храниться не в инпрок. G>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия.
для обычной куки можно делать аналогично.
на практике в любом случае надо будет лезть в сессию, получается сэкономили на одном раундрипе, получили потенциальную дыру в безопасности, которая сейчас получила реальное воплощение. (причем до фермы в 10 компов дай бог 1% приложений доходят, стаковерфлоу и до этого пока не дошел).
Re[9]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, gandjustas, Вы писали:
G>>>>Здравствуйте, cadet354, Вы писали:
C>>>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>>>просто хранить session_id
G>>>>Накладные расходы в режиме фермы представляешь? C>>>хранение одного ключа?
G>>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей. G>>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию. C>все хорошо в теории, только вот на практике оказалось хреново (причем как я понял таже проблема есть и у Оракла и т.д.)
Что ты имеешь ввиду?
G>>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети. C>рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска
А причем тут чтение с диска?
G>>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии. C>в любом случае это происходит если ссесия храниться не в инпрок. G>>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия. C>для обычной куки можно делать аналогично.
Какой обычной куки? Причем тут обычная кука?
C>на практике в любом случае надо будет лезть в сессию, получается сэкономили на одном раундрипе
на какой практике? На моей практике за 3 года ни одного обращения к session
C>получили потенциальную дыру в безопасности
Ну да, а с сессией проблем нету
Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да?
C>стаковерфлоу
Он кстати использует куки, а не сессию.
Re[10]: Cookies from ASP.NET servers can be cracked
G>Что ты имеешь ввиду?
Oracle Application Server http://www.pentestit.com/2010/06/08/poet-padding-oracle-exploit-tool/
G>>>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>>>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети. C>>рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска G>А причем тут чтение с диска?
сравнение скорости, что это не так много
G>>>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии. C>>в любом случае это происходит если ссесия храниться не в инпрок. G>>>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>>>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия. C>>для обычной куки можно делать аналогично. G>Какой обычной куки? Причем тут обычная кука?
а что ты считаешь авторизационной кукой?
C>>на практике в любом случае надо будет лезть в сессию, получается сэкономили на одном раундрипе G>на какой практике? На моей практике за 3 года ни одного обращения к session
да, я забыл, практика у всех разная C>>получили потенциальную дыру в безопасности G>Ну да, а с сессией проблем нету G>Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да?
зачем? httponly для всех кук работает C>>стаковерфлоу G>Он кстати использует куки, а не сессию.
откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[11]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
G>>>>В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server. G>>>>В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети. C>>>рандрип по сети (если инфа храниться в памяти),стоит дешевле чем чтение с локального диска G>>А причем тут чтение с диска? C>сравнение скорости, что это не так много
Скорости чего? А причем тут чтение с диска?
G>>>>Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии. C>>>в любом случае это происходит если ссесия храниться не в инпрок. G>>>>inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием). G>>>>Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия. C>>>для обычной куки можно делать аналогично. G>>Какой обычной куки? Причем тут обычная кука? C>а что ты считаешь авторизационной кукой?
"А почему вы отвечаете вопросом на вопрос?"
Мы сейчас говорим об аутентификации, а не о куках вообще.
C>>>получили потенциальную дыру в безопасности G>>Ну да, а с сессией проблем нету G>>Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да? C>зачем? httponly для всех кук работает а причем тут HTTP only?
C>>>стаковерфлоу G>>Он кстати использует куки, а не сессию. C>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь.
А причем тут пользовательская информация? я про аутентификацию говорю
In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
что значит decrypt cookies, я грешным делом думал, что
C> In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
C>что значит decrypt cookies, я грешным делом думал, что C>
C>> In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
C>>что значит decrypt cookies, я грешным делом думал, что C>>
C>>просто индефикатор, а тут получается зашифрованы пользовательские данные?
S>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
плохо,зачем было вообще это тащить на клиент?
P.S. интересно, а обратное действие тоже возможно (по имени пользователя на основе имеющийся cookie сгенерировать новый .ASPXAUTH)?
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[3]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, sunshine, Вы писали:
S>>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
C>плохо,зачем было вообще это тащить на клиент?
Непонятно — как иначе сделать авторизацию, если честно.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[5]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Непонятно — как иначе сделать авторизацию, если честно. C>просто хранить session_id
ID сессии хранится в другой куке.
[quote]The value is encrypted using the machine key (located in the server's machine.config or web.config file) so looking at the cookie on the client won't really provide you any information.[/quote]
Прошёл по твоей ссылке, товарищ ничего не написал — ни как взломали, ни что достали.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[6]: Cookies from ASP.NET servers can be cracked
Здравствуйте, Aen Sidhe, Вы писали:
AS>Прошёл по твоей ссылке, товарищ ничего не написал — ни как взломали, ни что достали.
согласен, но от этого не легче,
оказывается в asp.net 3.5sp1 / asp.net 4 есть возможность просмотреть web.config (пусть и зашифрованный), я так понял это как-то связано с роутингом. сообщение от scottgu взлом dnn
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[5]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, Aen Sidhe, Вы писали:
AS>>Непонятно — как иначе сделать авторизацию, если честно. C>просто хранить session_id
Накладные расходы в режиме фермы представляешь?
Re[6]: Cookies from ASP.NET servers can be cracked
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>Непонятно — как иначе сделать авторизацию, если честно. C>>просто хранить session_id
G>Накладные расходы в режиме фермы представляешь?
хранение одного ключа?
Re[7]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>просто хранить session_id
G>>Накладные расходы в режиме фермы представляешь? C>хранение одного ключа?
Синхронизация этого ключа.
С уважением, Анатолий Попов.
ICQ: 995-908
Re[7]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Здравствуйте, cadet354, Вы писали:
C>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>просто хранить session_id
G>>Накладные расходы в режиме фермы представляешь? C>хранение одного ключа?
Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей.
В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.
В случае сессии: inpocess ты её хранит не можешь ибо ферма. У тебя два варианта: SQL Server или State server.
В любом случае требуется сериализация-десериализация и блокировка на каждый запрос, кроме того round-trip по сети.
Все это складывается с тем что ты довольно хреново контролируешь время жизни сессии.
inproc и state-server сессии могут жить гораздо меньше времени жизни app pool_а, а сессия на SQL Server гораздо дольше (приходится ручками следить за устареванием).
Для авторизационной куки можно указывать sliding expiration, независящий от времени жизни app pool, можно делать фичу вроде "чужой компьютер" чтобы браузер не сохранял куку после закрытия.
C> In short, you can decrypt cookies, view states, form authentication tickets, membership password, user data, and anything else encrypted using the framework's API!
C>что значит decrypt cookies, я грешным делом думал, что C>
Здравствуйте, Aen Sidhe, Вы писали:
AS>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Здравствуйте, cadet354, Вы писали:
C>>>>Здравствуйте, Aen Sidhe, Вы писали:
AS>>>>>Непонятно — как иначе сделать авторизацию, если честно. C>>>>просто хранить session_id
G>>>Накладные расходы в режиме фермы представляешь? C>>хранение одного ключа?
AS>Синхронизация этого ключа.
в смысле синхронизация?
Re[9]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
G>>>>Накладные расходы в режиме фермы представляешь? C>>>хранение одного ключа?
AS>>Синхронизация этого ключа. C>в смысле синхронизация?
Здравствуйте, gandjustas, Вы писали:
G>Скорости чего? А причем тут чтение с диска?
для сравнения, что раундрип до сервера с ссесией это быстро.
C>>>>получили потенциальную дыру в безопасности G>>>Ну да, а с сессией проблем нету G>>>Заставь каждого пользователя специально жать "выход" перед закрытием браузера. Я так понимаю это вообще не проблема, да? C>>зачем? httponly для всех кук работает G> а причем тут HTTP only?
эт я сморозил, признаю, non-persistent это называется, HTTP only спасает от другого вида атак.
C>>>>стаковерфлоу G>>>Он кстати использует куки, а не сессию. C>>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь. G>А причем тут пользовательская информация? я про аутентификацию говорю
еще раз, я задал вопрос, что храниться в строке вида, т.к. в моей практике я с этим не сталкивался (делал вручную, без использования Membership и прочего стандартного набора)
Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
я выразил сомнение в целесообразности хранения имени пользователя и других пользовательских данных в куках, т.к. на практике это может расшифровываться в разумное время.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[13]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
G>>Скорости чего? А причем тут чтение с диска? C>для сравнения, что раундрип до сервера с ссесией это быстро.
Быстро по сравнению с чем? Откуда ты чтение с диска взял? В аутентификационной куке передается вся необходимая информация, дополнительно никуда обращаться не надо.
C>>>>>стаковерфлоу G>>>>Он кстати использует куки, а не сессию. C>>>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь. G>>А причем тут пользовательская информация? я про аутентификацию говорю C>еще раз, я задал вопрос, что храниться в строке вида, т.к. в моей практике я с этим не сталкивался (делал вручную, без использования Membership и прочего стандартного набора) C>
C>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
C>я выразил сомнение в целесообразности хранения имени пользователя и других пользовательских данных в куках, т.к. на практике это может расшифровываться в разумное время.
Время расшифровывания не зависит от того какие данные хранятся.
Re[14]: Cookies from ASP.NET servers can be cracked
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, cadet354, Вы писали:
C>>Здравствуйте, gandjustas, Вы писали:
G>>>Скорости чего? А причем тут чтение с диска? C>>для сравнения, что раундрип до сервера с ссесией это быстро. G>Быстро по сравнению с чем?
по сравнению со считываем информации с локального диска. G> Откуда ты чтение с диска взял? В аутентификационной куке передается вся необходимая информация, дополнительно никуда обращаться не надо.
вот я и клоню к этому, что экономия на спичках.
C>>>>>>стаковерфлоу G>>>>>Он кстати использует куки, а не сессию. C>>>>откуда инфа что они пользовательскую информацию хранят в куках? например тут: t=QE21gRQTMkLO&s=KC7vJBzhSkeA много не сохранишь. G>>>А причем тут пользовательская информация? я про аутентификацию говорю C>>еще раз, я задал вопрос, что храниться в строке вида, т.к. в моей практике я с этим не сталкивался (делал вручную, без использования Membership и прочего стандартного набора) C>>
C>>Ну там просто указано, какой именно юзер аутентифицировался по Forms-аутентификации.
C>>я выразил сомнение в целесообразности хранения имени пользователя и других пользовательских данных в куках, т.к. на практике это может расшифровываться в разумное время. G>Время расшифровывания не зависит от того какие данные хранятся.
это понятно.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[8]: Cookies from ASP.NET servers can be cracked
Здравствуйте, gandjustas, Вы писали:
G>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей.
И вы что, серьезно предлагаете хранить всю эту информацию в кукисах ради якобы снижения нагрузки на сервер?
Вы предлагаете так все и оставить, не менять модель безопасности .Net?
Лично я всегда хранил в кукисах: ID пользователя + 32 байтных случайных ключ. Все! Остальная изформация из базы данных + кеширование на сервере. Кукисы только для https. Всегда знал что стандартная система ни к черту: ну студент какой придумал (или человек просто не выспался) а остальные не обратили внимания.
G>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию.
Это, молодой человек, называется экономия на спичках. Если у вас несколько серверов -- продумайте грамотно взаимодействие.
Re[9]: Cookies from ASP.NET servers can be cracked
Здравствуйте, 0K, Вы писали:
0K>Здравствуйте, gandjustas, Вы писали:
G>>Задача: у тебя 10 веб-серверов, пользователь заходит грубо говоря на случайный из них. Надо понять что он авторизован и получить его id и отображаемое имя и список ролей.
0K>И вы что, серьезно предлагаете хранить всю эту информацию в кукисах ради якобы снижения нагрузки на сервер?
Она и так хранится, для этого пару настроек в web.config надо сделать.
0K>Вы предлагаете так все и оставить, не менять модель безопасности .Net?
Модель отлично работает, реализация подкачала.
Это именно баг реализации что злоумышенник может определить правильно ли расшифровалась кука или нет.
0K>Лично я всегда хранил в кукисах: ID пользователя + 32 байтных случайных ключ. Все! Остальная изформация из базы данных + кеширование на сервере. Кукисы только для https. Всегда знал что стандартная система ни к черту: ну студент какой придумал (или человек просто не выспался) а остальные не обратили внимания.
Да ты у нас самый умный, мы это прекрасно знаем.
HTTPS кстати никак не помогает против такой атаки
G>>В asp.net эта информация передается в шифрованых куках, то есть сервер может без обращения к внешним источникам узнать всю необходимую информацию. 0K>Это, молодой человек, называется экономия на спичках. Если у вас несколько серверов -- продумайте грамотно взаимодействие.
так уже продумали — не использовать сессию, я об этом и говорю.
Re[9]: Cookies from ASP.NET servers can be cracked
Здравствуйте, 0K, Вы писали:
0K>Лично я всегда хранил в кукисах: ID пользователя + 32 байтных случайных ключ. Все! Остальная изформация из базы данных + кеширование на сервере.
Кстати хороший пример.
Вот у тебя в кеше лежат данные чтобы показать страницу, но на каждой странице надо вывести имя пользователя (не логин). Условия все те же: ферма.
1)Бегать за ними на сервер — неэффективно, снижает пропускную способность.
2)Держать в кеше — тоже не очень полезно, если человек зайдет ровно один раз, кроме того кеширование в ферме также требует включения мозга.
3)Сессия — вообще ужас, см выше.
А вот передавать вместе с кукой — идеально (имхо).
Re[11]: Cookies from ASP.NET servers can be cracked
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gandjustas, Вы писали:
0K>>>Вы предлагаете так все и оставить, не менять модель безопасности .Net? G>>Модель отлично работает, реализация подкачала.
KV>У этой модели есть один, но очень существенный недостаток: она создает зависимость безопасности всей системы (в части, касающейся аутентификации и авторизации) от качества реализации всего лишь одной криптографической функции. Получается куча яиц в одном лукошке, что увеличивает связанные с реализацией любой из актуальных для этой функции угроз риски до небес.
Здравствуйте, kochetkov.vladimir, Вы писали:
KV>Здравствуйте, gandjustas, Вы писали:
0K>>>Вы предлагаете так все и оставить, не менять модель безопасности .Net? G>>Модель отлично работает, реализация подкачала.
KV>У этой модели есть один, но очень существенный недостаток: она создает зависимость безопасности всей системы (в части, касающейся аутентификации и авторизации) от качества реализации всего лишь одной криптографической функции. Получается куча яиц в одном лукошке, что увеличивает связанные с реализацией любой из актуальных для этой функции угроз риски до небес.
Насколько я понимаю любая система безопасности сильна настолько насколько сильно её самое слабое звено.
G>>Это именно баг реализации что злоумышенник может определить правильно ли расшифровалась кука или нет. KV>Сколько еще багов реализации осталось конкретно в этой, отлично работающей модели?
Ну серьезный нашли пока только один, и то довольно легко исправимый.
Re[15]: Cookies from ASP.NET servers can be cracked
Здравствуйте, cadet354, Вы писали:
C>по сравнению со считываем информации с локального диска. G>> Откуда ты чтение с диска взял? В аутентификационной куке передается вся необходимая информация, дополнительно никуда обращаться не надо. C>вот я и клоню к этому, что экономия на спичках.
так тебе и говорят что кука _не_ читается с диска
Re[12]: Cookies from ASP.NET servers can be cracked
Здравствуйте, gandjustas, Вы писали:
G>Ну серьезный нашли пока только один, и то довольно легко исправимый.
уже прошло больше 12 дней,update все нет, под степень "довольно легко исправимый" не попадает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1270>>
Re[16]: Cookies from ASP.NET servers can be cracked
Здравствуйте, mogadanez, Вы писали:
M>так тебе и говорят что кука _не_ читается с диска
я _это_ знаю, я не утверждал _что_ кука читается с диска, пример со временем чтения с локального диска я привел для сравнения скорости.
а причем тут HTTP only?
