Скрытие паролей / ключей в скомпилированном приложении

Question

В моем приложении C у меня есть ключ дешифрования, который используется для дешифрования наборов в базе данных (имя пользователя / пароль).В настоящее время я просто объявил это с помощью

char * key = "$$$secretSampleDecryptionKey$$$";

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

РЕДАКТИРОВАТЬ:

Как отмечали Марк и Аарон, я могу просто использовать команду строк Linux / Unix

strings nameOfApplication

распечатать все строки в моем приложении, включая «секретный» ключ.

РЕДАКТИРОВАТЬ 2:

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

Answer 1

Интересная ссылка, рассказывающая о том, как кто-то извлекал пароль из двоичного файла:

Деконструкция файла ELF

Это пошаговое описание того, что кто-то может попытаться найти пароль. Это даст вам представление о том, что «не делать». Использование команды strings является первым элементом в списке, например.

Если вы хотите скрыть вашу секретную строку от strings, вы можете сохранить ее как массив символов, не заканчивающийся символом \0. strings не должен поднимать его.

Также упоминается хороший трюк (который обойден), чтобы никто не использовал strace / ltrace для вашего двоичного файла.

В конечном счете, после разборки кода «хакеру» удается восстановить пароль, от которого, как указали другие, трудно защититься. По сути, вы ничего не можете спрятать в двоичном виде ...

Answer 2

Если ключ находится в вашем источнике, то злоумышленник сможет найти его. Лучшее, что вы можете сделать, - это усложнить им задачу.

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

Храните ключ как минимум в двух случайно выглядящих двоичных массивах, которые объединены в XOR для создания фактического ключа. В качестве альтернативы, выберите одну из стандартных текстовых строк, которая в любом случае присутствует в вашем приложении, что-то вроде: «Пожалуйста, введите почтовый индекс:», и используйте это в качестве ключа или в качестве одного из компонентов XOR. Хэширование такого сообщения получило бы его стандартную длину, если это необходимо.

Answer 3

Кто-нибудь может это увидеть?

Команда strings покажет строку, не нужно разбирать приложение.

Разборка просто сделает ее прощечтобы определить, какая из 15 000 строк используется как key.

Что я могу сделать, чтобы скрыть это от них?

Существует только одно решение:Не вставляйте его в код.

Вместо этого используйте лицензионный ключ или аналогичный метод, когда пользователь знает ключ.

Answer 4

Интересно, кто-нибудь может дать нам реальный ответ, чтобы решить эту проблему? По своему опыту веб-разработчика я могу сказать, что то, что вы даете клиенту, больше не принадлежит вам для контроля. Рассмотрим веб-сайт, использующий некоторый алгоритм шифрования на стороне сервера и жестко закодированную технику javascript на клиенте, и сам webdev, руководствуясь своей собственной тщеславием, не хочет показывать его миру, но все еще будет использоваться клиентами, как есть.

В таком случае, что он может сделать? Да, да, он может прийти к идее поместить свой сценарий в бесконечный цикл на основе setTimeout, все как анонимную функцию, поэтому его нельзя отследить, но все же инициализация должна быть где-то выполнена, код должен быть visibile, более того, он решает отправить код после загрузки в зашифрованном виде, но, тем не менее, на клиенте вам все равно нужно будет иметь ключ дешифрования, поэтому у кого-то, кто хочет получить информацию, по-прежнему будут две необходимые части этой головоломки , Но наш программист настойчиво, поэтому он создает функцию расшифровки каждый раз, чтобы соответствовать только одной зашифрованной строке, но все равно это не приносит ему пользы. Так как клиент все равно будет иметь строку и соответствующую функцию.

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

.

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

РЕДАКТ. 1: Вы можете создать интересный эффект домино в своем коде, пропуская биты ключа шифрования в зависимости от исполнения, так как при необходимости он у вас будет полностью, но он не будет сохранен в файле или в строке вашего скомпилированного файла, поэтому может быть найден только во время выполнения, и он может быть найден только в определенных условиях, и, более того, для его получения может потребоваться некоторое обратное проектирование. Может быть хорошим решением.

С большим уважением, Пол

Answer 5

Используя отладчик / дизассемблер, пользователь всегда сможет узнать пароль.Вы можете сделать это сложнее (например, использовать обфускацию ), но не невозможно.

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

В вашем сценарии, связанном с именами пользователей и паролями, вы можете просто сохранить хэш пароля в базе данных (см. связанные ответы в Лучший способ сохранить пароль в базе данных )