2016-04-16 4 views
1

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

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

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

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

ответ

0

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

+0

Я думал, что HTTPS гарантирует, что весь HTTP-протокол будет зашифрован. Разве это не так? Как вы предлагаете мне шифровать пароль? Я должен использовать JavaScript для шифрования клиентской стороны и Java на стороне сервера. Я не понимаю, почему HTTPS (используя TLS) недостаточно для шифрования. – Gronis

+0

Несчастливо https не гарантирует 100% самой безопасности. Сделайте быстрый поиск в Google по «проблемам безопасности https». И да, вы можете использовать Javascript для обозначения стороны клиента. –

+0

Согласно этому сообщению SO http://security.stackexchange.com/questions/33793/handling-passwords-in-a-web-application, использование HTTPS является предпочтительным. Кроме того, можно сказать, что HTTPS небезопасен, способ исправить это не будет реализовывать библиотеку javascript и составить собственный протокол безопасности, как общаться, потому что этот протокол, скорее всего, будет иметь проблемы с безопасностью. Лучший способ сделать это - обновить стандарт безопасности (SSL/TLS), который был в последний раз обновлен в 2011 году. Вы уверены, что TLS RFC 6176 небезопасен? – Gronis