From b1a619bcec61b9148c3918ff824d7aedecd28bf7 Mon Sep 17 00:00:00 2001 From: Roger Oba Date: Thu, 13 Jun 2024 02:29:43 -0300 Subject: [PATCH 1/2] Fix heading level. --- README.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index 9f63bd8..85e4505 100644 --- a/README.md +++ b/README.md @@ -139,7 +139,7 @@ Usage: arkana [options] > [!NOTE] > For the complete set of args, look at the [options](#options) section. -### Config File +## Config File The `arkana.yml` would typically contain 3 important sections: @@ -147,13 +147,13 @@ The `arkana.yml` would typically contain 3 important sections: - **Environment Secrets**: This is where you declare the keys which will be ultimately exposed to your app, like `apiKey`. - **Global Secrets**: Here you'd declare keys which are the same across all environments. -### Environment File +## Environment File The environment (`.env`) file contains the actual secrets for each environment. While config file declares the keys, they are assigned encrypted values from this file. This file is optional, but quite handy in local development. `.env` files shouldn't be committed as they contain your secrets. Instead, they should be stored in a secure location, like your CI/CD server as environment variables (all CI/CD servers have a way to store secrets securely). See [Continuous Integration](#continuous-integration) for more information. -#### Sample +### Sample A config file as shown below: From 63687826b1d66b0e6fb449737a0013de1b5bd573 Mon Sep 17 00:00:00 2001 From: Roger Oba Date: Thu, 13 Jun 2024 02:29:50 -0300 Subject: [PATCH 2/2] Add missing quote marks. --- README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 85e4505..06e8239 100644 --- a/README.md +++ b/README.md @@ -420,9 +420,9 @@ This encoding mechanism makes it difficult for attackers to simply just read you Key security is difficult. Right now even the biggest apps get their keys [leaked](https://threatpost.com/twitter-oauth-api-keys-leaked-030713/77597). This is neatly summed up by John Adams of the Twitter Security Team on [Quora](http://www.quora.com/Twitter-1/How-were-the-Twitter-iPhone-and-Android-OAuth-keys-leaked). > Putting this in the context of, "should you be storing keys in software", is more appropriate. Many companies do this. It's never a good idea. - +> > When developers do that, other developers can use debuggers and string searching commands to extract those keys from the running application. There are numerous talks on how to do that, but leave that as an exercise to the reader to find those talks. - +> > Many people believe that obfuscating these keys in code will help. It usually won't because you can just run a debugger and find the fully functional keys. So in summary, the ideal way to store keys is to not store keys. In reality though most Apps embed keys, and this does that and adds some rudimentary obfuscation to the keys. A well motivated app cracker could probably extract this within a few minutes however.