форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Информационная безопасность (Авторизация и аутентификация / FreeBSD)
Изначальное сообщение		[ Отслеживать ]

"авторизация, как правильно?"	+/–
Сообщение от greenwar (ok) on 28-Фев-13, 00:15
доброй ночи правильна ли такая схема авторизации: ввод логина и пароля - сверка в sql (пароль в md5 + шум). ok, совпало выдача куки с 32-битным ключом + занос в sql этого ключа (как уникального индекса) + занос туда же IP и некоторых параметров, присущих этому юзеру (конкретно, его привилегии) когда клиент заходит в закрытую зону, ключ из его куки проверяется в базе на соответствие IP, берётся его уровень доступа и.. работаем в закрытой зоне с соответствующими правами хешить в куках логин с паролем наверное всё-таки не очень гуд, а сверку уникального 32-битного ключа с IP подобрать, по идее, анрил.. или рил? или может есть метод получше?
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "авторизация, как правильно?"	+/–
Сообщение от parad (ok) on 28-Фев-13, 00:52
1. если использовать твою схему - то тогда с 64битным случайным ключем. 32 мало по опыту. еще лучше - uuid. 2. если проект не под нагрузку - покатит. под нагрузку см пункт3. 3. можно облегчить жизнь бд, используя симмитричную криптографию:  зашифрованную структуру из пользовательского ида, ника, ипа и привилегий или чего там еще хранить в его куках. на каждом пользовательском запросе расшифровывать его куку и без обращения к бд узнавать все о нем, оставаясь уверенным в защищенности данных. это самый потсанский метод.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 01:01
	> 1. если использовать твою схему - то тогда с 64битным случайным ключем. > 32 мало по опыту. еще лучше - uuid. > 2. если проект не под нагрузку - покатит. под нагрузку см пункт3. > 3. можно облегчить жизнь бд, используя симмитричную криптографию:  зашифрованную структуру > из пользовательского ида, ника, ипа и привилегий или чего там еще > хранить в его куках. на каждом пользовательском запросе расшифровывать его куку > и без обращения к бд узнавать все о нем, оставаясь уверенным > в защищенности данных. это самый потсанский метод. хмм, куку можно просто выкрасть и какой смысл держать в ней логин с пассом, если не сверяться с базой? а select одной-единственной записи в 1м поле по проиндексированному ключу это же мизерная нагрузка я такую схему видел в phpBB, там тоже в куке 1 уникID отвечает за авторизацию и всё кстати, да, у меня получается именно UUID, ибо я сам его генерирую блин, я там написал 32-битный ключ, а имел ввиду 32-байтную последовательность символов
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	4. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 01:33
	> хмм, куку можно просто выкрасть > и какой смысл держать в ней логин с пассом, если не сверяться > с базой? Куку сверяют c кукой на сервере (в таблице кук) Кука - это сессионный флаг, он вааще ничего не должен обозначать, кроме SessionID. Проверил пароль и логин - сгенерил абсолютно случайную куку, сохранил в таблице! При последующих доступах в охраняемую территорию, проверяешь наличие куки, при её существовании - проверяем и работаем, при отсутствии - выбрасываем на регистрацию.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	5. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 01:34
	>> хмм, куку можно просто выкрасть >> и какой смысл держать в ней логин с пассом, если не сверяться >> с базой? > Куку сверяют c кукой на сервере (в таблице кук) > Кука - это сессионный флаг, он вааще ничего не должен обозначать, кроме > SessionID. в куках что угодно хранят от настроек, до паролей ты имеешь ввиду, что сами настройки должны быть на сервере, а в куке только id в базе, где эти настройки? так я ж про это и спрашиваю в первом сообщении, собрался так авторизовываться
	Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

	6. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 01:36
	>>> хмм, куку можно просто выкрасть >>> и какой смысл держать в ней логин с пассом, если не сверяться >>> с базой? >> Куку сверяют c кукой на сервере (в таблице кук) >> Кука - это сессионный флаг, он вааще ничего не должен обозначать, кроме >> SessionID. > в куках что угодно хранят > от настроек, до паролей Идиотов много на свете, не стоит брать с них пример. :)
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	7. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 01:38
	> где эти настройки? А я откуда знаю, как сделаешь так и заработает. Кука собственно для этого и придумывалась, - разгрузить сервак и юзеров от повторных операций с авторизацией.
	Ответить | Правка | ^ к родителю #5 | Наверх | Cообщить модератору

	8. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 01:40
	>> где эти настройки? > А я откуда знаю, как сделаешь так и заработает. нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся в базе
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	9. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 01:43
	>>> где эти настройки? >> А я откуда знаю, как сделаешь так и заработает. > нет, это понятно, я говорю по id в куке Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie, тем самым экономишь open() + read() + strcmp() + close(); > индентифицировать настройки, хранящиеся в базе Абсолютно тоже самое, как и  иными методами. КУКА = ПРОВЕРИТЬ(КУКА_У_ЮЗЕРА);      ЕСЛИ ( КУКА_У_ЮЗЕРА == КУКА_В_БАЗЕ )          ТОГДА               ПОШЕЛ_НА(КОНЕЦ); ПАРОЛЬ: RET = ПРОВЕРИТЬ( Логин && Пароль )    ЕСЛИ ( RET == ПРАВИЛЬНО )       ТОГДА              KУКА = СОЗДАТЬ(СЛУЧАЙНУЮ_КУКУ);              ОТДАТЬ_ЮЗЕРУ(КУКА);              СОХРАНИТЬ_В_ТАБЛИЦЕ_КУК(КУКА);       ИНАЧЕ            ЕСЛИ ( RET == НЕ_ПРАВИЛЬНО )               ТОГДА                         ПОШЕЛ_НА(ПАРОЛЬ); КОНЕЦ;
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	10. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 01:44
	>>>> где эти настройки? >>> А я откуда знаю, как сделаешь так и заработает. >> нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся >> в базе > Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie > тем самым экономишь open() + read() + strcmp() + close(); не понял, всмысле на сервере хранить множество файлов, вместо записей в БД?
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	11. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 01:55
	>>>>> где эти настройки? >>>> А я откуда знаю, как сделаешь так и заработает. >>> нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся >>> в базе >> Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie >> тем самым экономишь open() + read() + strcmp() + close(); > не понял, всмысле на сервере хранить множество файлов, вместо записей в БД? см. выше
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	12. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 01:57
	>>>>>> где эти настройки? >>>>> А я откуда знаю, как сделаешь так и заработает. >>>> нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся >>>> в базе >>> Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie >>> тем самым экономишь open() + read() + strcmp() + close(); >> не понял, всмысле на сервере хранить множество файлов, вместо записей в БД? > см. выше а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))
	Ответить | Правка | ^ к родителю #11 | Наверх | Cообщить модератору

	13. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 01:59
	> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :))) Значит кука правильная - юзер наш, старый и проверенный!
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	14. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 02:01
	>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :))) > Значит кука правильная - юзер наш, старый и проверенный! аа, ну так я же это самое и предлагал и сверять куку с IP каждый раз а кука это просто 32 байта (от балды) случайных символов, по которым её идентифицируют в базе
	Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

	15. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 02:04
	>>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :))) >> Значит кука правильная - юзер наш, старый и проверенный! > аа, ну так я же это самое и предлагал > и сверять куку с IP каждый раз Да нафига его сверять... есть ip да и хер бы с ним... Мож он с мобилы, связи потерял, а keepalive - ждет, новый адрес получил, чё, опять авторизоваться?!   Кстати, разновидность MITM атаки есть, когда прерывают сессию, чтоб поймать авторизационные данные. > а кука это просто 32 байта (от балды) случайных символов, > по которым её идентифицируют в базе Да, и пущай там валяется 3600 секунд.
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	16. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 02:06
	>>>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :))) >>> Значит кука правильная - юзер наш, старый и проверенный! >> аа, ну так я же это самое и предлагал >> и сверять куку с IP каждый раз > Да нафига её сверять... есть ip да и хер бы с ним... > Мож он с мобилы, связи потерял, а keepalive - ждет, новый адрес > получил, > чё, опять авторизоваться?! > Кстати, разновидность MITM атаки есть, когда прерывают сессию, > чтоб поймать авторизационные данные. ага, опять. ибо нех. >> а кука это просто 32 байта (от балды) случайных символов, >> по которым её идентифицируют в базе > Да, и пущай там валяется 3600 секунд. нее, это мало. надо комфортно, надолго
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	17. "авторизация, как правильно?"	+1 +/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 02:08
	>> чё, опять авторизоваться?! >> Кстати, разновидность MITM атаки есть, когда прерывают сессию, >> чтоб поймать авторизационные данные. > ага, опять. ибо нех. Не хорошо это как-то, для уровня приложений юзать данные из сетевого уровня, ты ещё по макадрессу авторизуй в апаче :) >> Да, и пущай там валяется 3600 секунд. > нее, это мало. надо комфортно, надолго Ну феншуй сам там наводи... кому, куда и сколько...
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	19. "авторизация, как правильно?"	+/–
	Сообщение от PavelR (ok) on 28-Фев-13, 09:44
	>>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :))) >> Значит кука правильная - юзер наш, старый и проверенный! > аа, ну так я же это самое и предлагал > и сверять куку с IP каждый раз > а кука это просто 32 байта (от балды) случайных символов, по которым > её идентифицируют в базе ИМХО не надо "от балды", берите что-то вроде SHA1(UserID + microtime() + SECRET)
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	18. "авторизация, как правильно?"	+/–
	Сообщение от PavelR (ok) on 28-Фев-13, 09:38
	> а select одной-единственной записи в 1м поле по проиндексированному ключу это же > мизерная нагрузка > я такую схему видел в phpBB, там тоже в куке 1 уникID > отвечает за авторизацию и всё из таких мизерных нагрузок собирается нагрузка побольше. Кроме того, обращение к БД (по стандартным SQL-интерфейсам) - это _всегда_ дольше, чем альтернативные быстрые варианты. А время обработки запроса - критически важно. Но это для _нагрузок_, вы можете этим не заморачиваться совсем. В порядке роста скорости исполнения: 1) Нырнуть в файл / Обращение к БД 2) Обратиться в NoSQL (например в Memcache, но нужно понимать что это негарантированное хранилище) 3) Проверить корректность подписи значения в Cookie Но также нужно учитывать объемы авторизационной информации. Если вы туда собрались плюнуть сотни байт и выше, то тогда вариантом будет только (2), в котором хранить эту авторизационную информацию, а доступ к ней организовать по уникальному ключу сессии из cookie.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	20. "авторизация, как правильно?"	+/–
	Сообщение от parad (ok) on 28-Фев-13, 20:45
	ты похоже не научился читать и понимать написанное. про хранение логина и пароля - ни слова не говорил. написано - держать в куке зашифрованный идентификатор пользователя и какую еще часто используемую инфу. к примеру, если на каждой странице отображается его имя пользователя - нечего за ним лазить - пусть пользователь сам скажет свой ник, а криптография позволит удостовериться что он не нагнал что это его. то-же и с уидом - хочет пользователь прочитать свою почту - берем от него уид( также защищенный от подделки ) и делаем один запрос к бд с выгребкой его почты. вместо двух. в общем походу тебе можно не замарачиваться - храни хеш и лазь в бд.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	21. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 28-Фев-13, 20:58
	>[оверквотинг удален] > написано - держать в куке зашифрованный идентификатор пользователя и какую еще часто > используемую инфу. к примеру, если на каждой странице отображается его имя > пользователя - нечего за ним лазить - пусть пользователь сам скажет > свой ник, а криптография позволит удостовериться что он не нагнал что > это его. то-же и с уидом - хочет пользователь прочитать свою > почту - берем от него уид( также защищенный от подделки ) > и делаем один запрос к бд с выгребкой его почты. вместо > двух. > в общем походу тебе можно не замарачиваться - храни хеш и лазь > в бд. во1, на каждой странице надо проверять, имеет ли он вообще право там находиться = по-любому в базу лезть. сам читать поучись, это написано в первом сообщении. во2, какую такую инфу ты собрался в зашифрованных куках хранить, если не логин, его привилегии, прочие секреты, м? имя, да его можно просто написать: name=имя - всем насрать на него а если ты что-то конфиденциальное туда запихнёшь, то надо это сделать так, чтобы злоумышленник, получив куку с твоего сервера, не смог её расшифровать и разобрать на поля, которые на сервер шлются. потому что тогда он зашифрует любую свою инфу и отправит на твой сервер. так что ты уж там постарайся, а я пока да, уидами пользоваться буду.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	24. "авторизация, как правильно?"	+/–
	Сообщение от parad (ok) on 28-Фев-13, 21:38
	ты похоже смотришь те фильмы, где любую защиту взламывают за несколько секунд. подскажу - гугл, фейсбук, вк, яндекс, - все используют куки аналогичным образом. вот тебе к примеру с ютуба: Cookie:VISITOR_INFO1_LIVE=; use_hitbox=; recently_watched_video_id_list=; HSID=; APISID=; demographics=; BCSI-CS-xxx=2; wide=1; _U-gF.resume=; LOGIN_INFO=; SID=; ACTIVITY=; recently_watched_video_id_list - как переводится? LOGIN_INFO - >200байт в base64 - >150байт json'а SID - 204байта - защищеные криптографией данные. это повсеместно.
	Ответить | Правка | ^ к родителю #21 | Наверх | Cообщить модератору

	25. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 01-Мрт-13, 02:46
	> ты похоже смотришь те фильмы, где любую защиту взламывают за несколько секунд. нет, я вообще могу припомнить всего пару фильмов, где показывалось что-то близкое к реальному взлому: в матрице2 тринити + nmap, но с sshnuke уже перебор был; ещё девушка с татуировкой дракона, где за весь фильм аж целый 1 раз показали SQL-запрос но и там нагородили :( в остальных вообще беда с этим но это не мешает мне быть параноиком. я много читаю. > подскажу - гугл, фейсбук, вк, яндекс, - все используют куки аналогичным образом. > вот тебе к примеру с ютуба: > Cookie:VISITOR_INFO1_LIVE=; use_hitbox=; recently_watched_video_id_list=; HSID=; > APISID=; demographics=; BCSI-CS-xxx=2; wide=1; _U-gF.resume=; LOGIN_INFO=; SID=; ACTIVITY=; > recently_watched_video_id_list - как переводится? > LOGIN_INFO - >200байт в base64 - >150байт json'а > SID - 204байта - защищеные криптографией данные. > это повсеместно. я не понял, ты предлагаешь хранить некие данные в SSH1 их же невозможно расшифровать потом ^^
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	26. "авторизация, как правильно?"	+/–
	Сообщение от parad (ok) on 01-Мрт-13, 10:29
	ты сам понял что сказал?
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	27. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 01-Мрт-13, 17:56
	> ты сам понял что сказал? какое слово ты не понял?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	28. "авторизация, как правильно?"	+/–
	Сообщение от parad (ok) on 02-Мрт-13, 12:32
	что значит хранить данные в протоколе SSH1?
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	32. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 05-Мрт-13, 04:04
	> что значит хранить данные в протоколе SSH1? это опечатка ты упоминал SHA1-шифрование нах оно, я так и не понял хранить в куках что-то ценное БЕЗ шифрования вообще бред НЕ ценное в шифровании вообще не нуждается а шифровать чем-то вроде SHA1 это шифрование в одну сторону, которое потом не вернуть без обращения в базу или можно как-то кодировать куки, чтобы потом их по некоему ключу раскодировать и быть на 200% уверенным, что его никто не узнает?
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	29. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 02-Мрт-13, 16:08
	> ты похоже смотришь те фильмы, где любую защиту взламывают за несколько секунд.   > подскажу - гугл, фейсбук, вк, яндекс, - все используют куки аналогичным образом. > вот тебе к примеру с ютуба: > Cookie:VISITOR_INFO1_LIVE=; use_hitbox=; recently_watched_video_id_list=; HSID=; > APISID=; demographics=; BCSI-CS-xxx=2; wide=1; _U-gF.resume=; LOGIN_INFO=; SID=; ACTIVITY=; Блин, ты отходишь от темы. Всё вышеперечисленное - это некие настройки, к доступу и нахождению в защищённой зоне отношения не имеют. SID= запихнули внутрь, потому как всё-равно используется разбор содержимого зачем добавлять ещё функцию, если извлечь SID можно тем же парсером.
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	30. "авторизация, как правильно?"	+/–
	Сообщение от parad (ok) on 04-Мрт-13, 21:55
	sid там не простой а с данными. об этом и твержу - нахрена в бд лазить - если можно куки разгребсти и все нужное узнать. и что самое удивительное - это будет работь независимо от того как ты назовешь свою домашнюю страничку - защищенной зоной или публичным домом. ты сейчас коверкаешь вопрос.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 05-Мрт-13, 02:39
	> sid там не простой а с данными. об этом и твержу - > нахрена в бд лазить - если можно куки разгребсти и все нужное узнать. Откуда узнать? Короча, [censored] ты, кури AAA и RFC2905 :)
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

3. "авторизация, как правильно?"	+/–
Сообщение от pavlinux (ok) on 28-Фев-13, 01:26
> правильна ли такая схема авторизации: логин и пароль на каждый чих, пущай трахаются, сейчас практически во всех браузерах само запоминается.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	22. "авторизация, как правильно?"	+/–
	Сообщение от parad (ok) on 28-Фев-13, 21:18
	мне тут твоя писанина выше напомнила рассказ друга: - поставляют наши в одну африканскую страну разные военные девайсы, ну и как водиться снабдили поставку несколькими нашими спецами для обучения. так во время одной из лекция понадобилось произвести операцию схожую с забиванием гвоздя( может гвоздь и забивали - не помню ). молотка под рукой не оказалось - забили пассатижами, что рядом лежали. у аборигенов процедура( с нашей стороны обыденная ) забивания гвоздя не молотком вызвала сильное потрясение. они блин, были не в курсе что пассатижами можно забить гвоздь. вот так и с тобой. ты блин чтоле не в курсе что в куках можно хранить информацию отличную от идентификатора сессии? к тебе когда прилетает запрос от пользователя - ты получаешь некоторый контекст, содержимое которого ограничено параметрами цги запроса( хост, порты, ипы, ури, браузер, язык, ...). для расширения набора и были придуманны куки. для защиты критичных данных( например уида ) - добавляем криптографию. насчет phpBB - если учиться чему-то по его исходникам и реализациям можно стать только говнокодером. вместе с invision они возглавляют абстрактный сферический антирейтинг.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	23. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 28-Фев-13, 21:37
	> ты блин чтоле не в курсе что в куках можно Я в курсах, что нужно отвечать по теме, а чё туда автор пихать будет - фиолетово. > отличную от идентификатора сессии? Смысл? Хватить SessID, если появились сомнения, устарело, переход в более/менее секретную зону - запроси заново. Иль лучше всунть вторую куку. Махать пропуском в зону повышенной сверхсекретности в общей рабочей столовой - плохая примета!
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	33. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 05-Мрт-13, 05:16
	> что значит хранить данные в протоколе SSH1? это опечатка ты упоминал SHA1-шифрование нах оно, я так и не понял хранить в куках что-то ценное БЕЗ шифрования вообще бред НЕ ценное в шифровании вообще не нуждается а шифровать чем-то вроде SHA1 это шифрование в одну сторону, которое потом не вернуть без обращения в базу или можно как-то кодировать куки, чтобы потом их по некоему ключу раскодировать и быть на 200% уверенным, что его никто не узнает? сама идея передачи инфы между пагами через куки БЕЗ обращения в базу - правильная и верная например, можно запросто передать кукой название проекта, дату его и куратора и потом обнулить её сразу же но это пока годится только для неважной инфы по моему разумению.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	34. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 06-Мрт-13, 01:17
	>> что значит хранить данные в протоколе SSH1? > это опечатка ты упоминал SHA1-шифрование > нах оно, я так и не понял > хранить в куках что-то ценное БЕЗ шифрования вообще бред > НЕ ценное в шифровании вообще не нуждается > а шифровать чем-то вроде SHA1 это шифрование в одну сторону, которое потом > не вернуть без обращения в базу SHA-1 - это хэширование (иль в простом смысле - контрольная сумма), оно одностороннее по определению :) > или можно как-то кодировать куки, чтобы потом их по некоему ключу раскодировать > и быть на 200% уверенным, что его никто не узнает? XOR (DATA, RANDOM(STRLEN(DATA))) > сама идея передачи инфы между пагами через куки БЕЗ обращения в базу > - правильная и верная например, можно запросто передать кукой название > проекта, дату его и куратора и потом обнулить её сразу же но это пока > годится только для неважной инфы по моему разумению. Блин, вы ВСЮ тему разбили на две части: 1. О передаче секретов и промежуточной авторизации на страницах через куки. 2. О передаче всего остального, например размера экрана и языка, через куки. Это ВАААААААААААЩЕ ДВА РАЗНЫХ ПОДХОДА!
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	35. "авторизация, как правильно?"	+/–
	Сообщение от greenwar (ok) on 06-Мрт-13, 01:41
	> Блин, вы ВСЮ тему разбили на две части: > 1. О передаче секретов и промежуточной авторизации на страницах через куки. > 2. О передаче всего остального, например размера экрана и языка, через куки. > Это ВАААААААААААЩЕ ДВА РАЗНЫХ ПОДХОДА! да с авторизацией разобрались уже. я так и оставил - сверку с базой по хешу+IP вот передачу секретов, если возможно защитить в куках, то будет очень гуд на п.2 похваще
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	36. "авторизация, как правильно?"	+/–
	Сообщение от pavlinux (ok) on 06-Мрт-13, 02:19
	> вот передачу секретов, если возможно защитить в куках, то будет очень гуд Методом "Открытого ключа" - открытой частью ключа шифруешь секреты в куке, закрытой - дешифруешь.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема