Как стать автором
Обновить

Комментарии 22

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

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

Всегда было интересно, а кто где хранит боевые ключи и токены до их подкладывания вручную? Есть какие-то общие решения или каждый изобретает свой велосипед?
Кажется, нам нужен токен-репозиторий. Нужно только решить, где хранить ключи от него.
В нашем проекте они хранятся в приватном репозитории. В коде можно встретить такое:
#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»

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

Мы обычно их Environment variable выносим.

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

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

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

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

Как можно не понимать столь самоочевидные вещи?!
Уверен вы иногда вслух произносите конфиденциальную информацию, подразумевая что рядом стоящие ничего не понимают о чём идёт речь
Меня удивляет то, что это удивляет других. Ведь теория всегда ясна и понятна. На то она и теория.
Но есть ещё практика. И там есть такая штука, которая называется «человеческий фактор», «человеческая ошибка» и банальное «забыл».
Уверен, что многие ключи вышли «в свет» именно по этой причине. Например, если бы этот автор в момент публикации увидел вопрос «are you sure you want to publish your private key?», то он с уверенностью ответил бы отказом.
НЛО прилетело и опубликовало эту надпись здесь
Почему не называете компанию? Ни один человек не может знать всё, и даже знающий может ненамеренно ошибиться, но в описанной Вами ситуации имеет место воинствующее невежество.
НЛО прилетело и опубликовало эту надпись здесь
Да, с NDA не поспоришь. Будем надеяться, что исправили (грустно, если нет).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории