You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardexpand all lines: README.md
+5-5
Original file line number
Diff line number
Diff line change
@@ -139,21 +139,21 @@ Usage: arkana [options]
139
139
> [!NOTE]
140
140
> For the completeset of args, look at the [options](#options) section.
141
141
142
-
### Config File
142
+
## Config File
143
143
144
144
The `arkana.yml` would typically contain 3 important sections:
145
145
146
146
- **Environments**: This is typically where you specify `debug`, `release` or other environments which you wish to create.
147
147
- **Environment Secrets**: This is where you declare the keys which will be ultimately exposed to your app, like `apiKey`.
148
148
- **Global Secrets**: Here you'd declare keys which are the same across all environments.
149
149
150
-
### Environment File
150
+
## Environment File
151
151
152
152
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.
153
153
154
154
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.
155
155
156
-
#### Sample
156
+
### Sample
157
157
158
158
A config file as shown below:
159
159
@@ -420,9 +420,9 @@ This encoding mechanism makes it difficult for attackers to simply just read you
420
420
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).
421
421
422
422
> 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.
423
-
423
+
>
424
424
> 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.
425
-
425
+
>
426
426
> 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.
427
427
428
428
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.
0 commit comments