Скорее, все шифруется хешем пароля от iCloud. А Touch ID — это чисто локальная для девайса вещь, она даже никуда не передается по сети.
Чтобы ее «украсть», надо не только украсть физически процессор из девайса, но и как-то переместить данные из его secure enclave в защищенную область другого процессора.
Пока таких случаев известно не было, насколько я знаю.
Нет, не только браузерных полей. И на iOS и на Android есть возможность автоматического заполнения полей и в нативных приложениях.
Авторизация на телефоне через распознавания лица, на компьютере — распознавание пальца. Конечно, мастер-пароль есть, но это не «общий случай».
И конечно, компроментации этого пароля недостаточно чтобы все пароли улетели. Вход в iCloud, где пароли хранятся и синхронизируются между устройствами, защищен двухфакторной авторизацией.
Я пароли даже не то, чтобы забываю — я их изначально не знаю. Просто соглашаюсь с тем, который автоматически генерируется при регистрации и тот же пароль автоматически подставляется впоследствии на этом сайте, если даже я потом зашел туда с телефона.
Понятно, что для этого нужно авторизоваться, например, телефон должен узнать меня в лицо и я должен смотреть на экран в этот момент.
Конечно, раньше я тоже помнил пароли, имел системы их придумывания/вспоминания. Но все равно образуется какой-нибудь текстовый файлик в запароленном архиве с секретными данными, типа кодов восстановления двухфакторной авторизации и проч.
Но после того, как 10 лет назад я увидел, что можно это организовать на системном уровне в виде Связки ключей или другого менеджера паролей, я предпочитаю использовать эти решения.
Хорошая память — это отлично, но у меня около 650 сохраненных паролей типа «7qq-gRW-73m-tqn» и моя память, видимо, уже достаточно дырява, чтобы это запомнить.
Именно поэтому мне кажется использование менеджеров паролей очень оправданным. В Эппл-экосистеме одно и то же хранилище используется для автозаполнения паролей в мобильных приложениях. Причем, в последнее время для автозаполнения достаточно распознавания лица или пальца.
Бекап хранилища ничем не отличается от бекапа обычного файла.
Другие экосистемы тоже имеют свои менеджеры паролей. Для Андроида, например, точно есть.
Это тоже мое утверждение, но вы возражали на комментарий, который содержит другое.
Что касается именно этого, то я по-прежнему считаю, что плохой код — это плохая работа, но выяснится это после того, как плохой код проявит себя дополнительными затратами ресурсов, связанными с ним.
Оплата хостинга и проч. не связана с существованием вашего кода, это не дополнительные затраты на вашу работу.
Если же вам заказали не код сайта, а просто чтобы сайт был и работал, а вы не оговорили заранее затраты на хостинг, то вы действительно плохо поработали с клиентом.
Ни один из этих вариантов моему определению не противоречит.
Чтобы ее «украсть», надо не только украсть физически процессор из девайса, но и как-то переместить данные из его secure enclave в защищенную область другого процессора.
Пока таких случаев известно не было, насколько я знаю.
Авторизация на телефоне через распознавания лица, на компьютере — распознавание пальца. Конечно, мастер-пароль есть, но это не «общий случай».
И конечно, компроментации этого пароля недостаточно чтобы все пароли улетели. Вход в iCloud, где пароли хранятся и синхронизируются между устройствами, защищен двухфакторной авторизацией.
Понятно, что для этого нужно авторизоваться, например, телефон должен узнать меня в лицо и я должен смотреть на экран в этот момент.
Конечно, раньше я тоже помнил пароли, имел системы их придумывания/вспоминания. Но все равно образуется какой-нибудь текстовый файлик в запароленном архиве с секретными данными, типа кодов восстановления двухфакторной авторизации и проч.
Но после того, как 10 лет назад я увидел, что можно это организовать на системном уровне в виде Связки ключей или другого менеджера паролей, я предпочитаю использовать эти решения.
Именно поэтому мне кажется использование менеджеров паролей очень оправданным. В Эппл-экосистеме одно и то же хранилище используется для автозаполнения паролей в мобильных приложениях. Причем, в последнее время для автозаполнения достаточно распознавания лица или пальца.
Бекап хранилища ничем не отличается от бекапа обычного файла.
Другие экосистемы тоже имеют свои менеджеры паролей. Для Андроида, например, точно есть.
Они же автозаполняются? Ну хорошо, не все используют макось, но другие браузеры ведь тоже заполняют?
А вот что будет с самонарисованными градиентами и цветами, надо посмотреть.
Что касается именно этого, то я по-прежнему считаю, что плохой код — это плохая работа, но выяснится это после того, как плохой код проявит себя дополнительными затратами ресурсов, связанными с ним.
Возможно, существуют допзатраты, которые порождены другими причинами, я не знаю всех причин.
Я утверждаю, что плохая работа — это причина дополнительных затрат, но я нигде не говорил, что всех.
Напомню, что мое утверждение «плохая работа приводит к дополнительным затратам».
Эти два утверждения — не одно и то же.
Но дополнительные затраты по прежнему фигурируют и плохую работу определить помогают.
Именно это и есть объективный критерий ее определения.
d — допзатраты, В этот момент вы понимаете, что надо было делать по-другому. Оказалось, что эта работа была сделана плохо.
Вы ведь возражаете против показателя дополнительных затрат, как признака плохой работы.
Я прошу вас быть точнее, если вы действительно хотите показать логические недостатки этого утверждения, а не просто спорите ради спора.
Если же вам заказали не код сайта, а просто чтобы сайт был и работал, а вы не оговорили заранее затраты на хостинг, то вы действительно плохо поработали с клиентом.
Ни один из этих вариантов моему определению не противоречит.