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