Что почитать по веб-авторизации?

> Что почитать по веб-авторизации?
Для точности: тут скорее надо говорить «аутентификация», а не «авторизация».

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


Ключевые слова для выполнения задачи:
* SSL (если типа гуглевской аутентификации, то достаточно просто SSL-канала без аутентификации сертификатами);
* html forms;
* browser cookies;
* sessions
* http redirect (Response headers);
* http request (REFERER)

ну и доки на язык, на котором это будет реализовано (php, perl, java, C+CGI и т.д.).

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

Можно ли обойтись без cookies?

Нет

Для работы с паролями нужно использовать библиотеку crypt, или есть что-либо более современное?

Смотря какой язык программирования будет использоваться. В большинстве случаев хватает sha1(SALT + passwd) или sha256(SALT + passwd), где SALT - это любая произвольная строка от балды, сохранённая в виде константы в исходниках.

Как после завершения работы клиента сбрасывать данные об авторизации с его компьютера?

не понял предложение. уточните задачу.

>> Можно ли обойтись без cookies?

Нет

можно.

>>> Можно ли обойтись без cookies?

Нет

можно.

как?

Спасибо, почитаю.

не понял предложение. уточните задачу.

Я имел в виду аналог cookie, живущих только одну сессию. Но, раз уж без «печенек» не обойтись, вопрос отпадает.

boo32

Можно ли обойтись без cookies? > Нет

можно.

А правда - как? В «голом» SSL - понятно, там есть «встроенная» авторизация, но если делать перенаправление обратно в html, то как можно запомнить сеанс?

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

Если нужно авторизоваться на другом домене, то кидаешь редирект на хттпс, оно проверяет свою хттпс-сессию, если всё нормально, то не рисует форму логина, а сразу редиректит обратно с хэшем.

Можно попробовать. Но в этом случае как-то надо будет узнавать, что пользователь завершил сеанс - чтобы «подчистить хвосты». Да и при каждом запросе придется передавать на сервер этот «левый хэш». Не очень устойчиво к сниферам. В принципе, конечно, можно этот самый «левый хэш» вычислять менять после каждого обмена информацией, тогда если снифер и перехватит запрос, перехватчик не сможет представится серверу. Надо будет обмозговать это дело. Вообще, хотелось бы узнать, как это делают - ведь штука очень распространенная.

>Можно попробовать. Но в этом случае как-то надо будет узнавать, что пользователь завершил сеанс - чтобы «подчистить хвосты». Да и при каждом запросе придется передавать на сервер этот «левый хэш». Не очень устойчиво к сниферам. В принципе, конечно, можно этот самый «левый хэш» вычислять менять после каждого обмена информацией, тогда если снифер и перехватит запрос, перехватчик не сможет представится серверу. Надо будет обмозговать это дело. Вообще, хотелось бы узнать, как это делают - ведь штука очень распространенная.

Не придумывай велосипедов. Создавай сессию, храни её идентификатор в cookie, в сессии же храни авторизован пользователь или нет. Сессии сами, например, в БД или в файлах в сериализованном виде. Как минимум удалять их придётся только при разлогинивании/по таймауту.

А снифер, при желании, у тебя всё что хочешь перехватит, и кукисы, и хэши в урл-е (причем урл проще утянуть), только постоянный SSL спасёт.

небольшой обзор: HTTP Session Management

небольшой обзор

Спасибо.

В общем, решил я сделать алгоритм следующего вида:

проверяем куки из клиентского запроса
если кук нет - возвращаем 0
если есть куки - ищем в БД идентификатор сессии, если не находим - возврат -1
	если находим - сравниваем с ключом:
		различаются - возврат -1
		одинаковы - возврат соотв. LEVEL, генерирование нового ключа, сохранение его в БД и передача клиенту через куки

аутентификация:
	в CGI, требующем аутентификацию, генерируем ID
	перенаправляем клиента на https - CGI аутентификации, передавая в качестве параметра ID
		и URL страницы, с которой был отправлен запрос
	клиент вводит пару имя:пароль и отправляет их CGI аутентификации
	CGI хеширует пароль и сравнивает его с хешем из БД для данного пользователя
		если все ок - генерируется KEY, в БД сессии для данного ID записывается KEY и LEVEL,
			перенаправляем на старый URL
		если не совпадает - сообщение об ошибке аутентификации

куки имеют вид ID=sess_id:KEY=key
запись в БД сессии имеет поля ID, KEY, LEVEL
запись в БД паролей имеет поля LOGIN, PASS_HASH, LEVEL

И еще: есть ли сишные библиотеки для работы с данными аутентификации (помимо crypt), или мне будет проще все сделать самому?

Вот неплохая статья http://phoinix.ucoz.ru/publ/2-1-0-20

В принципе, там описано то же самое, только в упрощенном варианте (без перенаправления на https для аутентификации), да еще и на perl :)

Как у гугла - это кроссдоменная. Видимо курить oAuth / OpenID. Можно еще почитать доку по API авторизации фейсбука и вконтактика.

также, как и работают сессии без кук (в пхп, к примеру): после авторизации редиректить на /login?auth=12345, где 12345 - некое случайное число, известное только серверу.

Понятно: идентификатор сессии можно либо хранить в куках, либо - в переменной javascript'а. Во втором случае в каждом POST-запросе нужно передавать еще и значение идентификатора вместо куки. Только вот как без кук организовать перенаправление после авторизации с шифрованного на нешифрованное соединение?

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

Ну ты по сути сделал как у всех. Единственно - не храни key в cookies. В них вообще стоит хранить только идентификатор сессии, остальное всё на стороне сервера - а то мало ли что.

Всё, что ты написал, делается довольно быстро, какие ты хочешь библиотеки? Для создания хэшей чтоли, или для отсылки кукисов?

Да нет, я думал, что уже есть что-то готовое. А так - куки отсылаются элементарным printf, хэши я делаю функцией crypt из одноименной библиотеки: хэш пароля - sha512, ключ и идентификатор - sha256. Передавать в куки буду только ключ, идентификатор вычисляется по IP , и, если в поле для данного ключа идентификатор совпадет с вычисленным, по хранящемуся там же уровню доступа клиенту будут разрешены определенные действия.

Правда, это не защищает от подмены IP и перехвата ключа. Но для 100% защиты придется вообще делать двухсторонний обмен, например: сервер отсылает клиенту случайное число, клиент шифрует его своим ключом, а сервер проверяет, совпадает ли полученный шифр с вычисленным по тому же ключу. Но это будет слишком закручено, да и потребует внесения значительных изменений в код клиентской стороны. Кроме того, в JavaScript нет нативной поддержки sha.

Кроме того, в JavaScript нет нативной поддержки sha

Да, но мы же не брут-форс собрались на клиенте запускать. Один раз пощитать не проблема

http://www.google.com.ua/search?hl=uk&q=JavaScript sha&aq=f&aqi=g...

В принципе если ты сделаешь полный SSL везде, то безопасность повысится значительно.

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

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

50% сделано: аутентификация с перенаправлением на защищенный канал с возвратом после правильного ввода данных заработала. Теперь остается дописать функцию для особо значимых CGI, чтобы выполнялась авторизация в соответствии с уровнем доступа.

Сделал, проверил - работает отлично.

Если кому-то интересно, я вкратце описал сделанное. Буду благодарен за рациональные предложения.