Как хранить закрытый ключ или защищенную информацию / данные с помощью Electron

Я занимаюсь разработкой автономного приложения для кроссплатформенности с использованием электронов.

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

Или же

Я хочу хранить в приложении некоторую защищенную информацию, такую ​​как пароль пользователя, конфиденциальные данные

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

Источник

4 ответа

Решение

Для редактора Atom создан модуль NPM (для которого было создано приложение Electron), который называется Keytar. Он использует собственные API OS для безопасного хранения. например. Брелок на OS X.

https://github.com/atom/node-keytar

Источник

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

Во-первых, два больших замечания:

  1. Даже с некоторыми тяжелыми специализированными аппаратными средствами (банки и другие критически важные системы используют для этого аппаратные модули безопасности -HSM), всегда существует риск кражи вашего ключа. То, что вы выберете, зависит от того, насколько важен ваш ключ и насколько вы готовы его защитить. Я постараюсь не упоминать о решениях, связанных с аппаратным обеспечением, потому что они, как правило, излишни для большинства людей.
  2. Однако есть полезные практики, которым вы можете следовать: https://www.owasp.org/index.php/Cryptographic_Storage_Cheat_Sheet

Теперь некоторые советуют. Что бы вы ни делали, не храните ваш ключ в незашифрованном виде (и гораздо менее жестко). Если вы используете криптографию с открытым ключом, файлы PKCS12 (обычно с расширением.p12 или.pfx) являются стандартным способом хранения данных. Они обычно защищены паролем.

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

Однако если действия автоматизированы, вам нужно найти способ сохранить пароль. Даже программы для обеспечения безопасности, такие как некоторые реализации PGP, имеют подходы для этого, что не очень приятно:

  1. Запросите пароль в командной строке: command -password my-password. Это, положить в летучую мышь, работает. Но пароль сохраняется и, в зависимости от операционной системы, даже доступен с помощью команды history,
  2. Сохраните его в файле: по крайней мере, вы не оставляете копии вокруг, но пароль остается открытым текстом.
  3. Зашифруйте его, используя системные данные в качестве ключа шифрования: пароль относительно защищен, но вы теряете переносимость, и злоумышленник, имеющий доступ к компьютеру, не будет остановлен системой управления.
  4. Спросите пароль, как только одна служба включена: немного более разумно, но не всегда возможно (если служба критична, но пароль имеет только один человек, доступность может быть скомпрометирована).
  5. Причудливые вещи можно сделать с помощью расшифровки порога, но это, вероятно, слишком много для этого случая.

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

Источник

Избегайте хранения личных или серверных данных, таких как закрытый ключ, в электронном приложении. Доступ к данным и файлу приложения Electron можно получить изapp.asarфайл и электрон не защищают содержимое вообще. В электронике такого механизма защиты кода нет. ОднакоNW.jsподдерживает защиту исходного кода, вы можете прочитать это здесь. Поэтому, по моему мнению, хранить частные аккредитации, такие как подписание сертификата или закрытого ключа, в электронном исходном коде небезопасно.

В качестве другого способа вы можете хранить эти данные с помощью node-keytar в цепочке для ключей для Mac, диспетчере учетных данных в Windows и Gnom Keyring в Linux с использованием собственного API. Но все же эти учетные данные доступны для пользователя и не имеют смысла для хранения частных токенов (например, токен для частного репозитория GitHub с правами администратора). Это зависит от пользователя. Если он / она достаточно опытны, чтобы понять, что вы сохранили в Связке ключей, Диспетчере учетных данных или Связке ключей, они могут использовать это неправильно или использовать против вас. Итак, окончательный ответ:

Не храните учетные данные / закрытый ключ или административные токены в электронном источнике или с помощью node-keytar.

Источник

идеальный способ хранения данных в электронном виде - это пакет: https://www.npmjs.com/package/electron-data-holder

этот пакет хранит данные в файле JSON, но дает вам возможность зашифровать данные.

подробнее в документации

Источник
Другие вопросы по тегам