Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 30
А как правильно говорить «Авторизация» или «Аутентификация»?
Компрометация телефонного номера моего клиента зачастую более весома, чем компрометация пары логин/пароль на моем «микросервисе»…
Предоставляете ли Вы какие-либо гарантии против утечки телефонных номеров из Вашей базы? Показываете ли Вы номера кому-нибудь, например мне, как владельцу сервиса?
Предоставляете ли Вы какие-либо гарантии против утечки телефонных номеров из Вашей базы? Показываете ли Вы номера кому-нибудь, например мне, как владельцу сервиса?
Показываете ли Вы номера кому-нибудь, например мне, как владельцу сервиса?Пользователь модуля в админке может видеть телефоны своих пользователей.
Предоставляете ли Вы какие-либо гарантии против утечки телефонных номеров из Вашей базы?Гарантий от утечки в явном виде нет. Можно утешаться тем, что в случае утечки MagicLogin получит существенный ущерб от плохого имиджа и, вероятно, закроется, т.е. потеряет вложенные в проект деньги и время. Можно прописать штраф в договоре, но как подтверждать факт утечки данных?
Похоже, многие путают понятия авторизации и аутентификации.
Аутентификация — это процесс опознания пользователя.
Авторизация — это процесс аутентификации пользователя с помощью Логин-Пароля.
Тоесть Авторизация это один из методов Аутентификации пользователя!
Аутентификация — это процесс опознания пользователя.
Авторизация — это процесс аутентификации пользователя с помощью Логин-Пароля.
Тоесть Авторизация это один из методов Аутентификации пользователя!
вообще говоря, насчет авторизации Вы неправы.
Авторизация — это механизм разграничения доступа к ресурсам для уже опознанных пользователей.
Авторизация — это механизм разграничения доступа к ресурсам для уже опознанных пользователей.
Пример
форма ввода логина-пароля, получили, нашли в базе, аутентифицировали
смотрим к какому ресурсу запрошен доступ, ага, админка, а юзер не админ — авторизацию не прошел
смотрим к какому ресурсу запрошен доступ, ага, админка, а юзер не админ — авторизацию не прошел
Так вы сами пишите, все начинается с формы Логин-Пароль. -)
Я говорю о том, что
А) авторизация происходит с помощью логин-пароля
Б) аутентификация может происходить с помощью авторизации(логин-пароль), сканирования отпечатка пальца, кода смс, сканирования сетчатки и.т.д и.т.п
Я говорю о том, что
А) авторизация происходит с помощью логин-пароля
Б) аутентификация может происходить с помощью авторизации(логин-пароль), сканирования отпечатка пальца, кода смс, сканирования сетчатки и.т.д и.т.п
Нет. Смотрим, например, википедию:
Т.е. аутентификация — это представление пользователя системе. При этом без разницы каким методом. Сетчатка глаза, логин-пароль, смс, анализу крови или же веры на слово.
А авторизация — проверка аутентифицированного пользователя на право выполнять те или иные действия (вход в админку — пользователям группы «админ» разрешаем, пользователям группы «пользователи» нет доступа).
Авториза́ция (от англ. authorization — разрешение, уполномочивание) — предоставление определённому лицу или группе лиц прав на выполнение определённых действий; а также процесс проверки (подтверждения) данных прав при попытке выполнения этих действий.[1][2][3] Часто можно услышать выражение, что какой-то человек «авторизован» для выполнения данной операции — это значит, что он имеет на неё право.
Авторизацию не следует путать с аутентификацией: аутентификация — это лишь процедура проверки подлинности данных, например, проверки соответствия введённого пользователем пароля к учётной записи паролю в базе данных, или проверка цифровой подписи письма по ключу шифрования, или проверка контрольной суммы файла на соответствие заявленной автором этого файла.
Т.е. аутентификация — это представление пользователя системе. При этом без разницы каким методом. Сетчатка глаза, логин-пароль, смс, анализу крови или же веры на слово.
А авторизация — проверка аутентифицированного пользователя на право выполнять те или иные действия (вход в админку — пользователям группы «админ» разрешаем, пользователям группы «пользователи» нет доступа).
Все верно. А есть еще Accounting в этой триаде:
Accounting refers to the tracking of network resource consumption by users for the purpose of capacity and trend analysis, cost allocation, billing.[4] In addition, it may record events such as authentication and authorization failures, and include auditing functionality, which permits verifying the correctness of procedures carried out based on accounting data. Real-time accounting refers to accounting information that is delivered concurrently with the consumption of the resources. Batch accounting refers to accounting information that is saved until it is delivered at a later time. Typical information that is gathered in accounting is the identity of the user or other entity, the nature of the service delivered, when the service began, and when it ended, and if there is a status to report.
Accounting refers to the tracking of network resource consumption by users for the purpose of capacity and trend analysis, cost allocation, billing.[4] In addition, it may record events such as authentication and authorization failures, and include auditing functionality, which permits verifying the correctness of procedures carried out based on accounting data. Real-time accounting refers to accounting information that is delivered concurrently with the consumption of the resources. Batch accounting refers to accounting information that is saved until it is delivered at a later time. Typical information that is gathered in accounting is the identity of the user or other entity, the nature of the service delivered, when the service began, and when it ended, and if there is a status to report.
Все верно. А есть еще Accounting в этой триаде:
Accounting refers to the tracking of network resource consumption by users for the purpose of capacity and trend analysis, cost allocation, billing.[4] In addition, it may record events such as authentication and authorization failures, and include auditing functionality, which permits verifying the correctness of procedures carried out based on accounting data. Real-time accounting refers to accounting information that is delivered concurrently with the consumption of the resources. Batch accounting refers to accounting information that is saved until it is delivered at a later time. Typical information that is gathered in accounting is the identity of the user or other entity, the nature of the service delivered, when the service began, and when it ended, and if there is a status to report.
Accounting refers to the tracking of network resource consumption by users for the purpose of capacity and trend analysis, cost allocation, billing.[4] In addition, it may record events such as authentication and authorization failures, and include auditing functionality, which permits verifying the correctness of procedures carried out based on accounting data. Real-time accounting refers to accounting information that is delivered concurrently with the consumption of the resources. Batch accounting refers to accounting information that is saved until it is delivered at a later time. Typical information that is gathered in accounting is the identity of the user or other entity, the nature of the service delivered, when the service began, and when it ended, and if there is a status to report.
Я бы, наверное, сделал немного иначе:
Добавил бы на сервере сайта таблицу, в которой хранил статус смс в течении некоторого периода времени, и получал бы подтверждения смс от сервера аутентификации напрямую, минуя браузер.
А после этого можно было бы при вводе логина проверять, есть ли такая запись в бд и, если статус не подтвержден, выводить форму для ввода кода, полученного по смс, в противном случае выводить, что аутентификация по смс уже подтверждена. Как-то так.
Да, процент пользователей, отключающих куки низок, но всё-таки он не равен нулю. Плюс, если вдруг во время авторизации на сайте, браузер слетит, подтверждение по смс еще будет активным.
Добавил бы на сервере сайта таблицу, в которой хранил статус смс в течении некоторого периода времени, и получал бы подтверждения смс от сервера аутентификации напрямую, минуя браузер.
А после этого можно было бы при вводе логина проверять, есть ли такая запись в бд и, если статус не подтвержден, выводить форму для ввода кода, полученного по смс, в противном случае выводить, что аутентификация по смс уже подтверждена. Как-то так.
Да, процент пользователей, отключающих куки низок, но всё-таки он не равен нулю. Плюс, если вдруг во время авторизации на сайте, браузер слетит, подтверждение по смс еще будет активным.
Спасибо за вариант!
Это идеологически проще, но мы специально отказались от использования БД на стороне сайта. Во-первых, взят прицел на поддержку всевозможных платформ, а поддержка различных БД и всевозможных обёрток поверх БД в разных фреймворках добавила бы сложностей.
Во-вторых, чем меньше кода на стороне сайта, тем ниже вероятность найти в нём баг. Баги на стороне нашего сервера мы можем исправлять оперативно и без участия владельцев сайтов. Баги на стороне сайта исправлять намного сложнее.
Это идеологически проще, но мы специально отказались от использования БД на стороне сайта. Во-первых, взят прицел на поддержку всевозможных платформ, а поддержка различных БД и всевозможных обёрток поверх БД в разных фреймворках добавила бы сложностей.
Во-вторых, чем меньше кода на стороне сайта, тем ниже вероятность найти в нём баг. Баги на стороне нашего сервера мы можем исправлять оперативно и без участия владельцев сайтов. Баги на стороне сайта исправлять намного сложнее.
Кстати, добавьте пользователя вида test/test, чтобы можно было оценить количество кода на стороне сайта.
Думал посмотреть, как именно реализовали, но создавать пустую учетную запись поленился, да и захламлять было бы глупо.
Думал посмотреть, как именно реализовали, но создавать пустую учетную запись поленился, да и захламлять было бы глупо.
Если сделать тестовый аккаунт для админки, то на нём придется отключить двухфакторную авторизацию. Это не понятно, не наглядно и криво в реализации. По-этому, по просьбе трудящихся клиентская часть модуля на гитхабе: github.com/magiclogin/magiclogin
На сервер авторизации прямо напрашивается Oauth.
OAuth действительно кажется применимым, и в MagicLogin используются некоторые принципы его работы. К сожалению, этот протокол существенно шире, чем требуется в данной задаче. Если применить OAuth, то код клиентской серверной части заметно увеличится, что крайне не желательно из-за сложностей с переносимостью и поддержкой.
Можно посмотреть в сторону OpenId Connect. Он хоть и базируется на OAuth2 но ощущается как-то легковеснее что ли. Плюс почти на всех популярных платформах есть реализации. Да и сама реализация клиентского модуля с OIDC в самом простом случае — редирект по 401 коду и потом парочка запросов при обратном редиректе(я про Code Flow).
Можно в двух словах, чем модуль лучше самописного велосипеда. Можно же подключить шлюз по 10 коп. + написать самому данный функционал? В данном модуле ведь цена 50 коп. за авторизацию.
Если коротко, то мы сами так и делали, но оказалось слишком много проблем.
Во-первых, шлюзы по 10 коп. за смс используют «старые» каналы с цифровым именем отправителя. По нашему опыту на таких каналах процент задержек и недоставок слишком большой. Мы отказались от дешевых каналов в пользу каналов с буквенным именем отправителя, на которых характерная характерная цена 50 коп. за смс., т.е. как у нас. Получается, что MagicLogin стоит столько-же.
Во-вторых, опыт показывает, что сделать свой велосипед качественно не так просто. На деле это займёт существенно больше, чем пол-дня, скорее около недели. Смена телефона, время жизни смс-пароля, время повторной оправки, защиты от скликивания, резервирование и мониторинг отправки смс — всё это так или иначе придется реализовать. Если использовать MagicLogin, то эти вопросы уже будут решены за Вас.
В третьих, пользователи всех сайтов, которые подключили модуль, будут пассивно искать баги и проблемы. А наш первый приоритет их оперативно исправлять. Таким образом, решение получается более надёжным, чем если Вы будете делать это для одного своего сайта.
Во-первых, шлюзы по 10 коп. за смс используют «старые» каналы с цифровым именем отправителя. По нашему опыту на таких каналах процент задержек и недоставок слишком большой. Мы отказались от дешевых каналов в пользу каналов с буквенным именем отправителя, на которых характерная характерная цена 50 коп. за смс., т.е. как у нас. Получается, что MagicLogin стоит столько-же.
Во-вторых, опыт показывает, что сделать свой велосипед качественно не так просто. На деле это займёт существенно больше, чем пол-дня, скорее около недели. Смена телефона, время жизни смс-пароля, время повторной оправки, защиты от скликивания, резервирование и мониторинг отправки смс — всё это так или иначе придется реализовать. Если использовать MagicLogin, то эти вопросы уже будут решены за Вас.
В третьих, пользователи всех сайтов, которые подключили модуль, будут пассивно искать баги и проблемы. А наш первый приоритет их оперативно исправлять. Таким образом, решение получается более надёжным, чем если Вы будете делать это для одного своего сайта.
А какие есть шлюзы по 10 копеек? После повышения цен всеми операторами под предлогом борьбы со спамом я думал уже и не осталось таких.
Сделаете модуль для livestreet, цены вам не будет
Не очень понятно, зачем использовать SMS (и, тем более, тратить деньги на их рассылку), когда есть TOTP? «Google authenticator» уже есть под все смартфоны. На мой взгляд двухфакторная авторизация по смс это зло, с которым нельзя связываться, если есть возможность.
К сожалению, использование приложения для телефона не так универсально, как смс.
1. Есть немало людей, для которых установить и использовать приложение действительно сложно.
2. Если Ваш телефон стоит 700 руб., или, например, выпущен 10 лет назад, то java-приложение может не работать.
3. На простых телефонах обычно нельзя отсканировать QR-код, по-этому, при настройке Google Authenticator придётся вручную вбить ~20 символов секретного ключа.
Из-за этих ограничений на практике среди способов двухфакторной авторизации использование смс является самым популярным. Очень часто расходы на смс ниже, чем финансовые потери от неудобств клиентов, которые возникнут при переходе на приложение для телефона.
1. Есть немало людей, для которых установить и использовать приложение действительно сложно.
2. Если Ваш телефон стоит 700 руб., или, например, выпущен 10 лет назад, то java-приложение может не работать.
3. На простых телефонах обычно нельзя отсканировать QR-код, по-этому, при настройке Google Authenticator придётся вручную вбить ~20 символов секретного ключа.
Из-за этих ограничений на практике среди способов двухфакторной авторизации использование смс является самым популярным. Очень часто расходы на смс ниже, чем финансовые потери от неудобств клиентов, которые возникнут при переходе на приложение для телефона.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Двухфакторная авторизация по смс с барышнями и преферансом