Лидеры

В интернет магазинах не рекомендую покупать слишком дорогую электронику. Лучше в официальных точках продаж, где тебе дадут чек и гарантию.

Уже говорил, но повторюсь, что это не совсем музей, а больше этакая "авто-энциклопедия" в полном масштабе. Если здесь начинают что-то собирать, то получается не несколько экспонатов, а все (или практически все) модели конкретного брэнда, когда-либо сходившие с конвейера. Вот, например, так выглядит энциклопедия мотоциклов: А вот раздел авто-крошек. Вы вообще знали о существовании этих... микро-существ? "Rovin D2" - слышали о таком?? Вот ещё: Нано-Фиат: Ещё кто-то совсем малоизвестный.. А этот гробик называется... Вот он называется... Вот такой красивый и даже двухместный - Мессершмитт! БМВ Изетта - аж две штуки! Насколько мне напоминает мой внутренний склероз, в музее БМВ в Мюнхене стоит всего одна Изетта... Фиат зелёного корпоративного цвета.. О! Отечественные аналоги 🙂 Маруся! Так вот как ты выглядишь... Но уже всё, полный перебор, в секции формульных болидов мы уже бывали - достаточно на сегодня, пробегаем мимо и быстро... А на улице стоит вот такой красавец - А также можно покататься по территории, чем я обязательно воспользовался. Всё на этом - всем срочно в Верхнюю Пышму! Можно с детьми, но тогда на недельку, не меньше.

А теперь мы идём в новый, только что открытый корпус - здесь мы ещё ни разу не были... И на входе - экспериментальное шасси 1927 года от НАМИ. Как нам объяснили, от данной разработки отказались и руководство Партии и Правительства решило проект закрыть и закупить полный цикл производства у компании Форд - ну, а дальше история известная.. Наверное, начать в кратчайшие сроки локализовать и начать выпуск автомобилей и грузовиков - это была архиважнейшая и критическая задача. Но вот закрывать при этом отечественные разработки - это совершенно неправильно, как мы теперь все очень хорошо знаем на своей шкуре... Опель... но его историю я что-то не запомнил. Некоторые автомобили до конца не реставрируют, чтобы показать в каком виде они попадают в музей: \ Ну а эти Форды-ТТ все в идеальном состоянии. И в разных комплектациях. Тоже не до конца отреставрированный Бьюик - Ситроен Фантомаса! Эх, детство... Для тех, кто не в курсе - это про фильмы с Фантомасом, весьма популярные в 60-70 годы прошлого века (а я там уже был). Эээ... не запомнил. Ещё раз: это мы идём по новым залам Музея Техники УГМК в городе Верхняя Пышма. О какой "шестисотый"! На этом мозг уже начинает переставать реагировать на внешние раздражители, но рука по инерции продолжает нажимать на кнопки фотика... Советская авто-техника на парадах! Вот как оно там внутри всё устроено - чтобы можно было ехать стоя... Ну, вот эта коллекция уже попроще 🙂 Милицейский снегоход?? - не знал... Не катался 🙂 "Членовозы" - как их ласково называли в советское время. Но конкретно эти машины просто дублируют основную экспозицию в другом здании.

И проходя мимо очередной автодревности мне вдруг захотелось вывернуть мой объектив-ширик на полную и попробовать сделать вот так: А вроде неплохо получилось, необычненько! Ну я и пошел строчить портретные шедевры 🙂 Селфи 🙂 Ух, ну и сколько их здесь?... А дальше - ещё больше... Какой-то весьма заслуженный ветеран, весь в наградах - БМВ, Мерседес, Хорьх - чего здесь только нет... Однодверный Хейнкель! А мне раньше казалось, что Изетта была уникальным автомобилем...

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