Последствия безопасности хранения пароля в Settings.bundle и получении с CFPreferencesCopyAppValue
Не думайте о "получателе, являющемся нолем"; я соглашаюсь, это довольно странно. При отправке сообщения в ноль нет никакого получателя. Вы ни во что просто отправляете сообщение.
то, Как иметь дело с этим, является философским различием между Java и Objective C: в Java это - ошибка; в Objective C это нет.
2 ответа
CFPreferencesCopyAppValue - это просто основной способ доступа к той же информации, которую вы получаете при использовании NSUserDefaults . С точки зрения безопасности функции точно такие же. То есть не зашифровано. Это безопасно только в том смысле, что скрыто. «Правильный» ответ - использовать связку ключей.
Противодействие этому в том, что многие приложения используют NSUserDefaults для хранения паролей. Вы можете возразить, что если пароль не контролирует доступ к любой информации, то попытки использовать связку ключей не стоит усилий. Это подводит меня ко второму аргументу в пользу использования защищенного поля в приложении «Настройки»: API связки ключей ужасен, и, по крайней мере, по моему опыту, писать безошибочный код сложно.
Связка ключей на iPhone будет наиболее безопасной, если вы не используете специальное шифрование, которое очень сложно сделать (и экспортировать). NSUserDefaults не считается безопасным.