Кроссайтовая авторизация
63 views
Skip to first unread message
UserASD
Nov 7, 2007, 3:29:31 PM11/7/07
to RubyOnRails to russian
Доброго времени суток.
А вот стал мне интересен такой вопрос: как реализуется кроссайтовая
автоизация? (Например, google/blogger или vkontakte/vkadre.) То есть
пользовательские сессии делятся между разными сайтами.
Куки, очевидно, у браузера для каждого сайта свои. По IP тоже не
годится (из-за всяких NAT, в частности). Что же остаётся?
-- Evgeny Zolotarev
Michael Klishin
Nov 7, 2007, 3:44:10 PM11/7/07
to ror...@googlegroups.com
Хранить в базе отдельного приложения,
реализовывать single sign on через это
приложение, пиная его по ActiveResource. По-
крайней мере, это достаточно
прозрачный вариант, который допускает
прикрутку любого числа приложений6
использующих этот single sign on.
On 7 нояб. 2007, at 23:29, UserASD wrote:
>
> А вот стал мне интересен такой вопрос:
> как реализуется кроссайтовая
> автоизация? (Например, google/blogger или
> vkontakte/vkadre.) То есть
> пользовательские сессии делятся
> между разными сайтами.
>
> Куки, очевидно, у браузера для каждого
> сайта свои. По IP тоже не
> годится (из-за всяких NAT, в частности).
> Что же остаётся?
>
MK
реализовывать single sign on через это
приложение, пиная его по ActiveResource. По-
крайней мере, это достаточно
прозрачный вариант, который допускает
прикрутку любого числа приложений6
использующих этот single sign on.
On 7 нояб. 2007, at 23:29, UserASD wrote:
>
> А вот стал мне интересен такой вопрос:
> как реализуется кроссайтовая
> автоизация? (Например, google/blogger или
> vkontakte/vkadre.) То есть
> пользовательские сессии делятся
> между разными сайтами.
>
> Куки, очевидно, у браузера для каждого
> сайта свои. По IP тоже не
> годится (из-за всяких NAT, в частности).
> Что же остаётся?
>
Max Lapshin
Nov 7, 2007, 4:13:59 PM11/7/07
to ror...@googlegroups.com
On 11/7/07, Michael Klishin <michael.s.k...@gmail.com> wrote:
Хранить в базе отдельного приложения,
реализовывать single sign on через это
приложение, пиная его по ActiveResource. По-
крайней мере, это достаточно
прозрачный вариант, который допускает
прикрутку любого числа приложений6
использующих этот single sign on.
вопрос то прежде всего в том, что как, при заходе браузера на http://getalime.ru/, серверу
узнать, что на maxidoors.ru он уже под определённым пользователем залогинился.
UserASD
Nov 7, 2007, 6:32:31 PM11/7/07
to RubyOnRails to russian
совершенно верно
-- Evgeny Zolotarev
On 8 нояб, 00:13, "Max Lapshin" <max.laps...@gmail.com> wrote:
> On 11/7/07, Michael Klishin <michael.s.klishin.li...@gmail.com> wrote:
>
>
>
> > Хранить в базе отдельного приложения,
> > реализовывать single sign on через это
> > приложение, пиная его по ActiveResource. По-
> > крайней мере, это достаточно
> > прозрачный вариант, который допускает
> > прикрутку любого числа приложений6
> > использующих этот single sign on.
>
> вопрос то прежде всего в том, что как, при заходе браузера наhttp://getalime.ru/, серверу
Олег Андреев
Nov 8, 2007, 12:58:19 AM11/8/07
to ror...@googlegroups.com
По принципу openid. Каждый сайт заводит свой список юзеров, но
авторизует их по сообщению с постороннего сервера.
У нас так:
1) Заходишь на vkadre.ru/session/new (или /videos/new, или еще куда-
нибудь, где нужен логин)
2) Редирект на vkontakte.ru/autologin
3) Если юзер залогинен, то контакт редиректит его на vkadre.ru/vk-
login?name=Oleg&key=6af839...
3) Если юзер не залогинен, то контакт редиректит на vkadre.ru/vk-login?
failed
4) На ВКадре: если okay, то инфа используется для поиска/
авторегистрации юзера.
4) если failed, то ставим session['vk-autologin-failed'] = 1 и
показываем форму регистрации
Никаких ActiveResource и пингования. Ключик в том, что в GET-запросе
лежит минимально необходимая информация: id, name, email. И все это
хозяйство подписано расшаренным между серверами секретным ключом.
07.11.2007, в 23:29, UserASD написал(а):
авторизует их по сообщению с постороннего сервера.
У нас так:
1) Заходишь на vkadre.ru/session/new (или /videos/new, или еще куда-
нибудь, где нужен логин)
2) Редирект на vkontakte.ru/autologin
3) Если юзер залогинен, то контакт редиректит его на vkadre.ru/vk-
login?name=Oleg&key=6af839...
3) Если юзер не залогинен, то контакт редиректит на vkadre.ru/vk-login?
failed
4) На ВКадре: если okay, то инфа используется для поиска/
авторегистрации юзера.
4) если failed, то ставим session['vk-autologin-failed'] = 1 и
показываем форму регистрации
Никаких ActiveResource и пингования. Ключик в том, что в GET-запросе
лежит минимально необходимая информация: id, name, email. И все это
хозяйство подписано расшаренным между серверами секретным ключом.
07.11.2007, в 23:29, UserASD написал(а):
labria
Nov 8, 2007, 2:16:05 AM11/8/07
to RubyOnRails to russian
Я что-то не очень понимаю секурности этого метода.
Получается что если я поймаю GET запрос на vkadre.ru/vk-
login?name=Oleg&key=6af839... , то я могу потом послав его еще раз с
нужным REFERRER залогиниться под этим юзером?
Или key генерится все-так на основе каких-то данных из первичного
редиректа и уникален для данной сессии?
Получается что если я поймаю GET запрос на vkadre.ru/vk-
login?name=Oleg&key=6af839... , то я могу потом послав его еще раз с
нужным REFERRER залогиниться под этим юзером?
Или key генерится все-так на основе каких-то данных из первичного
редиректа и уникален для данной сессии?
Олег Андреев
Nov 8, 2007, 2:36:00 AM11/8/07
to ror...@googlegroups.com
key сейчас не уникален для данной сессии, но уникален для данного юзера.
key = md5( email, id, shared_secret )
Т.е. если ты будешь сниффать сеть, то сможешь поймать эту строку и
авторизоваться от имени данного юзера. Впрочем, поскольку в поля имейл/
пароль данные кладутся незашифрованными, их тоже можно просниффать.
Есть, однако одна проблема: get-запрос может быть залоггирован
промежуточным шлюзом, а это не очень хорошо. Поэтому можно добавить
timestamp, который тоже будет подписываться:
timestamp = Time.now.to_i
key = md5( email, id, timestamp, shared_secret )
redirect_to "...×tamp=#{timestamp}&key=#{key}"
На приемной стороне (вкадре.ру) будет проверка, что timestamp
отличается от текущего времени не более, чем на 5 секунд. Тогда все
равно можно залогиниться, сниффая сеть, но записи в логах будут
устаревшими.
Время, разумеется, должно быть синхронизованное и в UTC каком-нибудь.
08.11.2007, в 10:16, labria написал(а):
key = md5( email, id, shared_secret )
Т.е. если ты будешь сниффать сеть, то сможешь поймать эту строку и
авторизоваться от имени данного юзера. Впрочем, поскольку в поля имейл/
пароль данные кладутся незашифрованными, их тоже можно просниффать.
Есть, однако одна проблема: get-запрос может быть залоггирован
промежуточным шлюзом, а это не очень хорошо. Поэтому можно добавить
timestamp, который тоже будет подписываться:
timestamp = Time.now.to_i
key = md5( email, id, timestamp, shared_secret )
redirect_to "...×tamp=#{timestamp}&key=#{key}"
На приемной стороне (вкадре.ру) будет проверка, что timestamp
отличается от текущего времени не более, чем на 5 секунд. Тогда все
равно можно залогиниться, сниффая сеть, но записи в логах будут
устаревшими.
Время, разумеется, должно быть синхронизованное и в UTC каком-нибудь.
08.11.2007, в 10:16, labria написал(а):
Maxim Kulkin
Nov 8, 2007, 3:34:32 AM11/8/07
to ror...@googlegroups.com
On Nov 8, 2007 10:36 AM, Олег Андреев <oleg...@gmail.com> wrote:
> key сейчас не уникален для данной сессии, но уникален для данного юзера.
>
> key = md5( email, id, shared_secret )
>
> Т.е. если ты будешь сниффать сеть, то сможешь поймать эту строку и
> авторизоваться от имени данного юзера. Впрочем, поскольку в поля имейл/
> пароль данные кладутся незашифрованными, их тоже можно просниффать.
>
> Есть, однако одна проблема: get-запрос может быть залоггирован
> промежуточным шлюзом, а это не очень хорошо. Поэтому можно добавить
> timestamp, который тоже будет подписываться:
>
> timestamp = Time.now.to_i
> key = md5( email, id, timestamp, shared_secret )
>
> redirect_to "...×tamp=#{timestamp}&key=#{key}"
>
> На приемной стороне (вкадре.ру) будет проверка, что timestamp
> отличается от текущего времени не более, чем на 5 секунд. Тогда все
> равно можно залогиниться, сниффая сеть, но записи в логах будут
> устаревшими.
>
> Время, разумеется, должно быть синхронизованное и в UTC каком-нибудь.
> key сейчас не уникален для данной сессии, но уникален для данного юзера.
>
> key = md5( email, id, shared_secret )
>
> Т.е. если ты будешь сниффать сеть, то сможешь поймать эту строку и
> авторизоваться от имени данного юзера. Впрочем, поскольку в поля имейл/
> пароль данные кладутся незашифрованными, их тоже можно просниффать.
>
> Есть, однако одна проблема: get-запрос может быть залоггирован
> промежуточным шлюзом, а это не очень хорошо. Поэтому можно добавить
> timestamp, который тоже будет подписываться:
>
> timestamp = Time.now.to_i
> key = md5( email, id, timestamp, shared_secret )
>
> redirect_to "...×tamp=#{timestamp}&key=#{key}"
>
> На приемной стороне (вкадре.ру) будет проверка, что timestamp
> отличается от текущего времени не более, чем на 5 секунд. Тогда все
> равно можно залогиниться, сниффая сеть, но записи в логах будут
> устаревшими.
>
> Время, разумеется, должно быть синхронизованное и в UTC каком-нибудь.
Какая-то наивная секурность.
А как же атака main-in-the-middle ? Когда первоначальный запрос
(который вы защитили от replay-атаки) не дойдет до сервера, а будет
перехвачен на пути к серверу и отослан уже от имени злоумышленника ?
Олег Андреев
Nov 8, 2007, 4:03:21 AM11/8/07
to ror...@googlegroups.com
Во-первых, от replay-атаки я его не защитил. Я защитил от
использования устаревшего запроса (задержать можно не более, чем на 5
секунд, за эти 5 секунд можно повторить запрос любое число раз).
Во-вторых, злоумышленник с равным успехом может перехватить POST-
запрос от юзера к серверу, в котором лежит незашифрованный логин/
пароль (https пока нет) и GET-запрос, где содержится временная
авторизационная информация. Вернее, эти данные он может перехватить
двумя способами:
1) Хедеры редиректа от vkontakte.ru к юзеру
2) GET запрос юзера к vkadre.ru
Иными словами, эта авторизация не более дырявая, чем обычная форма
логин/пароль, которая проходит по простому HTTP (не HTTPS).
Если делать серьезно, то ко всем редиректам нужно приписать https:// и
настроить оба сервера соответствующим образом. На механизм авторизации
это не повлияет.
// На всякий случай, поясню, вдруг кто не понял: серверы между собой
не общаются. С ними общается юзер. Ему лишь говорят по какому УРЛ
нужно идти дальше.
08.11.2007, в 11:34, Maxim Kulkin написал(а):
использования устаревшего запроса (задержать можно не более, чем на 5
секунд, за эти 5 секунд можно повторить запрос любое число раз).
Во-вторых, злоумышленник с равным успехом может перехватить POST-
запрос от юзера к серверу, в котором лежит незашифрованный логин/
пароль (https пока нет) и GET-запрос, где содержится временная
авторизационная информация. Вернее, эти данные он может перехватить
двумя способами:
1) Хедеры редиректа от vkontakte.ru к юзеру
2) GET запрос юзера к vkadre.ru
Иными словами, эта авторизация не более дырявая, чем обычная форма
логин/пароль, которая проходит по простому HTTP (не HTTPS).
Если делать серьезно, то ко всем редиректам нужно приписать https:// и
настроить оба сервера соответствующим образом. На механизм авторизации
это не повлияет.
// На всякий случай, поясню, вдруг кто не понял: серверы между собой
не общаются. С ними общается юзер. Ему лишь говорят по какому УРЛ
нужно идти дальше.
08.11.2007, в 11:34, Maxim Kulkin написал(а):
Julian 'Julik' Tarkhanov
Nov 11, 2007, 8:58:55 AM11/11/07
to ror...@googlegroups.com
On Nov 8, 2007, at 10:03 AM, Олег Андреев wrote:
// На всякий случай, поясню, вдруг кто не понял: серверы между собой
не общаются. С ними общается юзер. Ему лишь говорят по какому УРЛ
нужно идти дальше.
Если ты про openid, то там все основано как раз на том что серверы сначала общаются друг с другом и устанавливают shared secret, а потом уже юзеру сообщают куда этот shared secret нести (как ключ сигнатуры hmac).
--
Julian 'Julik' Tarkhanov
please send all personal mail to m...@julik.nl
GeniyZ
Nov 12, 2007, 1:26:30 AM11/12/07
to RubyOnRails to russian
Я, в своё время, делал это так:
На сайте X заполняешь формочку логин/пароль,
Клацаешь Submit
Этот самый X проверяет данные, и, если всё верно обращается за
авторизацией к веб сервису сайта Y, который тоже выставляет в случае
успеха кукисы, точнее он их передаёт северу X, который их и выставляет
(это было самое сложное).
При регистрации почти таким же образом дублируются пользователи. Но
это, само собой, только в том случае если базы разные используются.
Val
Nov 13, 2007, 8:39:50 AM11/13/07
to RubyOnRails to russian
Либо "на коленке" либо основываясь на SAML. Google скорее всего на
втором (http://code.google.com/apis/apps/sso/
saml_reference_implementation.html), vkadre на первом. Кстати, оба
сценария - сервера общаются друг с другом непосредственно или через
редиректы, были прописаны еще в первой версии SAML (http://
en.wikipedia.org/wiki/SAML_1.1#SAML_1.1_Profiles).
втором (http://code.google.com/apis/apps/sso/
saml_reference_implementation.html), vkadre на первом. Кстати, оба
сценария - сервера общаются друг с другом непосредственно или через
редиректы, были прописаны еще в первой версии SAML (http://
en.wikipedia.org/wiki/SAML_1.1#SAML_1.1_Profiles).
Валера
Олег Андреев
Nov 15, 2007, 7:08:22 PM11/15/07
to ror...@googlegroups.com
У меня сделано жестко для двух сайтов, поэтому shared secret прописан
в сорцах на обеих сторонах. Поэтому и серверы друг с другом не
общаются - только с юзером.
в сорцах на обеих сторонах. Поэтому и серверы друг с другом не
общаются - только с юзером.
11.11.2007, в 16:58, Julian 'Julik' Tarkhanov написал(а):
Reply all
Reply to author
Forward
0 new messages