Т.е. единственная разница в том, что мы вводим не пароль, а хеш от пароля, и в этом безопасность?
Скорее безопасность в том, что мы не подвергаем опасности второй фактор - пароль и ТОТП подвержены разным векторам атаки.
Если пароль ты хранишь в уме, а ТОТП установил на доверенное устройство - тотп это вполне фактор владения этим устройством.
Это базовый сценарий. А всё остальное, когда мы привносим сюда парольные менеджеры, установку ТОТП на десятки устройств одновременно - более сложные случаи.
Только secret key от ТОТП не может быть скомпрометирован при логине, в отличие от пароля.
Угроз же множество, от многих из которых ТОТП вполне себе защищает. Понятно, что если у вас взломают устройство на котором у вас и парольный менеджер и ТОТП генерятся, то ТОТП тут никак не поможет.
СМС плохи тем, что перехватить их может крайне большой спектр лиц. Слишком ненадёжный канал передачи, с заведомо встроенными бекдорами на каждом из шагов.
Многие менеджеры TOTP не предоставляют возможность его экспортнуть. Если вы его экспортите на многие устройства или даже складываете в тот же парольный менеджер, где храните пароль - вы сами нарушаете концепцию. Но даже тогда он остаётся полезен: Перехватив пароль, его можно использовать сколь угодно и когда угодно. Пароль может быть скомпрометирован и другими способами (например угнали и расшифровали базу другого сайта, а у вас одинаковые пароли). ТОТП в данном случае защитит и вполне является вторым фактором.
ТОТП с некоторыми оговорками вполне себе фактор владения, если специально не ломать. А если заведёте отдельное устройство для ТОТП - вообще будете молодцом.
Это нужно шарить контекст на двоих, гранулярнее нарезать задачи, не получится работать над одним и тем же кодом вдвоём одновременно и прочие менеджерские издержки. Эти двое еще и кофе будут пить вместе 10 раз в день.
Но конечно, почти наверняка суть в том что там нет и х1.5
Ещё в ssh agent ключи можно грузить прямо из менеджера паролей.
Некоторые ещё могут спрашивать у пользователя разрешения не доступ программы к ключу. Да и сам ключ не передается программе, а сам агент выполняет аутентификацию.
В ключах на диске мне всегда не нравилось что любая программа может воспользоваться ключом.
По идее, чтобы следовать принципу 2FA база паролей и база TOTP токенов не должны быть на одном устройстве.
Используя менеджер паролей мы фактически подменяем фактор знания на фактор владения базой паролей. И если если генерировать TOTP токены на том же устройстве, где пользуемся менеджером паролей, то при компрометации одного устройства компрометируются оба фактора.
В общем это конечно добавляет безопасности, но противоречит 2FA.
Желающих попасть на стажировку больше чем мест. Нужно как-то ранжировать кандидатов. При этом у них нет реального опыта. Что ещё спрашивать, кроме алгоритмов?
В секции нет правильных и неправильных решений, и непонятно что делал его знакомый "решив не так, как хотел интервьювер".
В секции оценивается как раз то, как кандидат уточняет функциональные и нефункциональные требования, как размышляет, какие предполагает сценарии нагрузки, какие паттерны проектирования знает и использует, знает ли узкие места предложенного решения и предлагает ли какие-то варианты их устранения, софт скиллы. Именно поэтому на старте даются хоть как-то существенные значения по нагрузке/обёму данных, чтобы было о чем поговорить.
А сама архитектура системы достаточно вторична, если примерно удовлетворяет требованиям.
Скорее безопасность в том, что мы не подвергаем опасности второй фактор - пароль и ТОТП подвержены разным векторам атаки.
Если пароль ты хранишь в уме, а ТОТП установил на доверенное устройство - тотп это вполне фактор владения этим устройством.
Это базовый сценарий. А всё остальное, когда мы привносим сюда парольные менеджеры, установку ТОТП на десятки устройств одновременно - более сложные случаи.
Только secret key от ТОТП не может быть скомпрометирован при логине, в отличие от пароля.
Угроз же множество, от многих из которых ТОТП вполне себе защищает.
Понятно, что если у вас взломают устройство на котором у вас и парольный менеджер и ТОТП генерятся, то ТОТП тут никак не поможет.
СМС плохи тем, что перехватить их может крайне большой спектр лиц.
Слишком ненадёжный канал передачи, с заведомо встроенными бекдорами на каждом из шагов.
Многие менеджеры TOTP не предоставляют возможность его экспортнуть. Если вы его экспортите на многие устройства или даже складываете в тот же парольный менеджер, где храните пароль - вы сами нарушаете концепцию. Но даже тогда он остаётся полезен:
Перехватив пароль, его можно использовать сколь угодно и когда угодно. Пароль может быть скомпрометирован и другими способами (например угнали и расшифровали базу другого сайта, а у вас одинаковые пароли). ТОТП в данном случае защитит и вполне является вторым фактором.
ТОТП с некоторыми оговорками вполне себе фактор владения, если специально не ломать. А если заведёте отдельное устройство для ТОТП - вообще будете молодцом.
Это нужно шарить контекст на двоих, гранулярнее нарезать задачи, не получится работать над одним и тем же кодом вдвоём одновременно и прочие менеджерские издержки.
Эти двое еще и кофе будут пить вместе 10 раз в день.
Но конечно, почти наверняка суть в том что там нет и х1.5
Если такими требованиями обусловлена зарплата х2 от рынка, то почему нет, желающие найдутся.
Ещё в ssh agent ключи можно грузить прямо из менеджера паролей.
Некоторые ещё могут спрашивать у пользователя разрешения не доступ программы к ключу. Да и сам ключ не передается программе, а сам агент выполняет аутентификацию.
В ключах на диске мне всегда не нравилось что любая программа может воспользоваться ключом.
В nuts поддержка самых странных протоколов есть. А если нет - можно бросить силы на из поддержку.
Решал то же самое просто ретрансляцией magic пакета полученного извне на широковещательный адрес локалки.
Можно любой ПК включать, а не прибитый в конфиге mac.
По идее, чтобы следовать принципу 2FA база паролей и база TOTP токенов не должны быть на одном устройстве.
Используя менеджер паролей мы фактически подменяем фактор знания на фактор владения базой паролей.
И если если генерировать TOTP токены на том же устройстве, где пользуемся менеджером паролей, то при компрометации одного устройства компрометируются оба фактора.
В общем это конечно добавляет безопасности, но противоречит 2FA.
Из двухфакторной авторизации получается что-то странное.
Фактор владения и фактор знания где-то перемешиваются в вашем менеджере паролей, где наверняка хранятся gpg ключи и пароли от сайтов.
Желающих попасть на стажировку больше чем мест. Нужно как-то ранжировать кандидатов. При этом у них нет реального опыта. Что ещё спрашивать, кроме алгоритмов?
Из графика видно, что мы ускорили 250 медленных запросов, замедлив миллион относительно быстрых.
Можно запретить пушить в репозитории коммиты без подписи.
Нужно сделать перелив, как в сливных бачках в туалете, если клапан пропускает - перелив просто в канализацию, и ничего не заливает.
И минимальным требованием к кандидатами сделать умение настаивать vpn.
У KeePass есть фатальный недостаток.
Пока мы отображаем большее множество URL адресов на меньшее множество хешей, коллизии будут у любого алгоритма хеширования.
Иначе сервис перестаёт быть сокращателем ссылок.
Это же стандартный вопрос с system design секции.
В секции нет правильных и неправильных решений, и непонятно что делал его знакомый "решив не так, как хотел интервьювер".
В секции оценивается как раз то, как кандидат уточняет функциональные и нефункциональные требования, как размышляет, какие предполагает сценарии нагрузки, какие паттерны проектирования знает и использует, знает ли узкие места предложенного решения и предлагает ли какие-то варианты их устранения, софт скиллы.
Именно поэтому на старте даются хоть как-то существенные значения по нагрузке/обёму данных, чтобы было о чем поговорить.
А сама архитектура системы достаточно вторична, если примерно удовлетворяет требованиям.
Снапшот - это не бэкап.