Лидеры

Кароч, давай разберёмся, как работают менеджеры паролей. Речь не про Каспера, а вообще. Есть хранилище паролей. Например, база данных, например sqlite - это вообще детали реализации Это хранилище шифруется на неком ключе Пользователь задаёт пароль для доступа к хранилищу Это очень поверхностно и, по идее, должно быть понятно. Спускаемся ниже Хранилище паролей может быть зашифровано с учётом пользовательского пароля или без него. Выбор определяется, как правило, размерами хранилища и целевым устройством. Когда это маленькая база, то даже телефон не подавится. Когда данные большие или их много, то перешифрование будет дико дорогой операцией. Чтобы понимать, почему это важно. Если у тебя привычка менять пароль, скажем, раз в месяц, целевым устройством является телефончик на Андроиде и шифрованные данные весят, скажем, 8 Гигабайт. Твой телефон просто сдохнет на операции перешифрования. Потому что это одновременно несколько операций: создать новый контейнер, открыть старый и копировать из старого в новый, на лету дешифруя данные на старом ключе и шифруя на новом. Потому на телефончиках так никто не делает и данные шифруются на другом ключе, генерируемом специальными API операционной системы. Следовательно, если твоя система - плохой на палке в дешёвом китайском телефоне за тыщу рублей, очень высока опасность, что системный метод создатьБезопасныйРандомДляШифрованияСуперВажныхДанных() вернёт тебе просто цепочку нулей и этими нулями всё зашифруется. Так что да, если тебе важна безопасность своих данных, ты не должен никогда покупать дешёвые телефоны с АлиЭкспресс. При этом настоящий ключ шифрования шифруется уже ключом, созданным на основе твоего пароля. То есть меняя мастер пароль, ты меняешь пароль для контейнера, в котором лежит настоящий ключ Итак, выяснили, что типичная реализация такая: Шифруем контейнер на ключе, сгенерированном локально на устройстве Шифруем ключ на пароле пользователя Теперь переходим к проблемам: Очень плохая среда может отдавать очень плохой ключ шифрования для контейнера. Это решается способами, зависящими от того, от чего мы скрываемся: Если мы скрываемся от Васяна, то достаточно иметь нормальный телефон или компьютер с нормальной операционной системой Если мы скрываемся от правительства США, Британии, Японии, Кореи, Китая или России, то нужно использовать свои устройства для генерации ключей, т.к. нельзя рассчитывать, что твой Intel или твой Exinos не создаёт очень хорошие ключи, но которые создатели этих процессоров не могут восстановить Плохой разработчик может использовать неправильные API для создания ключей. Я не буду показывать пальцем на тех, кто так делал. В итоге ключи будут предсказуемыми. То есть система тебе даёт API для генерации классных ключей, но разработчик просто не знает про их существование и дёргает привычные API, которые используют для примитивных вещей типа перетасовки буковок в предложении, а не для безопасности Плохой разработчик может вообще неправильно реализовать хранение ключа. Я не знаю, делал ли такую дичь хоть кто-то, потому что я её только что придумал, но в мире так много идиотов, что, возможно, кто-то и делал. В общем, разработчик может не шифровать ключ шифрования на твоём ключе, а просто валидировать, что ты ввёл правильный пароль и начинать дешифровку контейнера, при этом сам ключ будет лежать в открытом виде - бери не хочу Пользователь может ввести плохой пароль. Все нормальные разработчики всегда добавляют к пользовательскому паролю ещё свой хороший хвост, но этот хвост не является сверх тайной и может быть извлечён из приложения, что снова возвращает нас на плохой пароль пользователя. Потому атака контейнер с настоящим ключом, который шифрован на пароле пользователя, по-прежнему выгоднее атаки на сам контейнер с данными, т.к. тот, как правило, всё же шифрован очень хорошо на нормальном ключе, ведь его предоставила нормальная ОС, написанная нормальными людьми Я описываю только те проблемы, которые связаны с шифрованием. Утечку пароля пользователя по схемам типа "подсмотрели" или "записали экран" не рассматриваю. Итого, что мы получаем. Если шифрование сделано правильно и пользователь использует нормальный пароль в качестве мастер пароля, то контейнер можно хранить где угодно вообще, включая "облако" создателя приложения. Потому что стоимость взлома такого контейнера будет настолько дорога, что перекроет все деньги компании, которые они зарабатывают. Если же шифрование сделано плохо, то это ничем не отличается паролей на бумажке в кармане. Пока она в кармане - всё отлично. Как только вне кармана - всё пропало. Резюмируя. Не доверяешь ЛК - не пользуйся. Доверяешь - пользуйся. У тебя никаких способов проверить, что ЛК делает всё правильно. Доверят наполовину нельзя - типа, пусть менеджер паролей их, но облако не их. Реши для себя, считаешь ли ты, что разработчики ЛК достаточно знакомы с азами шифрования данных в разных ОС и правильно выполняют все правила и прими конечное решение. Перечитал текст и вижу, что сработала автоцензура. Там, где слово "плохой" выбивается из общего предложения, там было написано, на самом деле, г...но

Этот сайт только по http работает, по https не открывается.

В тот момент был недоступен нигде.

У меня доступен:

А с чего вы взяли, что сайт сейчас доступен? Он недоступен.

Всем огромное спасибо! Заодно определились 10 гостей на Новогодний ужин 🙂

Это нормально. Если бы что-то пошло не так, то была бы ошибка.

@Nucleus, вам нужно обновить корневые сертификаты. Потому что без этого могут быть проблемы с другими сайтами. Инструкция есть у меня в подписи. И, кстати, антивирус тоже хорошо бы обновить.

Скорее всего это ваш случай - https://www.safezone.cc/threads/ne-otkryvaetsja-sajt-oshibka-podkljuchenija-ssl-istek-sertifikat-r3-lets-encrypt.39406/

Ну и версию кав/кис/кес бы написать сразу же

Здравствуйте! Какая версия Windows у вас?

@Nucleus скриншот в первом сообщении не говорит о проблеме с DNS, а о тайм-ауте ожидания запроса.