LINUX.ORG.RU

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


0

0

Мне нужно добавить авторизацию к некоторым сервисам. Посоветуйте, что почитать, чтобы сделать авторизацию наподобие гугловской. Т.е. идея такая:

  • если клиент запрашивает определенную веб-страницу, которой нужна авторизация, происходит перенаправление на https с формой авторизации;
  • в форму вводится логин и пароль и данные отсылаются CGI, который получает хэш пароля и сравнивает пару логин-хэш пароля с данными из базы (скажем, на mysql);
  • если данные правильные, происходит перенаправление обратно, доступ к сервису разрешается.

У меня загвоздка в перенаправлении: как после https-авторизации «перескочить» обратно на нешифрованное соединение, чтобы при этом сохранять информацию о сеансе? Можно ли обойтись без cookies? Для работы с паролями нужно использовать библиотеку crypt, или есть что-либо более современное? Как после завершения работы клиента сбрасывать данные об авторизации с его компьютера?

☆☆☆☆☆

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

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


Ключевые слова для выполнения задачи:
* 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 - это любая произвольная строка от балды, сохранённая в виде константы в исходниках.

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

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

Slavaz ★★★★★ ()
Ответ на: комментарий от Slavaz

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

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

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

boo32

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

можно.

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

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

INFOMAN ★★★★★ ()
Ответ на: комментарий от INFOMAN

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

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

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

anonymous ()

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

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от kst

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

Eddy_Em ☆☆☆☆☆ ()

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

Vit ★★★★★ ()
Ответ на: комментарий от Slavaz

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

boo32 ()
Ответ на: комментарий от boo32

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

Eddy_Em ☆☆☆☆☆ ()
Ответ на: комментарий от Eddy_Em

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

Eddy_Em ☆☆☆☆☆ ()

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

Eddy_Em ☆☆☆☆☆ ()

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

Eddy_Em ☆☆☆☆☆ ()
12 июля 2010 г.

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

Eddy_Em ☆☆☆☆☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.