Нужно различать смену и восстановление. Если вы забыли пароль — на почту (к примеру) отправляется ссылка на восстановление (у Google/Yandex/Hetzner есть возможность отправлять на резервный email). Но перейдя по ссылке вам всё ещё нужно будет ввести второй фактор, тот же код из смс.
Если бы написанное мной не было правдой, то зачем вообще придумывали двухфакторную аутентификацию, если она на порядок упрощает взлом людей, находящихся рядом?
На то он и резервный адрес. Аналогично есть резервные коды восстановления на случай если у вас нет устройства, которое генерирует TOTP токены. То есть формально вы можете даже не иметь доступа к устройству.
В статье вообще ни слова про ненадежность двухэтапной аутентификации, только заголовок. Написано про то, что при получении доступа к телефону возможна смена пароля привязанного к этому телефону, что совсем не относится к двухфакторной аутентификации.
Он может приходить на украденное устройство, но на устройстве не должно быть доступного пароля. Если пароль в голове а второй фактор на украденном телефоне, то система всё ещё работает.
Нет, не может. Войдите с неизвестного компьютера (достаточно открыть окно в приватном режиме) и запустите процедуру восстановления пароля. А потом расскажите нам об успехах.
Кто вам доктор, что вы положили два яйца в одну корзину? Это не будет двухфакторной (двухэтапной) аутентификацией, ибо у вас оба фактора одинаковые, а должны быть разными (один то, что вы знаете — пароль, второе что вы имеете — телефон, аппаратный генератор токенов). В этом случае получение доступа к одному из факторов не позволяет войти в систему или изменить пароль.
Двухэтапная значит что у вас есть два этапа. Первый: ввод пароля. Второй: ввод кода смс (к примеру).
Следовательно, вы не приступите ко второму этапу, не пройдя первый. То же самое во время ввода пароля, получения смс не достаточно для смены пароля, иначе какой в этом смысл? Кто-то называет это этапами, кто-то факторами. Суть не меняется.
Вы не понимаете что такое двухфакторная аутентификация. Вы никогда не смените пароль без двух факторов. Второй фактор ДОПОЛНЯЕТ, а не заменяет пароль. То есть кроме такого же подбора пароля вам нужно ещё получить доступ ко второму фактору — телефону, аппаратному токену, и так далее.
В случае, если вторым фактором является подтверждение через коды в SMS, текстовое сообщение сводит надежность пароля до нуля
При чем тут надежность пароля? Надежность пароля ровно такая же, как и до этого. Просто кроме самого пароля вам нужно иметь в руках телефон. Следовательно пароль ниже никогда не станет.
Мне кажется, вы тоже не до конца понимаете что такое двухфакторная аутентификация.
К сожалению, хорошо работающие меры защиты при комбинировании, порой, могут дать обратный результат лишь повысив шанс взлома.
Я так и не понял из статьи, как пароль может быть надежнее пароль+второй фактор, при условии что пароль тот же? А это как раз то, что вы говорите в заголовке.
На самом деле нужно просто обозначить, а что мы, собственно, меряем. Ибо в зависимости от выбранных метрик получатся совершенно разные результаты. Ещё сложнее то, что нужно учитывать взаимодействие с пользователем, к примеру, рендер первого скрина за 100 мс и рендер интерактивной страницы за ещё 1500 мс может быть предпочтительно полному рендеру интерактивной страницы за 1000 мс, если она всё это время белая без содержимого.
Короче, неблагодарное дело вот это всё без четких критериев:)
А зачем отрисовка? Пусть отрисовывается позже, это ведь только часть страницы, в реальности вы же не будете после инициализации каждого виджета делать отрисовку, впрочем, как и раскладку (если ориентироваться на производительность, то обоих должно быть минимум).
Да, если вы действительно хотите отрендерить, тогда вместо setTimeout() лучше container.offsetHeight, это синхронно вызовет нужные эффекты. Но если на чистоту, то и $mol не рендерит весь список:) Похожий механизм ленивого рендеринга есть и в Polymer: https://elements.polymer-project.org/elements/iron-list
Я с другими инструментами не знаком:) Был бы Polymer — его бы тоже оптимизировал, но с прочими предоставленными не работал, так что извините.
Как по мне — так производительность фреймворка это на самом деле количество оверхеда, который он привносит. То есть он не может быть быстрее платформы. Понятно, что в более сложных ситуациях вам может быть не очень удобно всё писать без фреймворка, но это не отменяет того факта, что ни $mol, ни React не могут обогнать платформу, которую они используют под капотом.
Бенчмарки, конечно, странные. Меня привлекло что какая-то (не важно какая) библиотека может в принципе быть быстрее платформы. Я решил немного исправить бенчмарк: https://github.com/eigenmethod/mol/pull/62
Прирост получился ~20x в Firefox Nightly и ~10x в Chromium Nightly.
Теперь в Chromuim даже повторный рендеринг $mol вдвое медленнее обычного нативного рендеринга:)
Мне кажется, что интеграция Gitd семейство IDE от JetBrains уже имеет подход гораздо ближе к Gitless. Все эти staging/stashing и правда весьма сложно понять изначально.
Такое обычно подсказывает IDE. В JS всё сложнее, там подсказки паршиво работают, но вот для PHP всё очень даже хорошо, в Java есть типизация, тоже должно быть отлично.
Нужно различать смену и восстановление. Если вы забыли пароль — на почту (к примеру) отправляется ссылка на восстановление (у Google/Yandex/Hetzner есть возможность отправлять на резервный email). Но перейдя по ссылке вам всё ещё нужно будет ввести второй фактор, тот же код из смс.
Если бы написанное мной не было правдой, то зачем вообще придумывали двухфакторную аутентификацию, если она на порядок упрощает взлом людей, находящихся рядом?
На то он и резервный адрес. Аналогично есть резервные коды восстановления на случай если у вас нет устройства, которое генерирует TOTP токены. То есть формально вы можете даже не иметь доступа к устройству.
Совершенно согласен.
Чем второй этап (после пароля) отличается от ввода второго фактора (после пароля)?
А какая разница, смс или TOTP? Первый фактор/этап ведь пароль. Это два названия одного подхода.
Вот у Namecheap приходит смс, у множества других сервисов типа GitHub, Google, Facecbook, vk.com — TOTP. Это сути не меняет.
Он может приходить на украденное устройство, но на устройстве не должно быть доступного пароля. Если пароль в голове а второй фактор на украденном телефоне, то система всё ещё работает.
Нет, не может. Войдите с неизвестного компьютера (достаточно открыть окно в приватном режиме) и запустите процедуру восстановления пароля. А потом расскажите нам об успехах.
Кто вам доктор, что вы положили два яйца в одну корзину? Это не будет двухфакторной (двухэтапной) аутентификацией, ибо у вас оба фактора одинаковые, а должны быть разными (один то, что вы знаете — пароль, второе что вы имеете — телефон, аппаратный генератор токенов). В этом случае получение доступа к одному из факторов не позволяет войти в систему или изменить пароль.
Двухэтапная значит что у вас есть два этапа. Первый: ввод пароля. Второй: ввод кода смс (к примеру).
Следовательно, вы не приступите ко второму этапу, не пройдя первый. То же самое во время ввода пароля, получения смс не достаточно для смены пароля, иначе какой в этом смысл? Кто-то называет это этапами, кто-то факторами. Суть не меняется.
Вы не понимаете что такое двухфакторная аутентификация. Вы никогда не смените пароль без двух факторов. Второй фактор ДОПОЛНЯЕТ, а не заменяет пароль. То есть кроме такого же подбора пароля вам нужно ещё получить доступ ко второму фактору — телефону, аппаратному токену, и так далее.
При чем тут надежность пароля? Надежность пароля ровно такая же, как и до этого. Просто кроме самого пароля вам нужно иметь в руках телефон. Следовательно пароль ниже никогда не станет.
Мне кажется, вы тоже не до конца понимаете что такое двухфакторная аутентификация.
Не кажется, вы тоже не понимаете что такое двухфакторная аутентификация. Если второй фактор смс/звонок, то для входа вам нужен И пароль, И смс/звонок.
Какам образом использование второго фактора что-либо упрощает?
Какая ещё СМС? Вы вообще понимаете что такое двухфакторная аутентификация?
Я так и не понял из статьи, как пароль может быть надежнее пароль+второй фактор, при условии что пароль тот же? А это как раз то, что вы говорите в заголовке.
На самом деле нужно просто обозначить, а что мы, собственно, меряем. Ибо в зависимости от выбранных метрик получатся совершенно разные результаты. Ещё сложнее то, что нужно учитывать взаимодействие с пользователем, к примеру, рендер первого скрина за 100 мс и рендер интерактивной страницы за ещё 1500 мс может быть предпочтительно полному рендеру интерактивной страницы за 1000 мс, если она всё это время белая без содержимого.
Короче, неблагодарное дело вот это всё без четких критериев:)
А зачем отрисовка? Пусть отрисовывается позже, это ведь только часть страницы, в реальности вы же не будете после инициализации каждого виджета делать отрисовку, впрочем, как и раскладку (если ориентироваться на производительность, то обоих должно быть минимум).
Не сложно, а именно лень.
Да, если вы действительно хотите отрендерить, тогда вместо
setTimeout()лучшеcontainer.offsetHeight, это синхронно вызовет нужные эффекты. Но если на чистоту, то и $mol не рендерит весь список:) Похожий механизм ленивого рендеринга есть и в Polymer: https://elements.polymer-project.org/elements/iron-listПисать бенчмарк для Polymer ленюсь)
Я с другими инструментами не знаком:) Был бы Polymer — его бы тоже оптимизировал, но с прочими предоставленными не работал, так что извините.
Как по мне — так производительность фреймворка это на самом деле количество оверхеда, который он привносит. То есть он не может быть быстрее платформы. Понятно, что в более сложных ситуациях вам может быть не очень удобно всё писать без фреймворка, но это не отменяет того факта, что ни $mol, ни React не могут обогнать платформу, которую они используют под капотом.
Бенчмарки, конечно, странные. Меня привлекло что какая-то (не важно какая) библиотека может в принципе быть быстрее платформы. Я решил немного исправить бенчмарк: https://github.com/eigenmethod/mol/pull/62
Прирост получился ~20x в Firefox Nightly и ~10x в Chromium Nightly.
Теперь в Chromuim даже повторный рендеринг $mol вдвое медленнее обычного нативного рендеринга:)
Мне кажется, что интеграция Gitd семейство IDE от JetBrains уже имеет подход гораздо ближе к Gitless. Все эти staging/stashing и правда весьма сложно понять изначально.
Такое обычно подсказывает IDE. В JS всё сложнее, там подсказки паршиво работают, но вот для PHP всё очень даже хорошо, в Java есть типизация, тоже должно быть отлично.