Сохранение паролей в приложении

Это зависит от того, что вы собираетесь делать с информацией.

Если вы собираетесь использовать имя и пароль для доступа к какой-либо внешней службе (но пользователю придется повторно ввести информации при следующем запуске программы), то их можно сохранить в некоторых переменных. Было бы разумно хранить их в зашифрованном виде (по крайней мере, хранить зашифрованный пароль), чтобы он не был виден в дампах ядра или аналогичных. Когда требуется пароль, вы его расшифровываете, используете и затем записываете, где хранилась расшифрованная версия (удаляя ее). (Примечание: хеширование не подходит в этом контексте; вы должны иметь возможность видеть пароль, и вы не можете отменить хеш). Вы можете решить сохранить информацию вне программы (в файле на диске), но это не кажется необходимым. Обратите внимание, что двоичный файл по-прежнему будет содержать ключ шифрования (и алгоритм шифрования), а зашифрованные данные более случайны, чем среднее содержимое вашей программы, поэтому действительно скрыть зашифрованный пароль на самом деле очень сложно (почти невозможно). Однако вы можете сделать его достаточно сложным, чтобы остановить всех, кроме самых решительных злоумышленников.

Если вы собираетесь сохранить имя пользователя и пароль в качестве постоянной записи, чтобы вы могли проверить, что тот же пользователь имеет доступ к информации в будущее, то вы должны использовать внешнее хранилище программы; вы будете использовать простую базу данных, которая может быть такой же простой, как обычный текстовый файл, если вы убедитесь, что вы решите любые проблемы параллелизма. В этом случае вы будете хешировать пароль с некоторой солью, и вы сохраните имя пользователя, соль и хешированный пароль таким образом, чтобы с учетом имени пользователя, вы можете легко найти два других значения.

Комментарий Night Walker:

Я использую этот пароль для доступа к некоторой веб-базе данных, поэтому мне нужно, чтобы он сохранялся в моем приложении после того, как он вводится в первый раз. Вы уверены, что простой текстовый файл - это такая умная идея?

Это зависит от того, как вы понимаете «хранится в моем приложении». Вы не можете изменить исполняемый файл или, по крайней мере, не должны пытаться это сделать. Итак, вам нужно рассматривать это как постоянную запись, хранящуюся в каком-то файле, отдельном от исполняемого файла приложения. С другой стороны, вы действительно сталкиваетесь с проблемой, отличной от той, которую я описал, - вы не аутентифицируете пользователя с помощью информации; вам необходимо расшифровать информацию по запросу для отправки в другие приложения.

Во-первых, это означает, что соли и хэши не актуальны; вам нужно отменить операцию маскирования, и вы не можете отменить хэш.

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

Если пользователь должен ввести какой-то пароль в ваше приложение, чтобы начать работу, тогда вы можете рассмотреть возможность использования этого пароля (или его хэша, отличного от хэша пароля, используемого для распознавания пароля к приложению) для шифрования комбинации имени пользователя и пароля для внешнего приложения. Затем вы можете сохранить имя пользователя и, в качестве аргумента, версию зашифрованного пароля в кодировке Base-64 в текстовый файл; это так же безопасно, как и пароль приложения, который хранится в исходном соленом хеш-формате. Когда пользователь возвращается, они должны предоставить свое имя пользователя и пароль приложения, и вы можете проверить эту комбинацию по сохраненным значениям, а затем использовать пароль для расшифровки пароля к внешнему приложению.

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

mkdir ~/.appname
chmod 700 ~/.appname
cp /dev/null ~/.appname/app.key
...store the encrypted information...
chmod 500 ~/.appname
chmod 400 ~/.appname/app.key

Это менее удовлетворительно, потому что даже если вы объедините фиксированный ключ с именем пользователя, скажем, есть вероятность, что кто-то сможет выяснить, что это за ключ (и технология шифрования), и перепроектировать его. (Секретность зашифрованных данных зависит от ключей; когда ключ определяется программой, он также может быть определен злоумышленником. Безусловно, лучше всего полагаться на то, что пользователь предоставит ключ (или пароль, или парольную фразу) во время выполнения; тогда приложение не хранит ничего, что злоумышленник может использовать в автономном режиме.