Skip to content

Commit f426bcf

Browse files
authored
#67 Lint README
2 parents c567a3c + 6368782 commit f426bcf

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

README.md

+5-5
Original file line numberDiff line numberDiff line change
@@ -139,21 +139,21 @@ Usage: arkana [options]
139139
> [!NOTE]
140140
> For the complete set of args, look at the [options](#options) section.
141141
142-
### Config File
142+
## Config File
143143
144144
The `arkana.yml` would typically contain 3 important sections:
145145
146146
- **Environments**: This is typically where you specify `debug`, `release` or other environments which you wish to create.
147147
- **Environment Secrets**: This is where you declare the keys which will be ultimately exposed to your app, like `apiKey`.
148148
- **Global Secrets**: Here you'd declare keys which are the same across all environments.
149149
150-
### Environment File
150+
## Environment File
151151
152152
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.
153153
154154
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.
155155
156-
#### Sample
156+
### Sample
157157
158158
A config file as shown below:
159159
@@ -420,9 +420,9 @@ This encoding mechanism makes it difficult for attackers to simply just read you
420420
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).
421421
422422
> 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+
>
424424
> 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+
>
426426
> 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.
427427
428428
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

Comments
 (0)