Почему не DriverManager.getConnection (Строковый URL, Строковый пользователь, символ [] пароль)?

Строковые литералы объединяются в пул, но я не ожидал, что пароль будет быть буквальным (жестко запрограммированным в программе). Я ожидал, что это произойдет от конфигурации или подобного. Таким образом, он не будет буквальным, и будет собирать мусор (при условии, что все ссылки помещены в корзину).

Аргумент использования массивов char [] наиболее применим, когда пользователь вводит пароль, и вы хотите минимизировать раскрытие этого пароля.

Соединения JDBC почти никогда не бывают такими. Пароль хранится в каком-то конфигурационном файле, возможно, в зашифрованном виде, и является гораздо более серьезным источником утечки, чем возможность чтения памяти.

В любом случае стандарт JDBC позволяет передавать пароли в объектах свойств и даже в URL-адресе, поэтому я думаю, что наличие параметра пароля char [] даст вам ложное ощущение безопасности.

Если у вас есть реальный вариант использования, когда пароль необходимо удалить из памяти как можно быстрее, чтобы его невозможно было восстановить, и это имеет смысл в противном случае в контексте реального приложения JDBC, я хотел бы это услышать. Я могу представить, что такое может существовать, но я не могу представить себе сценарий, в котором использование char [] действительно делает вещи более безопасными.

Ваша причина №2 - это та, которую я видел чаще всего для использования char [] вместо String. Однако в целом я думаю, что если вы предполагаете, что кто-то имеет доступ к состоянию вашей программы через отладчик или другие средства, нет причин, по которым он также не может просматривать содержимое char [].

Можно только догадываться, если вы не можете спросить разработчика API.

Я предполагаю следующее:

Основной API, который использует char [] вместо String для паролей, о которых я знаю, это JPasswordField . Это делается для того, чтобы программа могла перезаписать введенный пользователем пароль другими значениями после того, как значения были использованы (что невозможно с String , которая будет оставаться в памяти по крайней мере , пока он не будет собран сборщиком мусора).

Пароль, используемый для подключения к базе данных, обычно не вводится пользователем в большинстве известных мне приложений, а берется из какой-то конфигурации / directory / ...

Неважно, откуда он берется: приложение может чтобы восстановить его, когда он больше не известен. В этом большая разница между паролями, вводимыми пользователем, и паролями, полученными программным путем.

Поскольку пароль обычно можно получить более легкими способами, чем поиск во всей памяти, используемой программой, исправление этого вектора атаки не является высоким приоритетом.

Файловая система является отличным примером того, как TDD может привести вас к лучшему и более гибкому дизайну. Часто при взаимодействии с файловой системой можно выполнять чтение и запись файлов с помощью Streams или TextWriters вместо фактических файлов.

Это все абстрактные типы, и так легко издеваться.

Теперь у вас есть более гибкий API, потому что он не тесно связан с файловой системой, но по-прежнему поддерживает операции с файлами.

Структуры предназначены исключительно для новых пользователей (вместе с out и ref).

Да, структуры могут обеспечить высокую производительность при использовании ref, но вы должны видеть, какую память они используют. Кто управляет памятью и т.д.

Если вы не используете ref и выходы со структурами, они не стоят того, если вы ожидаете некоторые неприятные ошибки: -)

Точка 1 действительна до некоторой степени, но пункт 2 о последовательностях, находящихся в неотбытом являетсяледовательностей, является истинной только для строк статического литерала (последовательностей, которые появляются непосредственно в коде). Если у вас есть пароли, хранящиеся непосредственно в вашем коде, я бы порекомендовал сначала побеспокоиться об этих паролях, поскольку их гораздо проще найти в классах, а затем в работающей виртуальной машине.

Поэтому, если вы считаете, что должны хранить свои пароли в символе [], вы все равно можете создать из него строковый объект, прежде чем вызывать getConnection (). Если реализация драйвера не хранит строковый объект внутри, он будет быстро недоступен и, таким образом, будет собран довольно быстро. Единственный шанс прочитать его в то время - изучить память JVM непосредственно там, где он все еще может существовать. Таким образом, вы правы, что использование char [] будет немного более безопасным, но не так много, как пароль должен быть в памяти в какой-то момент в любом случае.

Т.е. очень простым способом захвата пароля с помощью любого типа API было бы введение фальшивого драйвера SQL и захват пароля непосредственно в методе подключения. Тот, кто сможет исследовать память JVM, чтобы найти еще не перезаписанную последовательность пароля в ней, также сможет ввести измененную банку драйвера.