Смягчить утечку учетных данных с помощью дампов памяти в Java
Мы все знаем, что пароли / учетные данные в Java должны храниться как массив символов. Его смягчение, а не защита.
Я всегда храню свои учетные данные, не используя неизменяемые объекты, но рано или поздно мне нужно передать их в некоторый класс, который ожидает String (из всех 3-х библиотек, которые мы используем). Разве не все усилия ушли? Например: если я хочу установить заголовок авторизации, значение заголовка сохраняется как строка в классе org.apache.http.message.BasicHeader. Другой пример (может быть, не очень хороший): я использую сервис, который имеет дело с паролями (хранит их или что-то еще). Это требует их как тело в запросе POST. Я создаю HttpPost и добавляю StringEntity в качестве тела. Он уже хранится как String и может быть сброшен снова.
Удалось ли вам сохранить свои учетные данные относительно в безопасности от дампов памяти?
Спасибо
1 ответ
Обратившись к некоторым специалистам по безопасности в этой области, я получил следующий ответ:
- Хранение учетных данных как char[] в Java - это второй уровень защиты. Во-первых, не разрешать им делать дамп памяти.
- Если первый уровень пройден, мы можем уменьшить количество учетных данных, которые они найдут в памяти.
- Не использовать сторонние библиотеки практически невозможно в наши дни. Однако во всех моих примерах сторонние библиотеки на короткий промежуток времени ссылаются на мой пароль. Тот факт, что они хранят его как String, не означает, что мы не должны хранить его должным образом. Мы должны стремиться не хранить учетные данные в виде строк, особенно в кэш-памяти или в других местах, где ссылка на этот объект хранится в течение длительного времени.