Удаление конфиденциальных данных из памяти при использовании Spark Java (веб-сервер)

Question

Я использую SparkJava, и я разбираюсь в паролях. Идея состоит в том, чтобы передать пароль (в обычном тексте) на сервер (очевидно, под https), а затем на стороне хэша и солевого сервера, и сохранить соль и хеш на сервере для пользователя. Однако в соответствии с этим post пароль простой текстовой информации никогда не должен храниться в виде строки в памяти по соображениям безопасности.

Однако при доступе к телу HTTP-протокола из запроса POST с использованием SparkJava API возвращает строку, содержащую пароль открытого текста.

Route post = (request, response) -> { 
    String dataWithPassword = request.body(); 
    //  ^-- Stays in memory until GC kicks in 
} 

Как я должен сделать, чтобы убедиться, что текстовый пароль, который был получен от клиента не хранится в виде строки ServerSide, так что это никогда не может быть потенциальной дырой в безопасности? Или есть что-то еще, что я могу сделать, чтобы убедиться, что память очищена, а пароль незашифрованного текста не задерживается в памяти?

Answer 1

То, как вы это делаете, уже гарантировано, что этот пароль никогда не будет сохранен в файле, как журнал сервера. Но на Java нет официального способа очистки памяти. Вы ничего не можете сделать, чтобы гарантировать, что память, содержащая открытый текстовый пароль, будет очищена. Вы даже можете установить ссылочные данныеWithPassword в null и вызвать System.gc(), которые предполагают, что сейчас самое подходящее время для запуска сборщика мусора, но не гарантировано, что эта память будет очищена. Я вижу, что возможная проблема безопасности в вашем подходе заключается в том, чтобы отправить пароль в виде простого текста с клиента на сервер, даже с помощью https (я настоятельно не предлагаю этого). Лучшее, что вы могли бы сделать, это потребовать от клиента o дать вам пароль, уже зашифрованный, чтобы вам не нужно было беспокоиться об этом значении в памяти, и вы получите гораздо больше проблем с безопасностью, так как сетевые снифферы и прокси-серверы будут теперь не пароль.