Менеджеры паролей являются важной частью набора инструментов безопасности как для потребителей, так и для предприятий. Они позволяют вам использовать случайные надежные пароли для каждой из ваших учетных записей в Интернете, помогая защититься от риска раскрытия паролей в результате утечки с сайтов из-за неэффективных методов шифрования. Они также поддерживают все больше и больше функций, таких как автоматический вход в систему, хранение кодов TOTP 2FA (плохая идея, но, увы) и, что особенно важно, синхронизация ваших паролей между устройствами.
Хранение ваших паролей в хранилище не является чем-то новым — такое программное обеспечение, как KeePass, существует уже несколько десятилетий, — но синхронизация ваших паролей между устройствами — это нечто новое. На самом деле это решающий элемент, который сделал нынешнее поколение облачных менеджеров паролей жизнеспособным. Вы бы использовали менеджер паролей, который требовал бы вручную копировать каждый пароль на другие устройства при каждом его обновлении?
Но если ваши пароли синхронизируются между устройствами с помощью облачного провайдера, означает ли это, что ваши пароли доступны вашему облачному провайдеру?
Ваш провайдер не может прочитать ваши пароли
Никто не хочет брать на себя ответственность за сохранность паролей каждого
Простой ответ: нет, ваш облачный провайдер не может прочитать ваши синхронизированные пароли. Это может показаться немного очевидным. В конце концов, предоставлять облачному сервису ответы на ваши пароли в виде простого текста было бы ужасной идеей, но решить эту проблему на удивление сложно. Он работает путем шифрования ваших паролей локально на вашем устройстве перед отправкой их вашему провайдеру, гарантируя, что ваш провайдер всегда получит только ваши зашифрованные пароли. Эти пароли зашифрованы ключом, полученным из вашего главного пароля (по сути, составленным из него), гарантируя, что без доступа к вашему главному паролю в виде открытого текста даже ваш провайдер не сможет расшифровать ваши данные.
Важным элементом здесь является то, что приложения и программное обеспечение, которые вы используете локально, находятся в безопасности, поэтому лучшие поставщики обычно регулярно проверяют свои приложения надежными фирмами по обеспечению безопасности или даже публикуют код, открывая его с открытым исходным кодом. кодовая база. Когда вы входите в систему на новом устройстве, ваш зашифрованный дамп пароля загружается на ваше локальное устройство, а затем расшифровывается с использованием получения ключа на основе вашего главного пароля.
Это известно как архитектура с нулевым разглашением, когда поставщик услуг не знает данных, хранящихся на его платформе. Провайдер берет на себя ответственность за хранение и передачу информации, но не имеет возможности доступа к ней.
Менеджеры паролей используют хитрый трюк при регистрации
Если вы внимательно следите, возможно, вы заметили проблему. При входе на новом устройстве пользователь должен сначала пройти аутентификацию у поставщика услуг, прежде чем ему будет разрешено загрузить хранилище паролей. После аутентификации приложение загружает хранилище паролей, а затем расшифровывает его с помощью ключей, полученных из главного пароля пользователя. Пока все хорошо, но если пользователь аутентифицируется у провайдера с помощью своего пароля, наверняка провайдеру услуг нужно иметь какое-то представление о пароле для аутентификации пользователя? Поставщик услуг не видит пароль, когда пользователь входит в систему с нового устройства, что позволяет ему расшифровать хранилище?
Хитрость здесь происходит, когда пользователь регистрируется. Вместо передачи открытого текста пароля на сервер (открытый текст, защищенный только через HTTPS/SSL), как вы обычно делаете при входе в приложение онлайн, клиент сам хеширует пароль, а затем отправляет его провайдеру. Провайдеры обычно делают это на стороне сервера, так как это усложняет, например, смену пароля. Поставщик видит только «хешированную» версию пароля.
Клиент передает только хешированный пароль.
Хеширование — это односторонняя функция, которая берет исходный пароль и извлекает из него хэш. Этот хэш можно воссоздать в любое время, используя исходный пароль, но это делает невозможным восстановление исходного пароля из хеша, что делает его односторонним. Это важно практически для любого онлайн-сервиса, поскольку позволяет провайдерам хранить пароли таким образом, чтобы их можно было проверить, но не хранить в виде открытого текста.
В менеджерах паролей эта функция хеширования выполняется локально при регистрации. Это означает, что приложение никогда не передает ваш пароль напрямую провайдеру, позволяя ему хранить только хэш. При входе в систему с новых устройств каждое устройство может хешировать главный пароль и отправлять его на серверы провайдера, не раскрывая исходный главный пароль провайдеру.
Реализации у разных поставщиков здесь могут различаться, но это общий обзор того, как работают менеджеры паролей с нулевым доверием.
А как насчет смены пароля?
Когда вы меняете пароль, весь процесс повторяется локально. Ваш менеджер паролей проверяет подлинность у провайдера, загружает и расшифровывает ваше хранилище, а затем повторно шифрует его с помощью нового пароля. Затем он отправляет хэш пароля и зашифрованное хранилище обратно провайдеру для хранения.
Забудьте о сбросе пароля
Недостатком этой архитектуры является то, что вы можете забыть о возможности сброса пароля. Поскольку ваше хранилище зашифровано вашим мастер-паролем, а ваш поставщик услуг не имеет доступа к вашему исходному мастер-паролю, он физически не сможет расшифровать ваше хранилище за вас. Это может стать серьезной проблемой, если вы забудете пароль к своему менеджеру паролей.
Хотя есть некоторая отсрочка. Во время первоначальной настройки вам предоставляется возможность генерировать коды восстановления. Они, как правило, работают по-разному от службы к службе, но обычно представляют собой одноразовые коды, которые позволяют вам восстановить свою учетную запись, если вы потеряли пароль. Криптография здесь становится немного сложнее. Как правило, это работает либо путем а) шифрования исходного хранилища с помощью многоключевого алгоритма, позволяющего использовать несколько новых ключей поверх ключей, полученных из вашего главного пароля, либо б) шифрования второй копии ключей, используемых для расшифровки. ваше хранилище с вашими кодами восстановления, что позволяет получить исходные ключи с помощью кода восстановления. Это может быть сложно реализовать безопасно, и некоторые крупные менеджеры паролей добавили его только недавно (1Password добавил поддержку только в июне этого года).
Если вам интересно узнать больше о том, как работают коды восстановления в менеджерах паролей, 1Password описал свое техническое решение в своем блоге.
Менеджеры паролей — это умные компоненты
Криптография, как известно, сложна, поэтому мы пропустили здесь некоторые наиболее сложные детали, но, надеюсь, это рисует хотя бы часть картины магии шифрования, происходящей под капотом ваших любимых менеджеров паролей. По своей сути облачные менеджеры паролей могут показаться ужасной идеей, но с большим количеством умных математических вычислений и хорошими аудиторами безопасности они могут стать одним из лучших способов защитить вашу личную кибербезопасность.
