Storing sensitive information/credentials

Help
1

Godot Version 4.3

Hello everyone! I have a question regarding the best way to store and use the external API key in a Godot project. I plan to open-source the project, so embedding the key directly in the code is not an option. However, I still need the key to be included in the exported executable. I’ve been reading about this topic but couldn’t find a good solution. Any help will be greatly appreciated!

2

have you read about Crypto class?
image
and methods like var_to_bytes_with_objects()?
and PackedByteArray?

3

I don’t see how the Crypto functionality will help me. :frowning:

I have the following code in a gdscript:

SilentWolf.configure({"api_key": "[API-KEY]": "[GAME-ID]", "log_level": 0})

API-KEY and GAME-ID are sensitive data and I can’t commit them to the repository as I want to make it public at some point. So I would have to store their values somewhere outside of the repository and load it runtime when I am developing and (this is for me the tricky part) when I am exporting the game to executable the values should be included. They can be encrypted, sure, but it is optional.

4

You do realize, that if you put sensitive data into the exported executable, then people can reverse engineer that executable and extract these values?

See for example: GitHub - bruvzg/gdsdecomp: Godot reverse engineering tools

1 Like
5

well I mixing bytes or symbols to generated value to make it ‘broken’
this code for inspiration:

	var api_key:='QWERTYIOP'
	var bytes:=var_to_bytes(api_key)
	#encode your key there
	
	#encoded
	bytes=bytes.compress(1)
	Marshalls.raw_to_base64(bytes)
	#send it to where it should be sent
	#or add extra symbols to string of remove some
6

This is obfuscation. I solution for another problem.

Anyway, I did some code search in Github and found a couple of way people have been dealing with this issue.

  1. Loading a script/resource/config file, but not committing it in the repository - examples 1, 2 and some useful documentation
  2. Using project settings - example 1 and again useful documentation

Hope someone find this useful.

1 Like
7

But the problem that Sauermann said still stays, what is stopping someone from reverse engineering the executable itself as for 1 you are including it in the file that is being given with the same story happening for 2.

I think a better way to do it would be to just not store it on the client at all and just use a server that is sent packets to do a specific task. (no one can get the actual code ran on the server except for the providers) If you really want to also open source the server code you can either just not include it or use an os variable.

1 Like
8

I agree. I am just asking about a different problem.

Reverse engineering is battled with obfuscation, encryption, client deprivation of secrets :slight_smile: Agreed!

1 Like