What is the best method for storing API token keys or other sensitive strings using Xojo.
I don’t think its best practice to just leave the token keys as plain text, should I use some encryption key methods?
Much thanks!
- don’t store them if you can get avoid it
- don’t put them in your code as plain text - obfuscate or encrypt them
- don’t store them all in one chunk - break it into pieces & put it all over the place
- at most put a public key in there - not a private key
What would be the easiest way to obfuscate/encrypt them?
Why not generate the key instead of just storing it?
@Alan Hewitt , the key is generated by the 3rd party developer API from for example “Twilio” or “Twitter” or whoever. I am going to need to enter the API key provided into my code somewhere to allow the communication with the 3rd party developer API service. I will not be the one generating them. Maybe I misunderstood your comment.
don’t put them in your code as plain text - obfuscate or encrypt them - see the built in Crypto module
don’t store them all in one chunk - break it into pieces & put it all over the place
@Norman Palardy let me review this crypto module… this will probably do the trick. Thanks
Sorry I meant create the API key (that you already know) programatically using some functions. IE:
MY API KEY = 9a0554259914a86fb9e7eb014e4e5d52
20 minus 11 = “9”
1st letter of alphabet = “a”
etc…
@Alan Hewitt I see what you mean, i guess this is an option, but still not totally secure since someone could review the algorithm used to build the key.
unless you’re giving the code away it’s not quite as easy as just reviewing the code 
combinations of the things suggested certainly raises the bar
If you’re on the Mac, you can use Apple’s Keychain to store them securely.
Keep in mind the threat vectors you are trying to protect against. Someone who can use a hex editor will be sufficiently protected against using these derivative and encoding schemes, as above. However, an attacker who can reverse engineer assembler code and do in memory debugging may have less of a hurdle.
One of the big questions to ask yourself when considering security controls is, how much time and energy is the attacker going to be willing to throw at the problem? What is the time/risk versus reward curve like?
If you are trying to guard against casual piracy or abuse of the api key, your controls are likely to be enough at the basic levels, especially if the api key is fairly cheap to get without hacking. On the other hand, if this is highly expensive/highly critical enterprise software of if it moves critical data with high levels of sensitivity, then you might want to up your game to the higher levels of protection.
There is no 100% security. No matter what you create, a sufficiently motivated and skilled attacker will still get what they want. The real rational balance is in finding just enough protection to make it costly enough or limit the attacker populace enough to provide the modicum of security you desire.
Hope that helps frame the security pro thought process for you.