Вход в систему: история вопроса - PullRequest
8 голосов
/ 16 января 2009

Что происходит при входе на сайт?

Я знаю, что куки хранятся, и некоторая информация (какая информация?) Отправляется на сервер ... но, может быть, более подробно?

Ответы [ 8 ]

51 голосов
/ 07 февраля 2009

Давным-давно, где-то в интернете ....

  • Браузер: «эй, могу я увидеть эту веб-страницу? Проблема в том, что я не помню, чтобы разговаривал с вами раньше»
  • Сайт: «конечно, заполните форму, мне нужно ваше имя пользователя и пароль»
  • Браузер: «Вот, пожалуйста»
  • Веб-сайт: «Отлично! Добро пожаловать, колдфыр! Вот эта страница. Посмотрите, если вам нужно больше страниц, возьмите этот токен и используйте его, когда попросите другой» *
  • Браузер: Круто. Этот сайт дал мне знак. Я запомню это!

Через несколько минут

  • Браузер: «Ох! Могу ли я увидеть эту другую веб-страницу? Вот мой токен»
  • Веб-сайт: «Этот жетон выглядит хорошо, еще раз привет koldfyre, вот ваша веб-страница»

Это, по сути, так и есть. Чтобы помнить, что пользователь вошел в систему, он дает пользователю токен, который он должен представить при следующем запросе. Обычно это достигается сервером, который указывает браузеру сохранить этот токен в файле cookie.

Delving глубже - аутентификация транспортного уровня

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

Самая простая, Базовая аутентификация HTTP , предоставляется большинством реализаций веб-сервера. Это заставляет ваш браузер открывать знакомое диалоговое окно входа в систему. «Токен» - это просто ваше незашифрованное имя пользователя и пароль в кодировке base64. Не особенно безопасно.

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

Еще глубже - аутентификация на уровне приложений

Для максимальной гибкости и контроля большинство сайтов предпочитают реализовывать авторизацию на уровне приложений, а не на транспортном уровне HTTP. Это дает более широкий выбор вариантов безопасности. Любой сайт, который запрашивает учетные данные на веб-странице (а не в диалоговом окне входа в систему браузера), использует пользовательский метод авторизации.

Пользовательские методы будут сильно отличаться в своем начальном взаимодействии, но они почти всегда приводят к тому, что пользователю дается cookie сеанса, содержащий случайно сгенерированный идентификатор. Затем браузер автоматически представляет файл cookie при каждом последующем запросе. Веб-приложение проверит значение файла cookie, чтобы убедиться, что оно все еще действует.

Также возможно передать авторизацию доверенной третьей стороне, как правило, для предоставления какой-либо услуги единого входа. В таких случаях, когда вы замечаете, что пользователь не аутентифицирован, вы отправляете его поставщику аутентификации. Они аутентифицируют их и будут возвращены вам с каким-то токеном, который вы проверите у провайдера. Shibboleth является одним из примеров этого. Вы также зашли на этот сайт, используя аналогичный метод, используемый OpenID

Дальнейшее чтение

Вот несколько хороших ответов от аналогичный вопрос

Другие ответы на этот вопрос дают еще больше ссылок на ваше образование!

11 голосов
/ 16 января 2009

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

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

На многих веб-сайтах, например, для банковских услуг, вы также хотите гарантировать, что обмен данными не может быть перехвачен третьей стороной. Если это так, вы устанавливаете безопасное соединение, используя протокол, известный как SSL или TLS. Это добавляет к основному соединению обмен информацией, который устанавливает сеансовый ключ . Этот сеансовый ключ затем используется для шифрования сообщений. Обычно это происходит за до того, как вы обменяете имя пользователя и пароль, так что ваш пароль никогда не будет виден злонамеренной третьей стороне.

Под прикрытием, когда вы устанавливаете безопасное соединение, веб-сайт отправляет вашему браузеру блок отформатированных данных, называемый x509 сертификат . Это еще одна форма аутентификации; сертификат будет подписан эмитентом ( центр сертификации или "CA"), и браузер может использовать сохраненные данные о центрах сертификации, чтобы гарантировать подлинность сертификата.

5 голосов
/ 16 января 2009

Это полностью зависит от реализации сайта. Даже использование куки не обязательно, но очень распространено.

Однако в большинстве случаев происходит нечто подобное:

  • Вы отправляете свое имя пользователя и пароль, используя форму HTML.
  • Сервер ищет соответствующего пользователя (используя базу данных)
  • Сервер проверяет, совпадает ли пароль с паролем, который хранится в базе данных рядом с пользователем.
  • Если пароль правильный, сервер сохранит, какой пользователь в данный момент активен в сеансе. Идентификатор этого сеанса хранится в файле cookie, фактические данные этого сеанса (текущего пользователя) хранятся на сервере под этим идентификатором.

Теперь вы вошли в систему. Вы останетесь в системе до конца сеанса:

  • Когда вы запрашиваете другую страницу с сервера, вы отправляете куки с идентификатором сезона.
  • Сервер загружает сеанс, используя этот идентификатор. В этом сеансе текущий пользователь сохраняется, поэтому сервер знает, какой пользователь вошел в систему.
3 голосов
/ 08 февраля 2009

При входе на веб-сайт сначала проверяются ваши учетные данные. Если ваши учетные данные совпадают, то в сеанс (на сервере) что-то добавляется, чтобы отследить, кто вы, чтобы вы могли получить доступ к вашим данным без повторной регистрации. Это, очевидно, бесполезно на веб-сервере, если только клиент не может предоставить информацию о том, кем он является в каждом запросе. Обратите внимание, что «Сеанс» обычно полностью поддерживается на веб-сервере, и клиент имеет только ключ, который разрешает доступ к сеансу.

Помните, что сам HTTP является протоколом без сохранения состояния. Стандарт HTTP не содержит методов для запросов HTTP, чтобы сохранять или сохранять какое-либо состояние между отдельными запросами HTTP. Таким образом, состояние обычно полностью хранится на сервере, и вам просто нужен метод, чтобы клиент мог определить, к какому сеансу относится текущий HTTP-запрос.

Два распространенных способа сделать это:

  • Используйте cookie (например, Apache Tomcat использует JSESSIONID cookie) для хранения некоторого хешированного токена аутентификации, который успешно выполнит поиск веб-сеанса, или
  • переписать URL-адрес, чтобы к каждому запросу добавлялся идентификатор сеанса в конце запроса. Все еще используя Apache Tomcat в качестве примера, если куки отключены, тогда URL будет переписан так, чтобы он заканчивался строкой, подобной «;jsessionid=....». Таким образом, каждый запрос, каждый HTTP GET и POST (и остальные) будут заканчиваться этой строкой.

Таким образом, при каждом запросе, который клиент делает, идентификатор сеанса предоставляется веб-серверу, что позволяет быстро просматривать постоянное состояние этого клиента, позволяя HTTP действовать как протокол с отслеживанием состояния.

Какая информация отправляется на сервер при входе в систему? Какую бы информацию вы не указали в форме входа. Некоторые веб-серверы также отслеживают адрес TCP / IP, с которого поступил запрос, чтобы избежать атак перехвата сеанса . Обычно это вся информация, которая нужна серверу.

Если вы не разрешаете браузеру сохранять куки, то вам придется входить на веб-сервер каждый раз, когда вы открываете браузер и первоначально открываете веб-страницу сервера. Однако, если вы разрешаете браузеру сохранять файлы cookie, многие серверы позволяют вам сохранять файлы cookie (т. Е. Не просто использовать файлы cookie сеанса), чтобы при каждом переходе на веб-страницу сервера сохранялся файл cookie. будет идентифицировать вас, поэтому вам не нужно повторно войти в систему. Здесь файл cookie сохранит достаточно информации - часто в зашифрованном виде, которую сможет понять только сервер, - чтобы идентифицировать вас. В этом случае Cookie - это не простой идентификатор сеанса.

1 голос
/ 12 февраля 2009

Существует два основных способа выполнения аутентификации в Интернете и несколько менее популярных способов, о которых также стоит знать.

Первым является HTTP-аутентификация, как определено RFC 2617 . Когда вы запрашиваете защищенную страницу, сервер отвечает кодом состояния 401, сигнализирующим, что у вас нет доступа к ресурсу. В дополнение к этому он также отправляет заголовок WWW-Authenticate, который указывает браузеру, как он хочет, чтобы вы авторизовались самостоятельно. Браузер видит этот код состояния и заголовок и запрашивает ваши данные для аутентификации. Когда вы вводите их, ваш браузер подготавливает их в соответствии с определенной схемой аутентификации, указанной сервером, и снова запрашивает страницу, включая заголовок Authorization с подготовленными данными. Сервер проверяет эти данные в своей пользовательской базе данных и отвечает либо другим 401 (неверные данные), либо защищенной страницей с сопровождающим кодом состояния 200, указывающим на успех.

HTTP-аутентификация - это одна из тех древних функций, которые браузеры с самого начала плохо реализовали и которые никогда не были улучшены. Из-за этого веб-разработчикам стало гораздо популярнее самостоятельно выполнять аутентификацию с использованием файлов cookie для сохранения состояния. В этом случае пользователю предоставляется стандартная HTML-форма. Когда пользователь вводит свои учетные данные в поля и отправляет форму, браузер кодирует ее и отправляет на сервер так же, как она кодирует любую обычную HTML-форму. Сервер проверяет учетные данные и, если они являются законными, устанавливает cookie со случайно сгенерированным идентификационным номером вместе с соответствующей записью базы данных / файловой системы, которая распознает этот идентификационный номер как принадлежащий конкретному пользователю.

С этого момента каждый запрос браузера к серверу включает этот cookie-файл с идентификатором в качестве заголовка HTTP. Сервер распознает cookie, ищет идентификационный номер и знает, каким пользователем вы являетесь. Когда вы решите выйти из системы, сервер отправляет ответ с просьбой, чтобы ваш браузер забыл идентификационный номер, после чего вы просто еще один анонимный пользователь.

Менее часто используемым вариантом является использование клиентских сертификатов SSL. Многие люди знакомы с идеей использования SSL для идентификации сервера. Криптографическая пара ключей генерируется, подписывается доверенным органом и используется для подтверждения того, что отправляемые данные исходили от владельца пары ключей. Однако многие люди не знают, что клиент может использовать то же самое для подтверждения своей личности на сервере. Однако это менее удобно, поскольку вам необходимо иметь при себе сертификат, если вы хотите использовать его на нескольких компьютерах.

Конечно, есть варианты и менее известные варианты, но это самые выдающиеся.

1 голос
/ 11 февраля 2009

Очень просто объяснил, что происходит, упоминается ниже:

Что входит?

  • Имя пользователя
  • Пароль

Что происходит внутри?

  1. Пароль преобразован в его хэш
  2. Хэш (пароль) равен по сравнению с таблицей БД или службой каталогов (если кто-то не по-настоящему глуп, сайт не сохранит ваш пароль в открытом виде)
  3. Если Аутентифицировано, Токен состояния хранится в сеансе и / или cookie.
    • Этот токен может просто содержать статус, метки времени входа в систему, ваш userId, userType (если есть) и др.
    • Этот токен читается и проверяется на каждой странице, к которой вы обращаетесь, если на этой странице требуется, чтобы вы вошли в систему как пользователь определенного типа.
  4. Если аутентификация не удалась , вы будете перенаправлены на страницу с сообщением об ошибке с просьбой повторно войти в систему.

Что выходит

  1. Вы перенаправлены на страницу своего личного профиля / на страницу, на которую вы заходили, и проверяет вас с помощью токена.
  2. Кроме того, цифровой сертификат может появиться на картинке, если вы заходите на банковский сайт или другой критически безопасный сайт
0 голосов
/ 12 февраля 2009

Послушайте, немного сложно дать вам гораздо больше информации, которая у вас уже есть; Я не уверен, почему вы хотите назначить награду за это. Файл cookie - это всего лишь небольшая часть именованной информации, и вы можете поместить в нее все, что захотите. Для сеанса вы бы хотели некоторый вид идентификатора сеанса. Есть соглашения для этого, или вы можете сделать это самостоятельно. Что бы вы ни делали, когда вы устанавливаете cookie, вы оставляете в браузере этого человека немного данных, примерно таких:

mydomain.com:
    mystuff: this is my stuff, by golly.

Когда вы возвращаетесь, вы извлекаете печенье и получаете его обратно.

Если вы хотите увидеть все подробности этого протокола, взгляните на статью Википедии .

0 голосов
/ 08 февраля 2009

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

function login(username, password) {
    user = db->get_user(username)

    if (user == false) {
        report_error("Unknown username")
        exit
    }

    if (user->password != hash(password)) {
        report_error("Incorrect password")
        exit
    }

    // User authenticated, set session cookie
    session->set_data('current_user', user->username)
}

Конечно, в большинстве случаев это немного больше, чем это, но каждая функция входа в систему начинает свою жизнь, по сути, как описано выше. Теперь, если мы добавим в смесь автологин («помни меня»), мы получим что-то вроде этого:

function login(username, password, remember_me) {
    user = db->get_user(username)

    if (user == false) {
        report_error("Unknown username")
        exit
    }

    if (user->password != hash(password)) {
        report_error("Incorrect password")
        exit
    }

    // User authenticated, set session cookie
    session->set_data('current_user', user->username)

    if (remember_me == true) {
        cookie_token = random_string(50)
        set_cookie('autologin_cookie', cookie_token, ONE_MONTH)
        // Finally, save a hash of the random token in the user table
        db->update_user(user, 'autologin_token', hash(cookie_token))
    }
}

Плюс функция автоматического входа в систему при наличии файла cookie:

function cookie_login() {
    cookie = get_cookie('autologin_cookie')

    if (cookie == false) {
        return false
    }

    // Only for demonstration; cookie should always include username as well
    user = db->get_user_by_cookie(cookie)

    if (user == false) {
        // Corrupt cookie data or deleted user
        return false
    }

    // User authenticated, set session cookie
    session->set_data('current_user', user->username)
    return true
}

ПРИМЕЧАНИЕ: Вышеуказанный подход не является «наилучшей практикой» и не очень безопасен. В рабочем коде вы всегда включаете идентификатор пользователя в данные cookie, используете несколько уровней регулирования, сохраняете данные при неудачных и успешных входах в систему и т. Д. Все это было удалено, чтобы упростить базовую структуру аутентификации.

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

P.S .: Вы также можете проверить вопрос " Полное руководство по аутентификации веб-сайта ", чтобы узнать о передовых методах

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...