Какие есть альтернативы хранению пароля в коде?

Question

[Bogdan]

В своих программах приходится хранить пароли и ключи в коде для подключения к серверу или шифровки/расшифровки данных в ROM. Наткнувшись на статью о том как это опасно я задался вопросом: какие есть альтернативы? Если в контексте микроконтроллеров иногда есть аппаратные фичи, то как быть например на линуксе или андроиде?

Comments

[shurshur]

Зачем хранить пароль в коде? В статье какой-то лютый пример приведён из серии "как не надо делать вообще никогда". В качестве самого минимального варианта пароль по меньшей мере выносится в конфиг, который в кодовую базу не входит и прикладывается к приложению только при выкатывании в прод (речь, конечно, о сетевых приложениях на своём сервере). А дальше можно делать разные другие усложняющие вещи: передавать пароль при запуске приложения через переменные окружения или даже прямым запросом с консоли, использовать разного рода шифрованные key store с мастер-паролем. который также передавать через окружение или ещё каким-то небанальным способом... Очень много зависит от уровня рисков и от предполагаемых угроз. От чего защищаемся-то?

[Bogdan]

shurshur,
Если я правильно понял, вы говорите о том когда программа крутиться на своем сервере. Меня волнует несколько иная ситуация, когда моя программа находиться на ПК/смартфоне пользователя или на отдельной продаваемой железке. И любой может дизассемблировать программу, найти пароли и ключи используемые для работы с MQTT брокером. Изучить протокол и устроить хаос рандомным пользователям после этого не составит труда.

[Александр Ананьев]

Bogdan, храние пароли в коде программы в зашифрованном виде и расшифровывайте непосредственно перед использовпнием. Это затруднит хакеру возможность взлома программы, но на 100% не исключит ее.

[Владимир]

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

[shurshur]

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

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

В своей железке тут уже предлагали железные решения. Можно и не в своей железке, есть разного рода железные токены, генераторы одноразовых паролей итд итп.

И в целом есть много других вариантов. Но, как я уже говорил, всегда надо начинать с модели угроз. Будет ли кто-то вообще заморачиваться, или это на самом деле никому нафиг не нужно?

Answer 1

[12rbah]

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

Answer 2

[Армянское Радио]

Зависит от контроллера. Большинство микросхем поддерживает Lock-Bit - после чего программатором прошивку считать практически невозможно (или очень сложно).