Комментарии 20
НЛО прилетело и опубликовало эту надпись здесь
Проблема в том, что неизвестно, что понадобится софту. smtp/imap/pop нужен только почтовому клиенту, гуглотолку нужен XMPP, андроиду ещё что-то.
НЛО прилетело и опубликовало эту надпись здесь
Можно, например, сделать такой механизм:
Получение ПП --> авторизация с помощью приложения, которое по умолчанию должно передать Google список требуемых разрешений на получение данных (иначе не получит доступа к аккаунту) --> блокировка Google для данного ПП всех других возможностей, которые не были заявлены в списке. Плюс предоставление пользователю контрольной страницы, на которой можно посмотреть доступные данному ПП разрешения и отредактировать их.
Также, безусловно, следует запретить доступ к страницам настроек безопасности даже доверенными компьютерам и требовать ввода одноразового пин-кода.
И еще. Я не понимаю, почему в ПП только буквы? Неужели для большей криптостойкости нельзя добавить цифры?
Получение ПП --> авторизация с помощью приложения, которое по умолчанию должно передать Google список требуемых разрешений на получение данных (иначе не получит доступа к аккаунту) --> блокировка Google для данного ПП всех других возможностей, которые не были заявлены в списке. Плюс предоставление пользователю контрольной страницы, на которой можно посмотреть доступные данному ПП разрешения и отредактировать их.
Также, безусловно, следует запретить доступ к страницам настроек безопасности даже доверенными компьютерам и требовать ввода одноразового пин-кода.
И еще. Я не понимаю, почему в ПП только буквы? Неужели для большей криптостойкости нельзя добавить цифры?
Для такой схемы необходима поддержка 2ФА со стороны приложения. Что в общем случае не выполняется.
26^16 вариантов — недостаточно для надежного пароля?
26^16 вариантов — недостаточно для надежного пароля?
Компании Google следует, на мой взгляд, сертифицировать те приложения, которые имеют доступ к данных ее пользователей (к любым). В таком случае приложение по умолчанию будет поддерживать 2ФА.
Лишний раз повысить надежность — почему нет? Добавив всего лишь 10 цифр, можно увеличить число комбинаций больше, чем в 180 раз, если я правильно посчитал.
Лишний раз повысить надежность — почему нет? Добавив всего лишь 10 цифр, можно увеличить число комбинаций больше, чем в 180 раз, если я правильно посчитал.
Казалось бы, использование стандартных протоколов — jabber, imap и т.д. — призвано решать прямо противоположную задачу: возможность использования любого поддерживающего протокол приложения.
Такое повышение надежности в данном случае не особо нужно — брутфорс невозможен даже для 16 букв. Впрочем, я тоже не понимаю, зачем они так ограничили диапазон символов. Но недостатком это явно не является.
Такое повышение надежности в данном случае не особо нужно — брутфорс невозможен даже для 16 букв. Впрочем, я тоже не понимаю, зачем они так ограничили диапазон символов. Но недостатком это явно не является.
В случае с такими протоколами типа imap, можно, к примеру, просить пользователя поставить соответствующую галочку при создании пароля, разрешив использование определенного протокола.
И в таком случае приложению, которое использует данный ПП будет доступен только imap.
В случае кражи хэшей паролей, их взлом — (относительный) вопрос процессорного времени, которого, если использовать, например, ботнеты — навалом. Большее знаков способно отсрочить момент взлома аккаунта — у компании-владельца (тут — Google) появляется время на блокировку/принудительную смену паролей.
Я, конечно, понимаю, что пароли хэшируются с солью и остальными ухищрениями, повышающими безопасность, но тем не менее возможность взлома грубой силой сохраняется, и более, чем реальная.
Тем более, что в случае с ПП заранее злоумышленнику известен не только набор символов, но и точная длина ПП (знание длины вычеркивает из общего числа паролей существенный кусок).
И в таком случае приложению, которое использует данный ПП будет доступен только imap.
В случае кражи хэшей паролей, их взлом — (относительный) вопрос процессорного времени, которого, если использовать, например, ботнеты — навалом. Большее знаков способно отсрочить момент взлома аккаунта — у компании-владельца (тут — Google) появляется время на блокировку/принудительную смену паролей.
Я, конечно, понимаю, что пароли хэшируются с солью и остальными ухищрениями, повышающими безопасность, но тем не менее возможность взлома грубой силой сохраняется, и более, чем реальная.
Тем более, что в случае с ПП заранее злоумышленнику известен не только набор символов, но и точная длина ПП (знание длины вычеркивает из общего числа паролей существенный кусок).
Отлично, мы пришли к довольно разумной идее «пользователь указывает, какие протоколы можно использовать с данным паролем». Но, боюсь, это не будет пользоваться популярностью — большинство пользователей скорее всего просто будут ставить «разрешить всё», не разбираясь.
Знание, что длина равна максимальной, слабо облегчает жизнь: число паролей длины <= 15 символов составляют примерно 1/25 от числа паролей длины =16 символов.
Процессорного времени по сравнению с количеством вариантов не так уж и навалом. Экспонента растет очень быстро.
Знание, что длина равна максимальной, слабо облегчает жизнь: число паролей длины <= 15 символов составляют примерно 1/25 от числа паролей длины =16 символов.
Процессорного времени по сравнению с количеством вариантов не так уж и навалом. Экспонента растет очень быстро.
Проблема прекращается и всё становится известно, когда приложение авторизуется через конкретный ПП.
да, я думал аналогично. Более того, специальные «восстановительные» пароли, которые предлагалось распечатать и сохранить при включении 2ФА, чтобы аварийно зайти в настройки в обход 2ФА, ровно на это и намекали: пароли приложений ограничиваются по доступу к важным настройкам. Хорошо, что дыру пофиксили.
Боюсь, что даже с украденным ПП можно проблем огрести более чем достаточно. Полный доступ ко всем письмам + возможность сбросить/украсть пароль любого сервиса, завязанного на этот ящик, и всё это можно, единожды украв пароль, незаметно делать годами…
2012/07/24: Проблема подтверждена и классифицирована Google как «ожидаемое поведение».
2013/02/21: Google выпустила фикс, который запрещает доступ к критичной информации для ПП сессий.
полгода… сколько ж аккаунтов увели за это время?
2013/02/21: Google выпустила фикс, который запрещает доступ к критичной информации для ПП сессий.
полгода… сколько ж аккаунтов увели за это время?
Интересно другое — что довольно критичную уязвимость гугл фиксил целых полгода. Все таки бюрократия их побеждает.
Если известен ПП и основной пароль, то можно получить полный доступ к аккаунту, в обход 2ФА. Ставим хром, и входим в него используя адрес почты и основной пароль и ПП. А потом оказывается, что хром авторизовал вас в гугле, для всех сервисов, при этом 2ФА проверки не было.
Оригинал:
Перевод:
И так много где по тексту аутентификация волшебным образом превращается в авторизацию.
after a successful login, Google’s service returns a limited-access “token”, which is used to authenticate your device/application in the future
Перевод:
После успешной авторизации, сервер возвращает токен с ограниченным доступом, который в дальнейшем используется для авторизации вашего устройства/приложения.
И так много где по тексту аутентификация волшебным образом превращается в авторизацию.
НЛО прилетело и опубликовало эту надпись здесь
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обход двухфакторной аутентификации Google