доброй ночи
правильна ли такая схема авторизации:
ввод логина и пароля - сверка в sql (пароль в md5 + шум). ok, совпаловыдача куки с 32-битным ключом + занос в sql этого ключа (как уникального индекса) + занос туда же IP и некоторых параметров, присущих этому юзеру (конкретно, его привилегии)
когда клиент заходит в закрытую зону, ключ из его куки проверяется в базе на соответствие IP, берётся его уровень доступа и.. работаем в закрытой зоне с соответствующими правами
хешить в куках логин с паролем наверное всё-таки не очень гуд, а сверку уникального 32-битного ключа с IP подобрать, по идее, анрил..
или рил? или может есть метод получше?
1. если использовать твою схему - то тогда с 64битным случайным ключем. 32 мало по опыту. еще лучше - uuid.
2. если проект не под нагрузку - покатит. под нагрузку см пункт3.
3. можно облегчить жизнь бд, используя симмитричную криптографию: зашифрованную структуру из пользовательского ида, ника, ипа и привилегий или чего там еще хранить в его куках. на каждом пользовательском запросе расшифровывать его куку и без обращения к бд узнавать все о нем, оставаясь уверенным в защищенности данных. это самый потсанский метод.
> 1. если использовать твою схему - то тогда с 64битным случайным ключем.
> 32 мало по опыту. еще лучше - uuid.
> 2. если проект не под нагрузку - покатит. под нагрузку см пункт3.
> 3. можно облегчить жизнь бд, используя симмитричную криптографию: зашифрованную структуру
> из пользовательского ида, ника, ипа и привилегий или чего там еще
> хранить в его куках. на каждом пользовательском запросе расшифровывать его куку
> и без обращения к бд узнавать все о нем, оставаясь уверенным
> в защищенности данных. это самый потсанский метод.хмм, куку можно просто выкрасть
и какой смысл держать в ней логин с пассом, если не сверяться с базой?
а select одной-единственной записи в 1м поле по проиндексированному ключу это же мизерная нагрузка
я такую схему видел в phpBB, там тоже в куке 1 уникID отвечает за авторизацию и всёкстати, да, у меня получается именно UUID, ибо я сам его генерирую
блин, я там написал 32-битный ключ, а имел ввиду 32-байтную последовательность символов
> хмм, куку можно просто выкрасть
> и какой смысл держать в ней логин с пассом, если не сверяться
> с базой?Куку сверяют c кукой на сервере (в таблице кук)
Кука - это сессионный флаг, он вааще ничего не должен обозначать, кроме SessionID.
Проверил пароль и логин - сгенерил абсолютно случайную куку, сохранил в таблице!
При последующих доступах в охраняемую территорию, проверяешь наличие куки,
при её существовании - проверяем и работаем, при отсутствии - выбрасываем на регистрацию.
>> хмм, куку можно просто выкрасть
>> и какой смысл держать в ней логин с пассом, если не сверяться
>> с базой?
> Куку сверяют c кукой на сервере (в таблице кук)
> Кука - это сессионный флаг, он вааще ничего не должен обозначать, кроме
> SessionID.в куках что угодно хранят
от настроек, до паролей
ты имеешь ввиду, что сами настройки должны быть на сервере, а в куке только id в базе, где эти настройки?
так я ж про это и спрашиваю в первом сообщении, собрался так авторизовываться
>>> хмм, куку можно просто выкрасть
>>> и какой смысл держать в ней логин с пассом, если не сверяться
>>> с базой?
>> Куку сверяют c кукой на сервере (в таблице кук)
>> Кука - это сессионный флаг, он вааще ничего не должен обозначать, кроме
>> SessionID.
> в куках что угодно хранят
> от настроек, до паролейИдиотов много на свете, не стоит брать с них пример. :)
> где эти настройки?А я откуда знаю, как сделаешь так и заработает.
Кука собственно для этого и придумывалась, - разгрузить сервак и юзеров
от повторных операций с авторизацией.
>> где эти настройки?
> А я откуда знаю, как сделаешь так и заработает.нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся в базе
>>> где эти настройки?
>> А я откуда знаю, как сделаешь так и заработает.
> нет, это понятно, я говорю по id в кукеОбычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie,
тем самым экономишь open() + read() + strcmp() + close();> индентифицировать настройки, хранящиеся в базе
Абсолютно тоже самое, как и иными методами.
КУКА = ПРОВЕРИТЬ(КУКА_У_ЮЗЕРА);
ЕСЛИ ( КУКА_У_ЮЗЕРА == КУКА_В_БАЗЕ )
ТОГДА
ПОШЕЛ_НА(КОНЕЦ);
ПАРОЛЬ:RET = ПРОВЕРИТЬ( Логин && Пароль )
ЕСЛИ ( RET == ПРАВИЛЬНО )
ТОГДА
KУКА = СОЗДАТЬ(СЛУЧАЙНУЮ_КУКУ);
ОТДАТЬ_ЮЗЕРУ(КУКА);
СОХРАНИТЬ_В_ТАБЛИЦЕ_КУК(КУКА);
ИНАЧЕ
ЕСЛИ ( RET == НЕ_ПРАВИЛЬНО )
ТОГДА
ПОШЕЛ_НА(ПАРОЛЬ);
КОНЕЦ;
>>>> где эти настройки?
>>> А я откуда знаю, как сделаешь так и заработает.
>> нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся
>> в базе
> Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie
> тем самым экономишь open() + read() + strcmp() + close();не понял, всмысле на сервере хранить множество файлов, вместо записей в БД?
>>>>> где эти настройки?
>>>> А я откуда знаю, как сделаешь так и заработает.
>>> нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся
>>> в базе
>> Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie
>> тем самым экономишь open() + read() + strcmp() + close();
> не понял, всмысле на сервере хранить множество файлов, вместо записей в БД?см. выше
>>>>>> где эти настройки?
>>>>> А я откуда знаю, как сделаешь так и заработает.
>>>> нет, это понятно, я говорю по id в куке индентифицировать настройки, хранящиеся
>>>> в базе
>>> Обычно делают не В куке, а саму куку (файл), типа A7SIOO_Oxd5!-3434VG13g56.cookie
>>> тем самым экономишь open() + read() + strcmp() + close();
>> не понял, всмысле на сервере хранить множество файлов, вместо записей в БД?
> см. вышеа чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))
> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))Значит кука правильная - юзер наш, старый и проверенный!
>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))
> Значит кука правильная - юзер наш, старый и проверенный!аа, ну так я же это самое и предлагал
и сверять куку с IP каждый раз
а кука это просто 32 байта (от балды) случайных символов, по которым её идентифицируют в базе
>>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))
>> Значит кука правильная - юзер наш, старый и проверенный!
> аа, ну так я же это самое и предлагал
> и сверять куку с IP каждый разДа нафига его сверять... есть ip да и хер бы с ним...
Мож он с мобилы, связи потерял, а keepalive - ждет,
новый адрес получил, чё, опять авторизоваться?!Кстати, разновидность MITM атаки есть, когда прерывают сессию,
чтоб поймать авторизационные данные.
> а кука это просто 32 байта (от балды) случайных символов,
> по которым её идентифицируют в базеДа, и пущай там валяется 3600 секунд.
>>>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))
>>> Значит кука правильная - юзер наш, старый и проверенный!
>> аа, ну так я же это самое и предлагал
>> и сверять куку с IP каждый раз
> Да нафига её сверять... есть ip да и хер бы с ним...
> Мож он с мобилы, связи потерял, а keepalive - ждет, новый адрес
> получил,
> чё, опять авторизоваться?!
> Кстати, разновидность MITM атаки есть, когда прерывают сессию,
> чтоб поймать авторизационные данные.ага, опять. ибо нех.
>> а кука это просто 32 байта (от балды) случайных символов,
>> по которым её идентифицируют в базе
> Да, и пущай там валяется 3600 секунд.нее, это мало. надо комфортно, надолго
>> чё, опять авторизоваться?!
>> Кстати, разновидность MITM атаки есть, когда прерывают сессию,
>> чтоб поймать авторизационные данные.
> ага, опять. ибо нех.Не хорошо это как-то, для уровня приложений юзать данные из сетевого уровня,
ты ещё по макадрессу авторизуй в апаче :)>> Да, и пущай там валяется 3600 секунд.
> нее, это мало. надо комфортно, надолгоНу феншуй сам там наводи... кому, куда и сколько...
>>> а чО это "КУКУ_У_ЮЗЕРА == КУКА_В_БАЗЕ" выдаёт "ПОШЕЛ_НА(КОНЕЦ);" :)))
>> Значит кука правильная - юзер наш, старый и проверенный!
> аа, ну так я же это самое и предлагал
> и сверять куку с IP каждый раз
> а кука это просто 32 байта (от балды) случайных символов, по которым
> её идентифицируют в базеИМХО не надо "от балды", берите что-то вроде SHA1(UserID + microtime() + SECRET)
> а select одной-единственной записи в 1м поле по проиндексированному ключу это же
> мизерная нагрузка
> я такую схему видел в phpBB, там тоже в куке 1 уникID
> отвечает за авторизацию и всёиз таких мизерных нагрузок собирается нагрузка побольше. Кроме того, обращение к БД (по стандартным SQL-интерфейсам) - это _всегда_ дольше, чем альтернативные быстрые варианты.
А время обработки запроса - критически важно. Но это для _нагрузок_, вы можете этим не заморачиваться совсем.В порядке роста скорости исполнения:
1) Нырнуть в файл / Обращение к БД
2) Обратиться в NoSQL (например в Memcache, но нужно понимать что это негарантированное хранилище)
3) Проверить корректность подписи значения в CookieНо также нужно учитывать объемы авторизационной информации.
Если вы туда собрались плюнуть сотни байт и выше, то тогда вариантом будет только (2), в котором хранить эту авторизационную информацию, а доступ к ней организовать по уникальному ключу сессии из cookie.
ты похоже не научился читать и понимать написанное. про хранение логина и пароля - ни слова не говорил.написано - держать в куке зашифрованный идентификатор пользователя и какую еще часто используемую инфу. к примеру, если на каждой странице отображается его имя пользователя - нечего за ним лазить - пусть пользователь сам скажет свой ник, а криптография позволит удостовериться что он не нагнал что это его. то-же и с уидом - хочет пользователь прочитать свою почту - берем от него уид( также защищенный от подделки ) и делаем один запрос к бд с выгребкой его почты. вместо двух.
в общем походу тебе можно не замарачиваться - храни хеш и лазь в бд.
>[оверквотинг удален]
> написано - держать в куке зашифрованный идентификатор пользователя и какую еще часто
> используемую инфу. к примеру, если на каждой странице отображается его имя
> пользователя - нечего за ним лазить - пусть пользователь сам скажет
> свой ник, а криптография позволит удостовериться что он не нагнал что
> это его. то-же и с уидом - хочет пользователь прочитать свою
> почту - берем от него уид( также защищенный от подделки )
> и делаем один запрос к бд с выгребкой его почты. вместо
> двух.
> в общем походу тебе можно не замарачиваться - храни хеш и лазь
> в бд.во1, на каждой странице надо проверять, имеет ли он вообще право там находиться = по-любому в базу лезть.
сам читать поучись, это написано в первом сообщении.
во2, какую такую инфу ты собрался в зашифрованных куках хранить, если не логин, его привилегии, прочие секреты, м?
имя, да его можно просто написать: name=имя - всем насрать на него
а если ты что-то конфиденциальное туда запихнёшь, то надо это сделать так, чтобы злоумышленник, получив куку с твоего сервера, не смог её расшифровать и разобрать на поля, которые на сервер шлются. потому что тогда он зашифрует любую свою инфу и отправит на твой сервер.
так что ты уж там постарайся, а я пока да, уидами пользоваться буду.
ты похоже смотришь те фильмы, где любую защиту взламывают за несколько секунд.
подскажу - гугл, фейсбук, вк, яндекс, - все используют куки аналогичным образом.вот тебе к примеру с ютуба:
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байта - защищеные криптографией данные.это повсеместно.
> ты похоже смотришь те фильмы, где любую защиту взламывают за несколько секунд.нет, я вообще могу припомнить всего пару фильмов, где показывалось что-то близкое к реальному взлому: в матрице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
их же невозможно расшифровать потом ^^
ты сам понял что сказал?
> ты сам понял что сказал?какое слово ты не понял?
что значит хранить данные в протоколе SSH1?
> что значит хранить данные в протоколе SSH1?это опечатка
ты упоминал SHA1-шифрование
нах оно, я так и не понял
хранить в куках что-то ценное БЕЗ шифрования вообще бред
НЕ ценное в шифровании вообще не нуждается
а шифровать чем-то вроде SHA1 это шифрование в одну сторону, которое потом не вернуть без обращения в базуили можно как-то кодировать куки, чтобы потом их по некоему ключу раскодировать и быть на 200% уверенным, что его никто не узнает?
> ты похоже смотришь те фильмы, где любую защиту взламывают за несколько секунд.
> подскажу - гугл, фейсбук, вк, яндекс, - все используют куки аналогичным образом.
> вот тебе к примеру с ютуба:
> 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 можно тем же парсером.
sid там не простой а с данными. об этом и твержу - нахрена в бд лазить - если можно куки разгребсти и все нужное узнать. и что самое удивительное - это будет работь независимо от того как ты назовешь свою домашнюю страничку - защищенной зоной или публичным домом.ты сейчас коверкаешь вопрос.
> sid там не простой а с данными. об этом и твержу -
> нахрена в бд лазить - если можно куки разгребсти и все нужное узнать.Откуда узнать?
Короча, [censored] ты, кури AAA и RFC2905 :)
> правильна ли такая схема авторизации:логин и пароль на каждый чих, пущай трахаются,
сейчас практически во всех браузерах само запоминается.
мне тут твоя писанина выше напомнила рассказ друга:- поставляют наши в одну африканскую страну разные военные девайсы, ну и как водиться снабдили поставку несколькими нашими спецами для обучения. так во время одной из лекция понадобилось произвести операцию схожую с забиванием гвоздя( может гвоздь и забивали - не помню ). молотка под рукой не оказалось - забили пассатижами, что рядом лежали. у аборигенов процедура( с нашей стороны обыденная ) забивания гвоздя не молотком вызвала сильное потрясение. они блин, были не в курсе что пассатижами можно забить гвоздь.
вот так и с тобой. ты блин чтоле не в курсе что в куках можно хранить информацию отличную от идентификатора сессии?
к тебе когда прилетает запрос от пользователя - ты получаешь некоторый контекст, содержимое которого ограничено параметрами цги запроса( хост, порты, ипы, ури, браузер, язык, ...). для расширения набора и были придуманны куки. для защиты критичных данных( например уида ) - добавляем криптографию.насчет phpBB - если учиться чему-то по его исходникам и реализациям можно стать только говнокодером. вместе с invision они возглавляют абстрактный сферический антирейтинг.
> ты блин чтоле не в курсе что в куках можноЯ в курсах, что нужно отвечать по теме, а чё туда автор пихать будет - фиолетово.
> отличную от идентификатора сессии?
Смысл? Хватить SessID, если появились сомнения, устарело, переход в более/менее секретную зону - запроси заново.
Иль лучше всунть вторую куку.
Махать пропуском в зону повышенной сверхсекретности в общей рабочей столовой - плохая примета!
> что значит хранить данные в протоколе SSH1?это опечатка
ты упоминал SHA1-шифрование
нах оно, я так и не понял
хранить в куках что-то ценное БЕЗ шифрования вообще бред
НЕ ценное в шифровании вообще не нуждается
а шифровать чем-то вроде SHA1 это шифрование в одну сторону, которое потом не вернуть без обращения в базуили можно как-то кодировать куки, чтобы потом их по некоему ключу раскодировать и быть на 200% уверенным, что его никто не узнает?
сама идея передачи инфы между пагами через куки БЕЗ обращения в базу - правильная и верная
например, можно запросто передать кукой название проекта, дату его и куратора
и потом обнулить её сразу же
но это пока годится только для неважной инфы
по моему разумению.
>> что значит хранить данные в протоколе SSH1?
> это опечатка ты упоминал SHA1-шифрование
> нах оно, я так и не понял
> хранить в куках что-то ценное БЕЗ шифрования вообще бред
> НЕ ценное в шифровании вообще не нуждается
> а шифровать чем-то вроде SHA1 это шифрование в одну сторону, которое потом
> не вернуть без обращения в базуSHA-1 - это хэширование (иль в простом смысле - контрольная сумма),
оно одностороннее по определению :)> или можно как-то кодировать куки, чтобы потом их по некоему ключу раскодировать
> и быть на 200% уверенным, что его никто не узнает?XOR (DATA, RANDOM(STRLEN(DATA)))
> сама идея передачи инфы между пагами через куки БЕЗ обращения в базу
> - правильная и верная например, можно запросто передать кукой название
> проекта, дату его и куратора и потом обнулить её сразу же но это пока
> годится только для неважной инфы по моему разумению.Блин, вы ВСЮ тему разбили на две части:
1. О передаче секретов и промежуточной авторизации на страницах через куки.
2. О передаче всего остального, например размера экрана и языка, через куки.Это ВАААААААААААЩЕ ДВА РАЗНЫХ ПОДХОДА!
> Блин, вы ВСЮ тему разбили на две части:
> 1. О передаче секретов и промежуточной авторизации на страницах через куки.
> 2. О передаче всего остального, например размера экрана и языка, через куки.
> Это ВАААААААААААЩЕ ДВА РАЗНЫХ ПОДХОДА!да с авторизацией разобрались уже. я так и оставил - сверку с базой по хешу+IP
вот передачу секретов, если возможно защитить в куках, то будет очень гуд
на п.2 похваще
> вот передачу секретов, если возможно защитить в куках, то будет очень гудМетодом "Открытого ключа" - открытой частью ключа шифруешь секреты в куке, закрытой - дешифруешь.