Общее строковое шифрование
В случае сомнений проверьте Javadocs класса :
. Обратите внимание, что эта реализация не синхронизирована. Если несколько потоков обращаются к хэш-карте одновременно, и хотя бы один из потоков структурно изменяет карту, она должна быть синхронизирована извне. (Структурная модификация - это любая операция, которая добавляет или удаляет одно или несколько сопоставлений; простое изменение значения, связанного с ключом, который уже содержится в экземпляре, не является структурной модификацией.) Обычно это выполняется путем синхронизации с некоторым объектом, который естественным образом инкапсулирует карту , Если такого объекта не существует, карту следует «обернуть» с помощью метода Collections.synchronizedMap. Это лучше всего сделать во время создания, чтобы предотвратить случайный несинхронизированный доступ к карте:
Map m = Collections.synchronizedMap(new HashMap(...));
(акцент не мой)
Таким образом, на основе тот факт, что вы сказали, что ваши потоки будут удалять сопоставления с карты, ответ таков: да это определенно вызовет проблему, и да, это определенно небезопасно .
4 ответа
Если вы пытаетесь достичь той же цели, что и SecureString .NET, то ваш пример действительно не решает проблему. (Я мог неправильно понять ваши цели, и в этом случае прошу прощения.)
Идея .NET SecureString заключается в том, что он хранит строковые данные, зашифрованные в неуправляемом фрагменте памяти, является неизменяемым после создания и не может быть читать в .NET, используя обычную строковую переменную. Это защищает строку от всех, кто пытается исследовать пространство вашей памяти (например, вредоносных программ, червей, троянов и т. Д.), И должно быть очищено вами явным образом. Причины этого включают то, как .NET обрабатывает строки, и тот факт, что данные в памяти очищаются только по прихоти сборщика мусора.
Даже если ваш класс SecureString зашифровывает строку в частную переменную, исходная строка, которая была передано по-прежнему небезопасно. Он также может оставаться некоторое время, прежде чем сборщик мусора соберет его, или, если эта строка была интернирована, она будет жить в течение всего процесса, в котором находится. Интернированные строки хранятся в таблице, что также упрощает их поиск.
С другой стороны ... если вы расшифруете свою SecureString, вы получите новую строковую переменную, которая может столкнуться с теми же проблемами, что и входная строка ... она очищается только тогда, когда сборщик мусора решает ... и она также может быть интернирована и жить в течение всего процесса.
Чтобы усложнить проблемы, каждый раз, когда вы расшифровываете, вы получаете еще один копия вашей зашифрованной строки. Это может создать избыток расшифрованных версий вашей защищенной строки, увеличивая шансы того, что какое-то вредоносное ПО, которое проверяет, скажем, номера кредитных карт ... действительно найдет их.
Я много раз пытался создать лучшую, более похожую на .NET версию .NET 2.0 SecureString, но так и не смог создать что-то действительно безопасное. Вы можете получить указатель на строковую переменную, которая была расшифрована, стереть ее, установить для каждого символа значение nil и т. Д. Однако это может быть очень проблематично, даже если что-то все еще ссылается на эту строку, вызывая исчезновение текста, поврежденное чтение и т. Д. Если строка интернирована, что обычно означает, что она используется многими вещами в течение длительного времени, ее очистка стирает единственную версию и влияет на все ее использование. Даже если вам удалось успешно стереть копию вашей защищенной строки, нет гарантии, что она не была скопирована другим кодом до того, как вы ее стерли (т.е. вы отправляете свою строку какой-то веб-службе ... теперь она живет в большем количестве чем одно технологическое пространство,
Here's one from SO:
Why does a bad password cause "Padding is invalid and cannot be removed"?
Вот отличное решение «все в одном» для ваших нужд.
Ссылка Txt: http://www.codeproject.com/Articles/36449/ String-Encryption-using-DPAPI-and-Extension-Methods.aspx
есть отдельная конструкция letrec . Алгоритм AES для симметричного шифрования обычно является подходящим для универсального шифрования. шифрование строк. Однако я боюсь, что .NET BCL не упростит для вас больше, предоставляя основные классы и функции шифрования / дешифрования.
Вы можете найти хороший пример того, как использовать крипографические классы специально для шифрования строк на этой странице . Он выглядит очень полным и действительно хорошо прокомментирован - вы даже можете обнаружить, что можете использовать его без каких-либо дополнительных изменений. Примечание. Rijndael - это тот же алгоритм, что и AES . (Технически первое относится к настоящему имени алгоритма, а второе - Advanced Encryption Standard .)