Information Security
GitHub
Comments 22
+4
Давайте зайдём с другой стороны: а что должно быть вместо реального токена, ключа и т.п.? — всё равно в тестах, описании, комментах будет тестовый, отозванный токен, либо его имитация вида ABCD-1234-EF56.
+3

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

+2
Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?
+4
Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.
+3
В нашем проекте они хранятся в приватном репозитории. В коде можно встретить такое:
#include "../../../miranda-private-keys/Dropbox/secret_key.h"

data.AppendFormat("&client_id=%s&client_secret=%s", DROPBOX_APP_KEY, DROPBOX_API_SECRET);

Соответственно, если кто-то посторонний хочет собирать сам, он должен создать у себя локально нужную структуру каталогов и положить токен в secret_key.h:
#define DROPBOX_API_SECRET «abcdefghijklm»
+1

Можно маунтить директорию с шифрованием. Ключи один раз положил потом просто маунт

0

Вопрос был про хранение до выноса в те же environment variables. Про обмен между членами команды.

0
Если приложение работает в Kubernetes, то можно использовать средства хранения ключей, предоставляемые платформой — Kubernetes Secrets. При этом в репозиториях ключи не хранятся от слова совсем, и один и тот же код, запускаясь в разных средах (dev, staging, prod — кто во что горазд), будет видеть разные ключи в специальном каталоге, видимом из их контейнера.

Если нужно всё по-серьёзному, с аудитом доступа к ключам, то можно использовать Google Cloud Key Management Service. Тогда собственно секреты хранятся на серверах клиентов (Google их даже не знает), но зашифрованными ключами, хранящимися в Google. Такое вот комбо.
0
Если open-source приложение устанавливается на компьютер или другое устройство клиента, то какой смысл держать API key в тайне?
+3
Если там ключ, который должен знать только клиент и больше никто, то странно было бы выкладывать этот ключ для всего остального мира.
+3
а 81% так и не были удалены в течении срока наблюдения
Что не обязательно свидетельствует о их уязвимости — отсутствие реакции может быть обусловлено тем что:
1) Ключ изначально был не рабочим (отозван, просто случайный набор букв для примера)
2) Рабочий ключ поменяли после сообщения, а старый просто оставили в репозитории.
3) Это ключ для демо-доступа, который и должен быть всем доступен
0
Меня удивляют люди, публикующие свой приватный ключ.

Недавно я объяснил то, что должно быть понятно без пояснений:
Полагаю, вам понятен смысл слов «приватный разговор» и «публичное заявление»: содержание приватного разговора не должно стать известно посторонним, содержание же публичного заявления должно стать известно широкому кругу людей. Разница между приватным ключом и публичным ключом такая же: приватный ключ следует спрятать и не показывать никому, а публичный ключ можно опубликовать (эти слова не случайно однокоренные).

Как можно не понимать столь самоочевидные вещи?!
+1
Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь
0
Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.
+1
Я как-то лично пытался донести до менеджмента одной, довольно крупной компании, что их code signing certificate с паролем (прямым текстом!) в подписывающим бинарники скрипте, не стоит не то, чтобы держать в public access repository, но даже и в private company repos (где любой сотрудник, даже контрактор на short term, имел к ним доступ). Не удалось…

P.S. Самое неприятное то, что их бинарники, подписанные этим сертификатом, работают практически на каждом Windows PC :(
0
Почему не называете компанию? Ни один человек не может знать всё, и даже знающий может ненамеренно ошибиться, но в описанной Вами ситуации имеет место воинствующее невежество.
0
Потому, что a) NDA b) возможно, они уже исправили ситуацию, не хочу клеветать (контракт закончился три года назад).
Only those users with full accounts are able to leave comments.  , please.