Что такое авторизация в компьютере
Хочется собрать все известные на сегодняшний день «простые» методы авторизации/регистрации на веб-ресурсах и их особенности в одном месте. (простые — в смысле не требующие специальных устройств, например смарт карт, устройств для сканирования отпечатков пальцев, сетчатки глаз и т.д.) Что ж, попробуем…
На данный момент мне известны такие способы:
1. Простая авторизация на сайте
Встречается повсеместно, естесственно возможна только после регистрации на конечном ресурсе, а для осуществления обычно требуется пара логин-пароль, предоставляемая пользователем.
Плюсы: простота реализации, надежность.
Минусы: для разных сайтов разные учетные данные, которые нужно запоминать, и не всегда это удается.
Ну это из более-менее популярных. Теперь рассмотрим «экзотику»:
3. Enum — авторизация
Суть метода: привязка «аккаунта» мобильному телефону, номеру. При регистрации на сайте такого провайдера пользователю выдается ссылка, по которой он устанавливает java-приложение себе в телефон. Для авторизации, на сайтах поддерживающих этот метод пользователь вводит свой адрес электорнной почты, сайт в ответ показывает пользователю число, которое необходимо ввести в ранее установленное приложение. После ввода контрольного числа на экране мобильного телефона отображается число-результат, которое затем необходимо ввести обратно на сайт, на котором происходит авторизация.
Чем-то напоминает OpenID, поэтому и наследует некоторые его особенности:
Плюсы решения: простота реализации и пользования, безопасность (метод исключает перехват учетных данных, пригодных для повторной авторизации)
Минусы: малое распространение метода, привязка к телефону, который может быть украден или потерян, или просто может не находиться рядом в нужный момент. Пример enum-провайдера
6. «Разовая» авторизация по ссылке
Сразу пример: после обычной регистрации на каком-нибудь форуме, на указанный электронный адрес высылаестя письмо со ссылкой — подтверждением адреса. Ссылка работает только один раз, цель у нее тоже одна — подтвердить что именно хозяин этого адреса зарегистрировался на том форуме, но при этом иногда при переходе по такой ссылке пользователь попадает сразу в свой аккаунт, не вводя логин и пароль, что тоже удобно. Подобный метод используется также для сброса пароля. В общем тоже метод авторизации.
Выводы:
Некоторые из этих методов чем-то похожи друг на друга, но обладают различным набором достоинств и недостатков. При этом 2 — 6 метод никак не обходятся без первоначальной «простой» регистрации и авторизации.
А это я все к чему? А к тому, что создавая очередной проект, вопрос авторизации/регистрации пользователей нужно хорошо продумывать.
ЗЫ Жду конструктивной критики.
UPD:
Всем спасибо за комментарии и исправления, также прошу прощения, что не смог принять активного участия в обсуждении — не было возможности из-за учебы. :)
Процесс авторизации компьютера в программе iTunes применяется для определения компьютеров, имеющих право проводить синхронизацию данных, загружать приобретенные книги, музыку и фильмы после покупки в магазине приложения. Эта функция также позволяет включать определенные опции управления домашней коллекцией пользователя.
- Как авторизовать компьютер
- Как деавторизоваться в itunes
- Как зарегистрировать компьютер
Укажите пункт «Авторизовать этот компьютер» в меню «Магазин» верхней панели инструментов окна программы и введите идентификатор Apple ID и свой пароль в соответствующие поля открывшегося окна запроса.
Повторите этот алгоритм действий для каждой учетной записи, подлежащей авторизации и завершите работу приложения iTunes.
Выберите пункт «Деавторизовать этото компьютер» и укажите свой идентификатор Apple IВ в соответствующих полях окна запроса при необходимости деавторизации выбранной учетной записи или перейдите в пункт iTunes Store в верхней панели инструментов окна приложения для выполнения деавторизации всех компьютеров, связанных с выбранным идентификатором.
Укажите раздел «Учетная запись» и используйте существующие идентификатор и пароль в соответствующих полях окна запроса.
Повторите нажатие кнопки «Учетная запись» для отображения данных идентификатора Apple ID на кнопке и повторите введение необходимых сведений.
Используйте учетную запись администратора компьютера для авторизации покупок, сделанных в магазине iTunes. Для этого выполните вход в систему через аккаунт администратора и авторизуйте компьютер. Завершите работу приложения iTunes и осуществите выход из системы. Используйте аккаунт пользователя для повторного входа и воспроизведения покупок.
Наиболее слабое звено в цепи компьютерной безопасности - это сам пользователь. Наличие установленного на компьютере.
Процесс авторизации при каждом входе на сайт или в программу порой отнимает лишнее время. Для тех, кому неудобно каждый раз вводить свой логин и пароль, придумана функция автоматической авторизации. Также в последнее время получила распространение функция входа через социальные сети, что значительно сокращает время, которое вы обычно тратите на регистрацию.
- Как поставить авторизацию
- Как сделать авторизацию
- Как авторизоваться на сайте
Если вы хотите добавить автоматическую авторизацию на каком-либо сайте, введите свои данные для входа в соответствующие поля, поставьте галочку в пункте «Автоматический вход при каждом посещении», выберите в появившемся окне браузера нужные параметры сохранения логина и пароля и нажмите «Ок».
Воспользуйтесь функцией автоматической авторизации через социальные сети, которая сейчас доступна на большинстве сайтов. Это может быть Twitter, Facebook, Myspace, Vkontakte и так далее. Найдите на странице входа на сайт пиктограмму, соответствующую социальной сети, в которой у вас имеется учетная запись. Нажмите на нее, в появившемся окне разрешите интеграцию сервисов.
Если вам нужно настроить автоматическую авторизацию в qip, откройте окно конфигурации, нажав на пиктограмму с изображением клиента, перейдите в появившемся окне на общие параметры. Первый сверху пункт отвечает за автоматический вход в систему, настройте его согласно собственным предпочтениям.
Выполните настройку автоматического входа в клиент Miranda, открыв настройки программы. Выберите пункт меню «Статус», поставьте автоматический вход и автоматическое подключение при запуске программы. Примените изменения.
Если вы хотите сделать автоматическую авторизацию для программы ICQ, тогда просто поставьте галочки при входе на пунктах «Запомнить пароль» и «Автоматический вход».
Включите функцию автозаполнения полей браузера. Для этого просто откройте настройки программы и найдите соответствующий пункт меню. Имейте в виду, что при этом ваш логин и пароль будут доступны для входа другим пользователям вашего компьютера. В основном информация о пароле находится в зашифрованном виде, однако в Мозилле, например, доступен его просмотр в обычном виде, поэтому используйте для работы мастер-пароль.
За время работы архитектором в проектах внедрения IdM я проанализировал десятки реализаций механизмов авторизации как во внутренних решениях компаний, так и в коммерческих продуктах, и могу утверждать, что практически везде при наличии относительно сложных требований они сделаны не правильно или, как минимум, не оптимально. Причиной, на мой взгляд, является низкое внимание и заказчика и разработчиков к данному аспекту на начальных этапах и недостаточная оценка влияния требований. Это косвенно подтверждает повсеместное неправильное использование термина: когда я вижу словосочетание «двухфакторная авторизация», у меня начинаются боли чуть ниже спины. Ради интереса мы проанализировали первые 100 статей на Хабре в выдаче по запросу «авторизация», результат получился неутешительный, боли было много:
В более чем 80% случаев термин употребляется неверно, вместо него следовало бы использовать слово «аутентификация». Далее я попытаюсь объяснить что это такое, и почему крайне важно уделить особое внимание этой теме.
Что же это такое?
Авториза́ция (англ. authorization «разрешение; уполномочивание») — предоставление определенному лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.
С точки зрения любой информационной системы это процесс принятия решения о предоставлении доступа субъекту на выполнение операции на основании каких-либо знаний о субъекте. К этому моменту субъект, как правило, уже должен быть идентифицирован (мы должны знать, кто он) и аутентифицирован (подтверждена его идентичность).
Реализация авторизации при разработке корпоративной информационной системы или продукта, ориентированного на корпоративный сектор — очень сложная и ответственная задача, которой часто уделяется недостаточное внимание на этапе проектирования и первичном этапе разработки, что в будущем ведет к «костыльной» реализации.
Пути решения
Решить данную задачу нам помогают разработанные модели управления доступом:
MAC — мандатная модель управления доступом. Доступ субъекта к объекту определяется его уровнем доступа: уровень доступа субъекта должен быть не ниже уровня секретности объекта.
DAC — прямое управление доступом. Доступ субъекта к объекту определяется наличием субъекта в списке доступа (ACL) объекта.
RBAC — ролевая модель управления доступом. Доступ субъекта к объекту определяется наличием у субъекта роли, содержащей полномочия, соответствующие запрашиваемому доступу.
АВАС — атрибутивная модель управления доступом. Доступ субъекта к объекту определяется динамически на основании анализа политик учитывающих значения атрибутов субъекта, объекта и окружения. Сюда же относятся PBAC, RAdAC, CBAC, с некоторыми нюансами (шикарный обзор от CUSTIS).
Их крайне рекомендуется использовать в первозданном виде, не изобретая велосипед. Достаточно часто в сложных информационных системах используется комбинация моделей. Например, популярна комбинация ACL + RBAC, когда роль включается в список доступа. Однако, правильное применение готовых моделей — тоже не простая задача. Не всем удается правильно выбрать модель, отделить ее от бизнес-логики и достичь приемлемой производительности механизма авторизации.
Для реализации озвученных выше в разделе «Проблематика» требований, на первый взгляд, я бы выбрал комбинацию PBAC + ACL. Требования могли бы быть реализованы следующим образом:
Требование от бизнеса | Решение | |
---|---|---|
1 | Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе | Тут напрашивается ACL, поскольку определить отношение пользователя к бизнес-процессу достаточно сложно, не записывая его в какой-то список в момент вовлечения. Это будет оптимальным решением с точки зрения производительности чтения относительно реализации с помощью политик. |
2 | Автор договора должен видеть его на всех этапах | Требование может быть реализовано обоими механизмами, но оптимальным я считаю ACL, поскольку в этом случае будет проще реализовать требование №3 от ИБ. |
3 | Создавать договор имеет право пользователь с грейдом не ниже 10 | Это политика (PBAC), без вариантов |
4 | Визирующий должен видеть договор начиная с поступления к нему на этап и далее | ACL будет оптимален |
5 | Руководители подразделений должны видеть договоры своих подразделений вниз по иерархии | Замечательная задача для PBAC, но его применение может снизить производительность чтения, а требования 1 и 2 от ИБ потребуют дополнительных усилий, поэтому стоит подумать над реализацией. |
6 | Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования | PBAC справится отлично |
7 | Руководство и секретариат головного офиса должны видеть документы всех филиалов | PBAC, с теми же ограничениями что и в п. 5 |
8 | Пользователь, создавший договор, не должен иметь права его завизировать | Это требование можно было бы закрыть с помощью PBAC, однако так делать не стоит. Это то самое место, где авторизация вступает в конфликт с бизнес-логикой, и если происходит такая ситуация, ответственность стоит отдать бизнес-логике. |
Перечисленные требования ИБ без всяких проблем реализуются с использованием ACL, однако бизнес-требования 5 и 7 мы реализуем с помощью PBAC. Так что для реализации требований ИБ 1 и 2 придется добавить к ним журнал или аналогичный механизм, поскольку при всей своей красоте динамические правила плохо аудируются:
Требование от ИБ | Решение | |
---|---|---|
1 | Знать, кто имеет доступ к конкретному договору | Общий журнал для ACL и PBAC |
2 | Знать, кто имел доступ к конкретному договору в заданный момент времени | Общий журнал для ACL и PBAC |
3 | Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей | ACL |
Проблематика
Давайте разберемся, какие требования к авторизации встречаются, и почему их крайне важно учитывать изначально при проектировании системы, а не откладывать на будущее. Источников требований к авторизации в корпоративной информационной системе, как правило, два — это бизнес и информационная безопасность. В общем случае бизнес хочет хранить секреты в тайне и предоставлять полномочия пользователям в соответствии с их функцией в бизнес-процессе, а безопасность хочет обеспечить минимальную достаточность полномочий каждому пользователю и аудировать доступ.
Возьмем для примера гипотетическую систему согласования договоров крупной компании, типовой кровавый энтерпрайз. Практически наверняка возникнут следующие требования к авторизации от бизнеса:
- Пользователь, не имеющий отношения к конкретному договору, не должен его видеть в системе
- Автор договора должен видеть его на всех этапах.
- Создавать договор имеет право пользователь с грейдом не ниже 10.
- Визирующий должен видеть договор, начиная с поступления к нему на этап и далее.
- Руководители подразделений должны видеть договоры своих подразделений вверх по иерархии.
- Автор договора и руководитель подразделения имеют право отозвать договор на любом этапе согласования.
- Руководство и секретариат головного офиса должны видеть документы всех филиалов.
- Пользователь, создавший договор, не должен иметь права его завизировать.
- Знать, кто имеет доступ к конкретному договору.
- Знать, кто имел доступ к конкретному договору в заданный момент времени.
- Лишать пользователя доступа к ранее доступным документам при изменении его должностных обязанностей.
Итак, обозначим, почему эти требования проблемные:
- Они не стабильны. Вероятность их изменения, даже в краткосрочной перспективе, стремится к 1.
- Они сквозные. Их реализация влияет на все слои, от дизайна БД до UI.
- Они лежат в плоскости предметной области. Это ведет к сильной связности механизма авторизации со слоем бизнес-логики.
- Они влияют на производительность.
Итого
Авторизация — незаслуженно обойденная вниманием тема, как в публикациях, так и непосредственно в процессе разработки. Двухфакторную аутентификацию по СМС к сайту прикрутит и ребенок. Правильно реализовать авторизацию в корпоративной системе, не наделав костылей — сложнейшая задача, о которую ломают копья сеньоры и архитекторы, а множество популярных коммерческих продуктов (к примеру, Atlassian Jira) стоят на костылях благодаря сложности требований.
Мы планируем серию статей, посвященных моделям авторизации и предмету в целом. Будем рады вопросам и предложениям по темам для рассмотрения.
Статья для дизайнеров интерфейсов, которые желают понять то, как работают процессы регистрации, авторизации, восстановления пароля, применяемые в различных системах. Если вы разработчик/дизайнер, и нашли ошибку/неточность - то дайте мне знать (я с радостью доработаю статью).
Начало
Сегодня я хотел бы рассказать о том, как проходит аутентификация в приложениях самых различных платформ - начиная от мобильных приложений, заканчивая консольными утилитами.
Аутентификация - это процесс, при котором пользователь подтверждает подлинность своей личности в какой-либо системе. Система предоставляет личные данные только своему владельцу.
Механизм аутентификации на базовом уровне довольно прост - вам нужно ввести данные в виде логина и пароля. Проверить данные на совпадение, и если данные совпали между собой - то вы являетесь подлинным обладателем учётной записи.
Учётная запись - это хранимый в системе набор данных о пользователе. К учётной записи как правило имеет доступ лишь один пользователь - её владелец.
В кино, когда шпиона просят назвать кодовую фразу для подтверждения своей личности - то по факту осуществляется процесс аутентификации пользователя. Если кодовая фраза (пароль) верный - то шпиону доверяют и предоставляют закрытые от остальных данные. (Утрированно)
Процессы аутентификации
Так как наши данные при регистрации в каком либо сервисе хранятся в базе данных - то к процессу аутентификации применяются базовые принципы работы с базами данных (далее БД) - это чтение, запись, обновление и удаление данных. При этом, во время каждого из действий с БД проверяется возможность совершения этих действий пользователем.
Авторизация (READ) - получение доступа к вашей личной учётной записи
Восстановление доступа к учётной записи (UPDATE) - если вы на пример забыли пароль - то его можно сменить, подтвердив свою личность.
Удаление (DELETE) - удаление вашей учётной записи из системы
Варианты фиксирования уникального имени пользователя (логин)
Есть несколько возможных способов проверки подлинности при предоставлении доступа к данным учётной записи в какой-либо системе. Логином могут выступать следующие пункты:
Номер телефона (+996 777 777 777)
Уникальное имя (username)
Учётная запись в стороннем сервисе (Google, Facebook, Apple… и так далее)
Варианты подтверждения логина (пароль)
Логин - это ещё не полный доступ к учётной записи, ему всегда сопутствует секретный ключ (пароль), который работает только в связке Логин-Пароль (или что-то из списка ниже).
SMS код (9379992SMS)
PIN код (9379992)
Ключи доступа / Токены (как пример ssh key)
Сканеры внешности (лицо, отпечаток пальца)
Токен - это уникальный (как правило длинный) набор символов для доступа к учётной записи, который может храниться на устройстве (телефон, компьютер, флешка, чип карта). Токен обычно не вводят вручную в поле ввода пароля, а предоставляют системе целый файл с токеном, для проверки подлинности.
Необходимость интернет соединения при различных видах аутентификации
Не все виды аутентификации пользователя требуют интернет соединения для проверки соответствия логина и пароля пользователя. На пример: вы можете без подключения к интернету разблокировать свой телефон, компьютер, сейф с кодовым замком или открыть дверь в подъезд.
Соединение нужно для тех типов аутентификации, в которых личные данные пользователей хранятся на удалённом сервере. Это как доступ к банковской ячейке, открыть которую вы можете только придя в банк, подтвердив свою личность и в присутствии охраны.
Комбинации ввода логина и пароля
Описанные выше варианты логинов и паролей могут комбинироваться между собой для проверки подлинности пользователя. На пример:
Номер телефона
Уникальное имя
В таблице каждая колонка - это варианты логина, а строки - это доступные варианты паролей.
Механизм проверки соответствия логина и пароля
Процесс проверки соответствия логина и пароля проходит в несколько этапов.
Отправляем данные на проверку
Система получает данные, которые ввёл пользователь, ищет в своей базе данных пользователя, проверяет соответствие логина и пароля.
Система отправляет результат проверки пользователю.
Получаем результат проверки
Для всех способов аутентификации процесс проверки соответствия одинаковый.
Двухфакторная аутентификация
В некоторых случаях может потребоваться дополнительная мера защиты учётных данных пользователя, и именно для этого вводится механизм двух факторной аутентификации - это когда пользователю необходимо подтвердить подлинность своей личности двумя разными способами. Примером может служить - ввод Email + Пароль, а затем номера телефона и СМС кода.
Упрощённая схема двух факторной аутентификации
Ошибки аутентификации
Во время проверки логина и пароля могут возникнуть ситуации, когда аутентификация не пройдена и пользователь не получил доступ к своим личным данным.
Логин введён неверно
Пароль введён неверно
Нет соединения с сервером
Ошибка проверки данных сервером
Превышен лимит ошибочных попыток аутентификации
Учётная запись пользователя заблокирована администратором
Лимиты ошибочных попыток аутентификации вводятся для усиления безопасности личных данных пользователей. После превышения лимита обычно предлагается восстановить пароль, либо повторить аутентификацию позже. В системах с повышенным уровнем контроля за безопасностью данных пользователя принимаются меры блокировки учётной записи до момента подтверждения личности пользователя (на пример в банковских картах).
Процесс восстановления пароля
В случаях, когда пользователь забыл свой пароль - он может его восстановить при помощи системы восстановления доступа. Для этого пользователю нужно пройти несколько шагов.
Подтвердить свою личность (на пример пройти по ссылке в электронном письме от сервиса восстановления пароля или ввести код из СМС)
Ввести новый пароль
Повторить ввод нового пароля
Сохранить новый пароль
После прохождения данных этапов пользователь для входа в систему может использовать свой логин и новый пароль.
В системах с повышенным контролем за безопасностью данных пользователей используется более сложный механизм подтверждения личности пользователя для смены пароля. Примером может служить приход пользователя в банк, чтобы восстановить пин-код к своей карте или личному кабинету в системе банка.
Стоит заметить, что некоторые сервисы не поддерживают восстановление пароля - например кошельки криптовалют. С одной стороны это позволяет обезопасить данные пользователя, с другой это даёт пользователю шанс навсегда потерять доступ к своим данным в системе.
Упрощённое объяснение термина "сессия"
Сессия - это механизм сохранения состояния авторизации пользователя в системе на заданный срок. Сессий одного пользователя может быть много. Примером может служить сессии в социальных сетях - когда вы можете зайти в свой аккаунт социальной сети с нескольких устройств одновременно, без необходимости выходить из учётной записи на другом устройстве.
Для того что бы различать входы с различных устройств - каждой сессии присваивается свой уникальный для каждой авторизации номер (Токен), который хранится в Cookies. Это нужно для того, что бы при выходе (закрытии сессии) с одного из устройств вы не выходили из своей учёной записи во всех остальных устройствах.
Cookies
Наверное вы часто слышали термин Cookies - это маленький фрагмент данных, которые система (сервер) хранит у пользователя. Каждый раз, когда пользователь открывает сайт - серверу отправляются данные Cookies, которые сервер сохранил у пользователя на устройстве. В нашей теме аутентификации - этим небольшим фрагментом будет уникальный номер сессии (Токен) пользователя, если он (пользователь) уже авторизован.
Вы можете проектировать свои интерфейсы как с сохранением сессий пользователей, так и без сохранения.
Заключение
В данной статье мы рассмотрели базовые принципы работы аутентификации в различных системах. Вся эта статья нацелена для того, чтобы помочь дизайнерам интерфейсов понять то - как работает процесс аутентификации, для чего он нужен, каких видов он бывает и что происходит на большинстве этапов во время авторизации, регистрации, восстановления пароля пользователем.
Читайте также: