Введение
2014 год можно смело назвать годом взломанных аккаунтов. Согласно Identity Theft Resource Center, данные были похищены чаще, чем когда-либо с 2005 года.
Также согласно ресурсу Have I been pwned? было похищено более 175 млн. аккаунтов. И одно дело, когда утекли абсолютно все данные и совершенно другое, когда утекли только учётные записи пользователей. Именно последнее будет обсуждаться в данной публикации.
Двухфакторная аутентификация
Двухфакторная аутентификация по сути является стандартом индустрии, позволяющем предотвратить использование утечек учётных записей, так как злоумышленник не сможет авторизоваться под украденным пользователем без второй аутентификации. Также это сводит на нет перебор паролей, убирает необходимость использования капчи и делает некоторые другие вещи приятнее в зависимости от приложения.
Известных способов реализовать двухфакторную аутентификацию несколько:
- Физический токен.
- SMS гейтвей.
- Приложение-аутентификатор.
Физический токен
Плюсы:
- Очень безопасно. Если аутентификатор скомпрометирован — мы узнаем об этом мгновенно, ведь его надо украсть.
Минусы:
- Стоит денег.
- Нужно иметь с собой при необходимости аутентифицироваться.
- Если у вас B2C, вы стопроцентно не сможете раздать токен каждому.
SMS гейтвей
Плюсы:
- Безопасно.
Минусы:
- Мы не контролируем его. Абсолютно. Нам неизвестно, что происходит внутри, нам неизвестно, что происходит с нашей базой номеров, нам неизвестно, действительное ли смс была отправлена. Что будет, когда сервис упадёт?
- Стоимость. Я брал цены с Clickatell. В среднем отправить одну смс стоит 0.03 доллара. Если вы отправляете 100 тысяч сообщений в месяц, это будет стоить вам 3000 долларов в месяц (~180 тысяч рублей) или 36 тысяч долларов в год (~2 млн. рублей). А что если вы немного больше по размерам? И отправляется 1 млн сообщений в месяц? Это будет стоить вам 30 тысяч долларов в месяц (360 тысяч в год). А что, если вы доросли до размеров ого-го? И отправляется 10 млн. сообщений в месяц? Тогда будьте добры выложить 300 тысяч долларов в месяц или 3 600 000 долларов в год (~216 млн. рублей). Это плохо. Если вы выкладываете деньги из своего кармана, вы могли бы купить на них что-нибудь интересное. Если это деньги инвестора, то вы могли бы пустить их на развитие проекта, новые сервера, увеличение зарплаты и прочие полезные вещи.
- Ваш пользователь всегда должен иметь при себе телефон с авторизованной SIM картой. Отсюда вытекают всякие неприятности, если пользователь меняет SIM карту или теряет телефон, или батарейка на нём садится.
Приложение-аутентификатор
Плюсы:
- Безопасно.
- Мы полностью контролируем его.
Минусы:
- Иногда суммарная стоимость разработки и поддержки такого приложения обходится дороже, чем использование SMS гейтвея.
- Вашему пользователю всегда нужно иметь с собой авторизованное устройство.
Стороннее приложение-аутентификатор
Например Google Authenticator или Microsoft Authenticator.
Плюсы:
- Безопасно.
Минусы:
- Мы не контролируем его и не знаем, что происходит внутри.
- Что будет с этим приложением завтра? Не убьют ли его, как ненужное?
- Вашему пользователю всегда нужно иметь с собой авторизованное устройство. При этом оно должно поддерживать сторонний аутентификатор.
Ещё одна аутентификация (the Sign)
Я назвал её the Sign. Пользователю не нужно вообще ничего, кроме его эмейла и доступа в почту с ним.
Выглядит это так:
- Пользователь вводит email в нашем сервисе.
- Мы добавляем его в базу, если его там не было.
- Отправляем пользователю письмо со сгенерированный авторизационной ссылкой и кодом, если авторизация будет в приложении.
- Пользователь авторизуется по ссылке или с помощью кода.
- ...
- Профит!
Диаграмма процесса:
Плюсы:
- Безопасно.
- Пользователю не нужно думать над паролем или давать нам или нет доступ в его профиль социальной сети. Если мы сначала сделали лендинг, чтобы проверить популярность идеи, то потом нам не составит никакого труда разослать пользователем авторизационные ссылки и не морочить их авторизацией.
- Мы полностью контролируем и ведём мониторинг всего процесса.
- Стоимость решения крайне невысока.
- Работает на любом устройстве.
- Пользователю вообще не нужно авторизованное устройство, только доступ к почте.
- Разработай один раз и забудь. Занимайся только поддержкой. Но вы ведь уже поддерживаете сервис отправки почтовых сообщений в своём проекте, не так ли?
- Для того, чтобы ввести код в приложении, нужно приложить ровно столько же усилий, сколько с SMS.
Минусы:
- Пользователю нужен доступ к email аккаунту.
Заключение
Данный процесс пока является концептом и не применяется в живых приложениях. Он не проверен временем. Так как его придумала ровно одна голова. Он не проверен критикой. Но я не нашёл возможных атак и вообще существенных минусов. Поэтому и вынес на публичное обсуждение. Хочется понять, ограничивает ли применение такой авторизации что-либо кроме того, что он не применяется широко.
Комментарии (29)
ENargit
01.04.2015 12:24Насколько я понимаю, эта и идея не нова. Я многократно видел в некоторых сервисах подтверждение критичных действий через email. В частности, на биткоин биржах. И единственной проблемой, почему эта идея не прижилась так широко, как остальные варианты второго фактора, является сравнительная простота кражи почтовых ящиков.
EminH
01.04.2015 12:30А где здесь второй фактор? Я вижу только один
теоретически вторым фактором может быть защищен email сервис пользователя, то есть получается просто перекладывание ответсвенностиENargit
01.04.2015 12:41Ну тут спорный вопрос, что можно считать вторым фактором. С одной стороны емейл является отдельным фактором, т.к. для того чтобы попасть на сайт нужно не только знать пароль, но и знать пароль от емейла. С другой стороны, некоторые источники утверждают, что вторым фактором может называться только при передаче по отдельному каналу (чтобы исключить MITM атаку, когда злоумышленник одним ударом получает в свои руки оба «фактора»).
Но вообще, вы правы, предложение больше похоже на шутку.EminH
01.04.2015 12:51емейл является отдельным фактором
На блок-схеме пользователь только email и представляет, то есть фактор предлагается один единственный
А шутка могла быть и повеселее :)
colotiline Автор
01.04.2015 21:16Вообще я не шутил. Просто так совпало, что опубликовали 1 апреля.
Здесь нет ещё одной двухфакторной аутентификации. Здесь просто аутентификация через почтовый ящик.
Этот ящик:
1. Защищён двухфакторной аутентификацией.
2. Уже авторизован на всех нужных пользователю устройствах.
3. К нему может быть получен доступ откуда угодно.
Я просто не понимаю, зачем городить второй огород двухфакторной аутентификации без необходимости.
colotiline Автор
01.04.2015 21:25Я вообще не понимаю, зачем нам все эти пароли. У нас уже есть авторизованное пространство — почта. И именно её надо защищать двухфакторной аутентификацией. Так как именно через неё угоняют другие аккаунты.
А в другие сервисы мы должны входить не задумваясь о:
1. А зарегистрированы ли мы здесь.
2. А какой у нас пароль.
3. Надо восстановить пароль.
4. Надо достать мобильный и ввести с него код, считать что-то с экрана и т.д.
Ввели email — перешли в почте по ссылке и работаем. Здесь и сейчас.
Более того, если угоняют аккаунт — это не наша вина. Так как в этом случае 99% угнали почту пользователя. Мы вообще не причём. И отдельная двухфакторная аутентификация нам здесь не нужна. Все, кому она нужна — установили на почте.
1. Зачем нам тратить ресурсы на её разработку и поддержку?
2. Зачем нам тратить деньги на смс?
3. Зачем на гемороить пользователя?
Мне действительно неясно, почему данное предложение больше похоже на шутку.
colotiline Автор
01.04.2015 21:13Здесь нет второго фактора, так как это замена. enargit правильно подумал, что это упрощение доступа в свой сервис и перкидывание ответственности.
EminH
01.04.2015 21:32Я не понял зачем вообще упоминать двухфакторку. Если речь о упрощении логина то сравнивайте с тем же open auth например
colotiline Автор
05.04.2015 15:37Я сравниваю с двухфактрной, потому что она почти везде. И это усложнение, а не упрощение. OpenAuth ещё мудрённее, чем двухфакторка, поэтому с ним не сравниваю.
Drew003
01.04.2015 12:54часто через email и ломают аккаунт. Кстати на moniker такая авторизация…
colotiline Автор
01.04.2015 21:16И этот email и нужно защитить двухфакторной аутентификацией. Зачем защищать ещё свой сервис, если мы не банк, мне неясно.
colotiline Автор
01.04.2015 21:27А какой moniker вы имели в виду? Я хочу добавить в копилку. Сейчас там отчасти похожие авторизации из Steam и МойКруг.
elepner
01.04.2015 13:55+1Такой тип авторизации присутствует, например, в Steam. При попытке подключится к аккаунту с нового устройства, на email отправляется письмо с кодом активации.
colotiline Автор
01.04.2015 21:17Да, точно. Спасибо. Я также предлагаю высылать авторизационную ссылку пользователю на почту, чтобы он просто кликнул и сразу вошёл в систему под собой. А мы его запомнили и больше не спрашивали ничего без необходимости.
UncleAndy
01.04.2015 15:19Вообще-то уже есть отличное приложение для того, что-бы организовать логин без пароля — GPLVote Sign Doc. Хотя оно и создано нашим проектом, но разрабатывалось как универсальное приложение. Весь процесс логина без пароля состоит из сканирования QR-кода и нажатия на кнопку «Войти». При этом, особенность системы такова, что если кто-то «из-за плеча» сосканирует этот код своим телефоном, они ничего не получит — просто вы после нажатия на «Войти» попадете в его аккаунт, а не в свой. :)
Само приложение сейчас доступно для Android в Play Market (версия для iOS в разработке). Оно абсолютно бесплатно и с открытыми исходными кодами. Об API и способе использования можно почитать вот тут.
К сожалению, у меня пока не хватает времени что-бы прикрутить этот способ на работающий сайт, но такие планы есть. Поиграться с приложением можно на тестовом сайте.
NYMEZIDE
01.04.2015 16:021. Зачем нажимать кнопку «войти»? разве андройд приложение не отправляет данные о том что код успешно считан? почему бы сразу не делать редирект на сайте?
2. что делать если нет интернета на телефоне? как сайт узнает что вы считали код? сильная зависимость от интернета и вообще от соединения, в отличии от Приложения-аутентификатора.UncleAndy
01.04.2015 16:061. Легко. Но это уже дело сайта организовать проверку статуса через JS;
2. Естественно, этот вариант применим только если на телефоне есть интернет (хотя найти сейчас такой без интернета, мне кажется, будет довольно сложно). Думаю, в приложении-аутентификаторе есть свои недостатки. Это уже тому, кто будет прикручивать их использование решать что выбрать. :)NYMEZIDE
01.04.2015 16:11представьте ситуацию — интернет кафе или точка доступа на 0 этаже. где связь не ловит. но интернет на рабочие станции идет по кабелю. вай-фая нет.
как залогинется? ) фоткать и выбегать на улицу отправлять данные? )
3. еще вопрос — если произошел сброс телефона на заводские настройки, прога слетела и т.д. — как восстановить доступ? через почту?
как тогда защититься если кто-то ломанет почту и установит себе прогу на телефон?UncleAndy
01.04.2015 16:21Опять-же, вы описываете умозрительную относительно редкую ситуацию в которой Sign Doc проигрывает, а ваш аутентификатор выигрывает. Но, я думаю, можно придумать столько-же умозрительных ситуаций с противоположным исходом. Так зачем нам тут «меряться пиписками»? И у вас и у меня есть приложения, которые можно применить для определенной цели. Со своими достоинствами и недостатками. Я не отрицаю того, что в определенной ситуации Sign Doc может не сработать. И что-же с того?
На счет сброса вы верно подметили. При стирании данных приложения, привязка к аккаунту на сайте потеряется. В такой ситуации имеет смысл воспользоваться стандартными средствами восстановления доступа.
> как тогда защититься если кто-то ломанет почту и установит себе прогу на телефон?
А как защититься если на смартфоне у вас вирус, который будет использовать данные вашего аутентификатора? Ситуация абсурдная, т.к. не предполагает возможности как-то от нее защитится на уровне приложения. Так что и обсуждать ее не имеет смысла.NYMEZIDE
01.04.2015 16:26ну насчет ситуаций — соглашусь.
а вот насчет защититься от вируса — т.е. данные хранятся на телефоне в открытом виде и передаются-перехватываются в открытом виде? реализацию не расскажите? смысл иметь приложение ключ — если его могут использовать кто угодно на телефоне? ) сам ключ должен иметь защиту же! как хранения — так и передачи данных.
иначе весь смысл теряется!UncleAndy
01.04.2015 16:39Нет, естественно, все что секретного храниться в приложении, храниться зашифрованным и ничего из этого по сети не передается. Но для хорошего вируса это не проблема, по идее.
Это приложение общего назначения — подписание данных ключем RSA. Секретный ключ храниться внутри в зашифрованном виде. Наружу уходят только подписи «документов». Как раз логин можно реализовать через подписание «документа» с одноразовым кодом (вводить пользователю в приложение ничего не надо — сосканировал QR-код, увидел что одноразовый код в документе совпадает с тем, что на экране и нажал «Подписать»).
colotiline Автор
01.04.2015 21:19Данный способ подразумевает, что у нас есть авторизованное мобильное устройство с приложением. Мне кажется, что это минус. Предлагаемый мой способ подразумевает, что у нас есть доступ к почте. Хоть с холодильника.
UncleAndy
01.04.2015 22:25Мой способ подразумевает только наличие устройства и приложения. Привязка производиться отдельным одноразовым действием типа «сосканировал QR-код» и продолжить.
colotiline Автор
05.04.2015 15:42А можете подробнее описать? Я почитал вики по вашей ссылке, но там немножко больше информации, чем хочется разбирать.
Как выглядит первый процесс авторизации устройства, чтобы в дальнейшем с него аутентифицироваться под своей учёткой?UncleAndy
05.04.2015 17:46— После установки приложения происходит процесс его инициализации, заключающийся в формировании пары RSA ключей. Делается один раз после установки приложения;
— При необходимости привязки к какому-либо сайту, нужно перейти на соответствующую страницу сайта, где сформируется QR-код c URL сайта и одноразовым кодом;
— При сканировании этого кода, приложение получает одноразовый код, его подписывает и отправляет на URL из QR-кода вместе с открытой частью RSA ключа;
Логика последнего этапа (регистрация на сайте) возможена в двух вариантах — либо регистрация только через QR-код, либо привязка публичного ключа к уже имеющемуся обычному аккаунту на сайте. В первом случае, приложение будет единственным способом авторизации на сайте и заполнять все остальные данные с никами, именами, емэйлами и т.д. надо будет дальше в процедуре регистрации (если это, конечно, нужно). Во втором случае публичный ключ просто привязывается к обычному логину и можно требовать от пользователя подтверждения каких-то действий через приложение. Либо сделать альтернативный вариант логина через сканирование QR-кода вместо вода логина и пароля.
EminH
Это шутка?
colotiline Автор
Нет. Опишите минусы, пожалуйста.