[feat] string obfuscation support

[michaelhenry]

Ability to obfuscate env values

[JackoPlane]

+1 This approach is ultimately pushing the problem further along. NSHipster has a great article on this, https://nshipster.com/secrets/#normal-brain-hard-code-secrets-in-source-code

[michaelhenry]

Thanks @JackoPlane. How are you?

Yup, I saw that article as well and it is really good one. I'm thinking of providing several algorithm options and whether keeping the string data type but with more secured encryption algorithm, so it will have less boilerplate/template. Or just using the same algorithm from nshipster but the downside is providing the boilerplate, because of the changes of data type from string to byte array, especially if using for other languages. What do you think?

[JackoPlane]

I'm doing well mate @michaelhenry

Ultimately, everything that you ship in a mobile app should be considered "public". Typically things like API keys aren't considered sensitive, It's trivial to capture these values using something like a MiTM proxy - Even with SSL pinning (See: (SSL Kill Switch)[https://github.com/NyaMisty/ssl-kill-switch3]).

Personally, my beliefs with obscuring things like API keys in mobile apps is to store them as binary and then convert to Strings (As described in the NSHipser article) at runtime. Doing so means that your raw string is no longer discovered via $ strings, Thus would require the attacker to have an understanding of ASM and reverse engineering Mach-O binaries. Ultimately these values will be obtainable to someone with the skillset and motivation todo so.

Unless you have a specific requirement, encoding the strings to binary and injecting that into your .swift file and using (App Attestation)[https://developer.apple.com/documentation/devicecheck/preparing_to_use_the_app_attest_service] will ensure the values you compile with are the same you use when you execute.

[michaelhenry]

@JackoPlane Yeah, that's true, and as NSHipster says, "Client Secrecy is Impossible". It's just a matter of effort and time.

And the other advantage of simply obscuring them as binary is it is much faster to decode compared to other algorithms that use thousands of iterations to perform the encryption and decryption, which is relatively slower.

For simplicity, I will use this approach by replacing the key with an anonymous function if the source is a swift code.

For example:

Source

enum Secrets {
  var apiKey = "$API_KEY"
}

Final form

enum Secrets {
  var apiKey = "\({ deobfuscate([0x1, 0x2, 0x3, 0x4, ..., 0x100], salt: salt) }())"
}

Required code

private var salt = "$SALT_KEY" // bytes and will be populated automatically by `envject`.

private func deobfuscate(_ bytes: [UInt8], salt: [UInt8]) -> String {
    return bytes.enumerated().reduce(into: "") {
        $0.append(Character(UnicodeScalar($1.element ^ salt[$1.offset % salt.count])))
    }
}

And if the code is swift, I think, I'm gonna automate this Required code (or at least provide an option) to be part of the process since they are private anyway, keeping a valid swift code/file.

What do you think?

[michaelhenry]