Смягчение утечек учетных данных с помощью дампов памяти в Java

Question

Мы все знаем, что пароли / учетные данные в Java должны храниться как массив символов.Это смягчение, а не защита.

Я всегда храню свои учетные данные, не используя неизменяемые объекты, но рано или поздно мне нужно передать их в некоторый класс, который ожидает String (из всех 3-х библиотек, которые мы используем).Разве не все усилия ушли?Например: если я хочу установить заголовок авторизации, значение заголовка сохраняется как строка в классе org.apache.http.message.BasicHeader.Другой пример (может быть, не очень хороший): я использую сервис, который работает с паролями (хранит их или что-то еще).Это требует их как тело в запросе POST.Я создаю HttpPost и добавляю StringEntity в качестве тела.Он уже сохранен как String и может быть снова выгружен.

Удалось ли вам сохранить свои учетные данные относительно безопасными от дампов памяти?

Спасибо

Answer 1

После обращения к некоторым специалистам по безопасности в этой области я получил следующий ответ:

1. Хранение учетных данных как char [] в Java - это второй уровень защиты.Первый - не разрешать им создавать дамп памяти.
2. Если первый уровень пройден, мы можем уменьшить количество учетных данных, которые они найдут в памяти.
3. Не использовать сторонние библиотекипочти невозможно в наше время.Однако во всех моих примерах сторонние библиотеки содержат ссылку на мой пароль в течение короткого периода времени.Тот факт, что они хранят его как String, не означает, что мы не должны хранить его должным образом.Мы должны стремиться не хранить учетные данные в виде строк, особенно в кэш-памяти или в других местах, где ссылка на этот объект хранится в течение длительного времени.