Comments 29
Это шутка?
Насколько я понимаю, эта и идея не нова. Я многократно видел в некоторых сервисах подтверждение критичных действий через email. В частности, на биткоин биржах. И единственной проблемой, почему эта идея не прижилась так широко, как остальные варианты второго фактора, является сравнительная простота кражи почтовых ящиков.
А где здесь второй фактор? Я вижу только один
теоретически вторым фактором может быть защищен email сервис пользователя, то есть получается просто перекладывание ответсвенности
теоретически вторым фактором может быть защищен email сервис пользователя, то есть получается просто перекладывание ответсвенности
Ну тут спорный вопрос, что можно считать вторым фактором. С одной стороны емейл является отдельным фактором, т.к. для того чтобы попасть на сайт нужно не только знать пароль, но и знать пароль от емейла. С другой стороны, некоторые источники утверждают, что вторым фактором может называться только при передаче по отдельному каналу (чтобы исключить MITM атаку, когда злоумышленник одним ударом получает в свои руки оба «фактора»).
Но вообще, вы правы, предложение больше похоже на шутку.
Но вообще, вы правы, предложение больше похоже на шутку.
емейл является отдельным фактором
На блок-схеме пользователь только email и представляет, то есть фактор предлагается один единственный
А шутка могла быть и повеселее :)
Вообще я не шутил. Просто так совпало, что опубликовали 1 апреля.
Здесь нет ещё одной двухфакторной аутентификации. Здесь просто аутентификация через почтовый ящик.
Этот ящик:
1. Защищён двухфакторной аутентификацией.
2. Уже авторизован на всех нужных пользователю устройствах.
3. К нему может быть получен доступ откуда угодно.
Я просто не понимаю, зачем городить второй огород двухфакторной аутентификации без необходимости.
Здесь нет ещё одной двухфакторной аутентификации. Здесь просто аутентификация через почтовый ящик.
Этот ящик:
1. Защищён двухфакторной аутентификацией.
2. Уже авторизован на всех нужных пользователю устройствах.
3. К нему может быть получен доступ откуда угодно.
Я просто не понимаю, зачем городить второй огород двухфакторной аутентификации без необходимости.
Я вообще не понимаю, зачем нам все эти пароли. У нас уже есть авторизованное пространство — почта. И именно её надо защищать двухфакторной аутентификацией. Так как именно через неё угоняют другие аккаунты.
А в другие сервисы мы должны входить не задумваясь о:
1. А зарегистрированы ли мы здесь.
2. А какой у нас пароль.
3. Надо восстановить пароль.
4. Надо достать мобильный и ввести с него код, считать что-то с экрана и т.д.
Ввели email — перешли в почте по ссылке и работаем. Здесь и сейчас.
Более того, если угоняют аккаунт — это не наша вина. Так как в этом случае 99% угнали почту пользователя. Мы вообще не причём. И отдельная двухфакторная аутентификация нам здесь не нужна. Все, кому она нужна — установили на почте.
1. Зачем нам тратить ресурсы на её разработку и поддержку?
2. Зачем нам тратить деньги на смс?
3. Зачем на гемороить пользователя?
Мне действительно неясно, почему данное предложение больше похоже на шутку.
А в другие сервисы мы должны входить не задумваясь о:
1. А зарегистрированы ли мы здесь.
2. А какой у нас пароль.
3. Надо восстановить пароль.
4. Надо достать мобильный и ввести с него код, считать что-то с экрана и т.д.
Ввели email — перешли в почте по ссылке и работаем. Здесь и сейчас.
Более того, если угоняют аккаунт — это не наша вина. Так как в этом случае 99% угнали почту пользователя. Мы вообще не причём. И отдельная двухфакторная аутентификация нам здесь не нужна. Все, кому она нужна — установили на почте.
1. Зачем нам тратить ресурсы на её разработку и поддержку?
2. Зачем нам тратить деньги на смс?
3. Зачем на гемороить пользователя?
Мне действительно неясно, почему данное предложение больше похоже на шутку.
Здесь нет второго фактора, так как это замена. enargit правильно подумал, что это упрощение доступа в свой сервис и перкидывание ответственности.
del
часто через email и ломают аккаунт. Кстати на moniker такая авторизация…
Такой тип авторизации присутствует, например, в Steam. При попытке подключится к аккаунту с нового устройства, на email отправляется письмо с кодом активации.
Вообще-то уже есть отличное приложение для того, что-бы организовать логин без пароля — GPLVote Sign Doc. Хотя оно и создано нашим проектом, но разрабатывалось как универсальное приложение. Весь процесс логина без пароля состоит из сканирования QR-кода и нажатия на кнопку «Войти». При этом, особенность системы такова, что если кто-то «из-за плеча» сосканирует этот код своим телефоном, они ничего не получит — просто вы после нажатия на «Войти» попадете в его аккаунт, а не в свой. :)
Само приложение сейчас доступно для Android в Play Market (версия для iOS в разработке). Оно абсолютно бесплатно и с открытыми исходными кодами. Об API и способе использования можно почитать вот тут.
К сожалению, у меня пока не хватает времени что-бы прикрутить этот способ на работающий сайт, но такие планы есть. Поиграться с приложением можно на тестовом сайте.
Само приложение сейчас доступно для Android в Play Market (версия для iOS в разработке). Оно абсолютно бесплатно и с открытыми исходными кодами. Об API и способе использования можно почитать вот тут.
К сожалению, у меня пока не хватает времени что-бы прикрутить этот способ на работающий сайт, но такие планы есть. Поиграться с приложением можно на тестовом сайте.
1. Зачем нажимать кнопку «войти»? разве андройд приложение не отправляет данные о том что код успешно считан? почему бы сразу не делать редирект на сайте?
2. что делать если нет интернета на телефоне? как сайт узнает что вы считали код? сильная зависимость от интернета и вообще от соединения, в отличии от Приложения-аутентификатора.
2. что делать если нет интернета на телефоне? как сайт узнает что вы считали код? сильная зависимость от интернета и вообще от соединения, в отличии от Приложения-аутентификатора.
1. Легко. Но это уже дело сайта организовать проверку статуса через JS;
2. Естественно, этот вариант применим только если на телефоне есть интернет (хотя найти сейчас такой без интернета, мне кажется, будет довольно сложно). Думаю, в приложении-аутентификаторе есть свои недостатки. Это уже тому, кто будет прикручивать их использование решать что выбрать. :)
2. Естественно, этот вариант применим только если на телефоне есть интернет (хотя найти сейчас такой без интернета, мне кажется, будет довольно сложно). Думаю, в приложении-аутентификаторе есть свои недостатки. Это уже тому, кто будет прикручивать их использование решать что выбрать. :)
представьте ситуацию — интернет кафе или точка доступа на 0 этаже. где связь не ловит. но интернет на рабочие станции идет по кабелю. вай-фая нет.
как залогинется? ) фоткать и выбегать на улицу отправлять данные? )
3. еще вопрос — если произошел сброс телефона на заводские настройки, прога слетела и т.д. — как восстановить доступ? через почту?
как тогда защититься если кто-то ломанет почту и установит себе прогу на телефон?
как залогинется? ) фоткать и выбегать на улицу отправлять данные? )
3. еще вопрос — если произошел сброс телефона на заводские настройки, прога слетела и т.д. — как восстановить доступ? через почту?
как тогда защититься если кто-то ломанет почту и установит себе прогу на телефон?
Опять-же, вы описываете умозрительную относительно редкую ситуацию в которой Sign Doc проигрывает, а ваш аутентификатор выигрывает. Но, я думаю, можно придумать столько-же умозрительных ситуаций с противоположным исходом. Так зачем нам тут «меряться пиписками»? И у вас и у меня есть приложения, которые можно применить для определенной цели. Со своими достоинствами и недостатками. Я не отрицаю того, что в определенной ситуации Sign Doc может не сработать. И что-же с того?
На счет сброса вы верно подметили. При стирании данных приложения, привязка к аккаунту на сайте потеряется. В такой ситуации имеет смысл воспользоваться стандартными средствами восстановления доступа.
> как тогда защититься если кто-то ломанет почту и установит себе прогу на телефон?
А как защититься если на смартфоне у вас вирус, который будет использовать данные вашего аутентификатора? Ситуация абсурдная, т.к. не предполагает возможности как-то от нее защитится на уровне приложения. Так что и обсуждать ее не имеет смысла.
На счет сброса вы верно подметили. При стирании данных приложения, привязка к аккаунту на сайте потеряется. В такой ситуации имеет смысл воспользоваться стандартными средствами восстановления доступа.
> как тогда защититься если кто-то ломанет почту и установит себе прогу на телефон?
А как защититься если на смартфоне у вас вирус, который будет использовать данные вашего аутентификатора? Ситуация абсурдная, т.к. не предполагает возможности как-то от нее защитится на уровне приложения. Так что и обсуждать ее не имеет смысла.
ну насчет ситуаций — соглашусь.
а вот насчет защититься от вируса — т.е. данные хранятся на телефоне в открытом виде и передаются-перехватываются в открытом виде? реализацию не расскажите? смысл иметь приложение ключ — если его могут использовать кто угодно на телефоне? ) сам ключ должен иметь защиту же! как хранения — так и передачи данных.
иначе весь смысл теряется!
а вот насчет защититься от вируса — т.е. данные хранятся на телефоне в открытом виде и передаются-перехватываются в открытом виде? реализацию не расскажите? смысл иметь приложение ключ — если его могут использовать кто угодно на телефоне? ) сам ключ должен иметь защиту же! как хранения — так и передачи данных.
иначе весь смысл теряется!
Нет, естественно, все что секретного храниться в приложении, храниться зашифрованным и ничего из этого по сети не передается. Но для хорошего вируса это не проблема, по идее.
Это приложение общего назначения — подписание данных ключем RSA. Секретный ключ храниться внутри в зашифрованном виде. Наружу уходят только подписи «документов». Как раз логин можно реализовать через подписание «документа» с одноразовым кодом (вводить пользователю в приложение ничего не надо — сосканировал QR-код, увидел что одноразовый код в документе совпадает с тем, что на экране и нажал «Подписать»).
Это приложение общего назначения — подписание данных ключем RSA. Секретный ключ храниться внутри в зашифрованном виде. Наружу уходят только подписи «документов». Как раз логин можно реализовать через подписание «документа» с одноразовым кодом (вводить пользователю в приложение ничего не надо — сосканировал QR-код, увидел что одноразовый код в документе совпадает с тем, что на экране и нажал «Подписать»).
Данный способ подразумевает, что у нас есть авторизованное мобильное устройство с приложением. Мне кажется, что это минус. Предлагаемый мой способ подразумевает, что у нас есть доступ к почте. Хоть с холодильника.
Мой способ подразумевает только наличие устройства и приложения. Привязка производиться отдельным одноразовым действием типа «сосканировал QR-код» и продолжить.
А можете подробнее описать? Я почитал вики по вашей ссылке, но там немножко больше информации, чем хочется разбирать.
Как выглядит первый процесс авторизации устройства, чтобы в дальнейшем с него аутентифицироваться под своей учёткой?
Как выглядит первый процесс авторизации устройства, чтобы в дальнейшем с него аутентифицироваться под своей учёткой?
— После установки приложения происходит процесс его инициализации, заключающийся в формировании пары RSA ключей. Делается один раз после установки приложения;
— При необходимости привязки к какому-либо сайту, нужно перейти на соответствующую страницу сайта, где сформируется QR-код c URL сайта и одноразовым кодом;
— При сканировании этого кода, приложение получает одноразовый код, его подписывает и отправляет на URL из QR-кода вместе с открытой частью RSA ключа;
Логика последнего этапа (регистрация на сайте) возможена в двух вариантах — либо регистрация только через QR-код, либо привязка публичного ключа к уже имеющемуся обычному аккаунту на сайте. В первом случае, приложение будет единственным способом авторизации на сайте и заполнять все остальные данные с никами, именами, емэйлами и т.д. надо будет дальше в процедуре регистрации (если это, конечно, нужно). Во втором случае публичный ключ просто привязывается к обычному логину и можно требовать от пользователя подтверждения каких-то действий через приложение. Либо сделать альтернативный вариант логина через сканирование QR-кода вместо вода логина и пароля.
— При необходимости привязки к какому-либо сайту, нужно перейти на соответствующую страницу сайта, где сформируется QR-код c URL сайта и одноразовым кодом;
— При сканировании этого кода, приложение получает одноразовый код, его подписывает и отправляет на URL из QR-кода вместе с открытой частью RSA ключа;
Логика последнего этапа (регистрация на сайте) возможена в двух вариантах — либо регистрация только через QR-код, либо привязка публичного ключа к уже имеющемуся обычному аккаунту на сайте. В первом случае, приложение будет единственным способом авторизации на сайте и заполнять все остальные данные с никами, именами, емэйлами и т.д. надо будет дальше в процедуре регистрации (если это, конечно, нужно). Во втором случае публичный ключ просто привязывается к обычному логину и можно требовать от пользователя подтверждения каких-то действий через приложение. Либо сделать альтернативный вариант логина через сканирование QR-кода вместо вода логина и пароля.
Sign up to leave a comment.
Замена двухфакторной аутентификации