что такое Auth_key.
AUTH, аутх, auth_key – это ключ, необходимый для авторизации пользователя на стороннем сервере приложения. Грубо говоря это «логин: пароль» от конкретного приложения. Для каждого приложения у пользователя различный Auth.
Вычисляется по формуле:
auth_key = md5(api_id + ‘_’ + viewer_id + ‘_’ + api_secret)
Сейчас многие боты и программы не требуют Вашего пароля от ВКонтакте. Необходимо лишь указать Auth от приложения и Ваш ID.
Как отыскать Auth-key?
Существует несколько способов. Вот самый простой:
На примере браузера GoogleCrome.
Запускаем необходимое приложение и жмем в любом пустом месте страницы Правую кнопку мыши и выбираем пункт Просмотр кода страницы.
PS: Для других браузеров ищем нечто похожее на «исходный код страницы»
PPS: Так же в некоторых браузерах достаточно войти на страницу с приложением и нажать Ctrl+U.
После проделанного выше появитс страница с исходным кодом. теперь в ней необходимо найти Auth.
Нажимаем Ctrl+F что бы упростить поиск.
Вконтакте
Ищем auth_key.
Среди множества непонятных символов найдется волшебная строчка вида «auth_key»:»e6b84623c311f08f15e8263dd2f3a48a» где e6b84623c311f08f15e8263dd2f3a48a и есть Ваш Auth-key.
MailRu
Ищем authentication_key.
Среди множества непонятных символов найдется волшебная строчка вида «authentication_key»:»e6b84623c311f08f15e8263dd2f3a48a» где e6b84623c311f08f15e8263dd2f3a48a и есть Ваш Auth-key.
Auth Key. Что такое auth key?
Auth Key. Что такое auth key?
Auth key, как правило, используется для авторизации пользователя на сторонних серверах. К примеру, социальная сеть «Вконтакте» запустила игру «Тюряга». Эта игрушка работает на ресурсе, который не имеет отношение к сайту «Вконтакте». Однако ресурс предоставил свои услуги и место для размещения приложения «Тюряга». В итоге получается, что Вы, войдя в социальную сеть с помощью своих данных, при переходе в игру остаётесь неизвестным гостем для сервера этого приложения. Поэтому, чтобы начать играть, необходимо также авторизоваться на сайте, где расположена сама игра.
В силу этого и был создан auth key. Простыми словами, можно сказать, что данный ключ – это логин и пароль стороннего приложения. Следовательно, для разных приложений конкретному пользователю присваиваются персональные ключи auth key. При этом во время авторизации на стороннем ресурсе, как правило, требуется указать не только персональный ключ, но и ID номер. Это и является главным отличием auth key от привычных для нас логина и пароля.
С назначением ключа разобрались. Оказывается не такой уж он загадочный. Теперь неплохо было бы понять: «А где, вообще, хранится этот auth key? И можно ли его найти?» Найти можно. Всё очень просто. Также как и все элементы сайта, ключ авторизации спрятан непосредственно в коде страницы ресурса, на котором размещено стороннее приложение. Чтобы понять, как его найти, обратимся к популярному браузеру «Chrome». С помощью этого WEB-обозревателя запускаем интересующее нас приложение и однократным кликом правой кнопки мыши в любом месте страницы вызываем всплывающее меню. В нём следует выбрать пункт под названием «Просмотр кода страницы». Нашему вниманию будет представлена страница с множеством непонятных символов. Естественно, во всём этом разбираться не надо. Достаточно нажать клавиши Ctrl+F, и ввести в появившемся поле начальные буквы интересующего элемента. В нашем случае вводим «auth». После этого на странице кода выделится ярким цветом слово, введённое в поле. Примерный вид нужной строки будет таким: «auth_key»: «e6b84623c311f08f15e8263dd2f3a48a». Здесь e6b84623c311f08f15e8263dd2f3a48a и есть тот самый Auth-key.
Во всех браузерах, отличных от Chrome, процедура поиска auth key почти одинаковая. Основное отличие в том, что при нажатии правой кнопки мыши во всплывающем меню вместо пункта «Просмотр кода страницы» может быть, что-то другое, но по смыслу похожее. В некоторых WEB-обозревателях код страницы можно просмотреть, нажав одновременно клавиши Ctrl+U. В остальном, последовательность действий та же, что описана в приведённом выше примере.
Вы еще не авторизуетесь по ключам? Тогда мы идем к вам
Этой заметкой я хочу показать, что использовать ключи для авторизации это просто.
Начнем с того, что нам понадобится PuTTY.
Идем на http://www.chiark.greenend.org.uk/
sgtatham/putty/download.html и качаем следующее:
PuTTY — ssh-клиент
Pageant — агент для хранения ключей (зачем объясню позже)
PuTTYgen — генератор ключей
Сначала сгенерируем ключи, потом настроим PuTTY, и в конце покажу как всем этим пользоваться.
Создадим папочку для PuTTY и все скинем туда. 
Запускаем PuTTYgen выбираем «Type of key to generate» SSH-2 RSA и 2048-битный ключ.
Жмем Generate. Следуя указациям, хаотично перемещаем мышку.
После генерации нам предстанет следующее.
В верхнем поле публичный ключ, который будет храниться у принимающей стороны.
Ах да, я забыл рассказать как происходит непосредственная авторизация с помощью ключей.
Для наглядности возьмем server и client.
client сообщает server’у свой публичный ключ любым доступным способом. Беспокоиться, что кто-то узнает этот ключ не стоит.
Авторизация происходит следующем образом:
дальше следует объяснение человека, который не читал соответствующей литературы, поэтому описывает так, как он себе это представляет
client обращается к server’у и они обмениваются публичными ключами.
на основании этого server авторизует client’а, дает соответствующие права.
Это было небольшое отступление, вернемся к PuTTYgen.
В верхнем поле публичный ключ, который будет храниться у принимающей стороны.
Key fingerprint — отпечаток ключа.
Key comment — комментарий к ключу, я обычно указываю машину, на которой это ключ используется.
Key passphrase — парольная фраза к приватному ключу. Ее следует сделать сложной. Конечно можно оставить пустой, и тогда при авторизации не будет требоваться пароль, но дальше я покажу, что даже с сложным паролем к ключу можно авторизовываться без повторного ввода пароля, будто пароля и нет.
Confirm passphrase — подтверждение парольной фразы.
Дальше нужно сохранить сгенерированные ключи. Остановлюсь только на приватном ключе. При сохранении (Save private key) предложится сохранить ключ с расширением .ppk. Он будет использоваться Pageant в дальнейшем.
Перед тем, как мы перейдем к настройке PuTTY, расскажу о возможности восстановить публичный ключ из приватного с помощью PuTTYgen.
Для этого нужно нажать кнопку Load. Указать приватный ключ. Ввести парольную фразу (если имеется) и отобразится точно такое же окно, как на предыдущем скриншоте.
Теперь запустим PuTTY и сделаем предварительные настройки.
Выберем Default Settings и нажмем Load.
Перейдем слева на Session->Logging, отметим галочкой Printable output. В поле Log file name впишем logs\&H_&Y-&M-&D-&T.log, уберем галочку Flush log file frequently.
Таким образом, мы указали, что хранить логи будем в папочке logs, рядом с PuTTY.exe с именами на подобии 192.168.1.6_2011-08-29-101304.log
Перейдем на вкладку Window->Translation. И выберим в списке Remote character set UTF-8, чтобы не было проблем с кодировкой.
В Connection->SSH->Auth проверим, что стоит галочка напротив Attempt authentication using Pageant и укажем путь к приватному ключу в графе Private key file for authentication.
После этого вернемся на вкладку Session нажмем сохранить, чтобы указанные настройки были по-умолчанию.
Пришло время показать работу авторизации, используя ключи, на практике.
Воспользуемся агентом для хранения ключей Pageant.
После запуска, появится иконка в области уведомлений. Жмем правой кнопкой, Add key.
Выбираем ключ, указываем парольную фразу. Теперь ключ хранится в памяти.
Чтобы посмотреть ключи, можно выбрать пункт View keys.
Попробуем авторизоваться.
Открываем PuTTY. Указываем IP. Жмем Open.
В первый раз выскочит предупреждение, что раньше мы не использовали ключ для авторизации на этом сервере. Когда такое возникает впервый раз, это нормально, но если такое возникает на сервере, на котором мы уже авторизовывались, то либо сервер сменил свои ключи, либо это фейковый сервер.
Вводим логин. Жмем Enter. И мы автоматически авторизовались.
Покажу еще, на примере Komodo Edit.
Выбираем File->Open->Remote open
Выбираем Accounts. Потом New Server.
В Server Type указываем SCP. В Name произвольное название для сервера. В Hostname ip сервера (или доменное имя). В User Name логин пользователя.
Жмем Add, затем OK.
В верхнем выпадающем меню выбираем наш сервер. Если сервер разрешает авторизацию по ключам, то мы увидим список директорий на сервере, выбираем нужный файл и редактируем (при наличии прав на запись у пользователя).
PS: Следующая ошибка появляется в том случае, если сервер поддерживает только авторизацию по ключам, а у вас не включен Pageant.
Создание ключа авторизации
Последовательность действий
Прежде чем отсылать незашифрованные сообщения (в данном случае — необходимые для создания авторизационного ключа), клиент должен пройти «(p,q)-авторизацию» следующим образом:
Вычисление nonce
Клиент шлёт серверу запрос:
Значение nonce выбирается клиентом произвольно (случайное число); оно идентифицирует клиента в рамках данного обмена. После этого шага оно известно всем.
Ответ сервера
Сервер отправляет ответ в виде:
Здесь «строка» pq представляет собой запись натурального числа (в двоичной системе в формате big-endian). Это число является произведением двух различных нечетных простых чисел. Обычно pq не превосходит 2^63-1. Значение server_nonce выбирается сервером произвольно; после этого шага оно известно всем.
Доказательство выполнения работы
Отправка серверу и аутентификация
Клиент отправляет запрос:
Здесь encrypted_data получается следующим образом:
Альтернативная форма внутренних данных ( p_q_inner_data_temp ) используется для создания временных ключей, которые сохраняются только в RAM сервера и стираются не более чем через expires_in секунд. Сервер свободно может стереть эту копию раньше. Во всех остальных отношениях протокол генерации временных ключей такой же. После того как временный ключ создан, клиент обычно привязывает его к основному ключу авторизации посредством метода auth.bindTempAuthKey и использует его для всех коммуникаций клиент-сервер до того как его срок истечёт; затем генерируется новый временный ключ. Таким образом в коммуникации клиент-сервер достигается Perfect Forward Secrecy.
Сервер отвечает двумя способами:
Здесь encrypted_answer получается таким образом:
После этого шага new_nonce всё ещё известно только клиенту и серверу. Клиент уверен, что ответил именно сервер и что ответ сгенерирован специально в ответ на запрос клиента req_DH_params, поскольку данные ответа шифруются с использованием new_nonce.
От клиента ожидается проверка того, является ли p = dh_prime верным 2048-битным простым числом (имеется в виду, что и p и (p-1)/2 являются простыми числами, и что 2^2047 encrypted_data получается таким образом:
Поле retry_id равняется нулю во время первой попытки; или равняется auth_key_aux_hash от предыдущей зафейленной попытки (см. пункт 9).
Вычисление auth_key
Вычисление auth_key_hash
auth_key_hash вычисляется := 64 бита нижнего порядка SHA1 (auth_key). Сервер проверяет, если ли уже другой ключ с таким же auth_key_hash и отвечает одним из следующих способов.
Завершение обмена ключами
Сервер отвечает одним из трёх способов:
В другом случае, клиент обращается к пункту 6) генерируя новое b.
Обработка ошибок
В том случае, если клиент не получает никакого ответа от сервера на свой запрос в течение какого-то времени, он может просто повторить запрос. Если сервер уже отправлял ответ на этот запрос (ровно на этот запрос, а не на такой же — все параметры при повторе должны принимать то же значение), но он не дошел до клиента, сервер просто повторит тот же ответ. Сервер помнит ответ до 10 минут после момента получения запроса 1). Если же сервер уже забыл ответ или необходимые временные данные, клиенту придется начать все с самого начала.
Сервер вправе считать, что если клиент уже прислал следующий запрос, использующий данные из предыдущего ответа сервера данному клиенту, то этот ответ заведомо получен клиентом и сервер может его забыть.
Пример использования
Пример полного списка запросов, необходимый для генерации ключа авторизации, показан на отдельной странице: «создание ключа авторизации — примеры».
Сайт про Telegram на русском (неофициальный).
Здесь собраны приложения на базе MTProto, переведена некоторая документация с официального сайта, а также работает Webogram.
Мы используем сервисы в интернете, чаще всего даже не зная, каким образом они устроены и функционируют. Не задумываясь, как передается информация о нас между тем или иным сервисом, мы просто делаем переходы с сайта на сайт, с одного приложения в другое. При этом, конечно же, между тем или иным сервером проходит моментальный обмен информацией. Чтобы дать вам знать немного больше о том, как устроена передача информации в интернете, мы пишем эту статью. В ней мы расскажем, что такое auth key, где это применяется и какова его роль в повседневной работе каждого из нас.
Итак, как можно понять из самого сокращения, полной формой этого термина является словосочетание «authorization key», что с английского переводится как «ключ авторизации». Такое название в полной мере отображает роль этого механизма и его сущность. Ключ сам по себе является генерированным из 32 случайных символов кодом, который используется для авторизации пользователя на сторонних сервисах.
Где применяется передача auth key?
После того как разобрались, что такое auth key, следует уточнить сферу его применения. На примере вы сможете разобраться в этой категории подробнее и яснее, чем просто прочитав определение.
Идентификационный номер (id) auth key применяется в наиболее распространенном виде в случае работы социальных сетей и приложений, которые работают на их платформе.
Не секрет, что все игры и приложения, доступные нам в сети «ВК» созданы не администраторами «Вконтакте», а сторонними разработчиками. Это значит, что какая-нибудь игра размещена физически не на серверах социальной сети, а где-нибудь отдельно.
Как узнать мой auth key?
Примерно вы разобрались в том, что из себя представляет auth key. Как посмотреть его, и можно ли это сделать, рассмотрим в этом пункте нашей статьи.
Итак, поскольку авторизационный ключ передается между сетью и приложением при помощи вашего браузера, вы, конечно же, можете его найти и увидеть собственными глазами. Тем более, что эта характеристика не меняется и является вашим уникальным ключом при работе с социальными сетями (и не только).
Почему не стоит публиковать свой auth key где попало?
