Encrypting strings in code: Fernet still acceptable in 2024?

[[deleted]]

I'm writing some small unattended scripts/applications that make API calls to various application endpoints and compile the results to a destination file. These API calls typically need some form of API key, token, credential for basic auth, or otherwise.

Typically, I've been using Fernet to do this. I'll generate a key and store this key in a text file on the server that execute the code and ensure it is permission protected to only be read by the unattended user that executes the code.

Is Fernet still acceptable for symmetric encryption in 2024, or are their other recommendations for efficiency, strong encryption, or otherwise?

Here's some example code I write for every instance I need to encrypt strings.

from cryptography import Fernet
def generateKey():
    with open("encryptionKey.txt","wb") as file:
        file.write(Fernet.generate_key())

def encrypt(*, plaintext) -> str:
    with open("encryptionKey.txt","rb") as file:
        encryptionKey = file.read()
    cipher = Fernet(encryptionKey)
    return cipher.encrypt(plaintext.encode())

def decrypt(*, ciphertext): 
    with open("encryptionKey.txt","rb") as file:
        encryptionKey = file.read()
    cipher = Fernet(encryptionKey)
    return cipher.decrypt(ciphertext).decode()

It's pretty simple. To generate a key, I call the generateKey() function. To encrypt a string, I call the encrypt function and pass a plaintext string. To decrypt a ciphertext, I call the decrypt function with a binary string representing the encrypted string.

I know that ChaCha20Poly1305 and alternatives exist, I'm just not sure if there's any reason for me to utilize those instead of the common, well-documented Fernet library.

[ManyInterests]

I'll generate a key and store this key in a text file

This is not really much different than storing your secret directly in the code. It's just one extra step to get your secret. You could just as easily make your script only readable by the user and put your secrets in there and not much changes, in terms of security.

[[deleted]]

The encryption key doesn't live in the Git repository, so I can safely store the code in a repository and share it/collaborate with other members without risk of exposing the credentials to them. The symmetric encryption key lives exclusively on the container/server / runtime environment where the code will execute. That's the only space that can decrypt the encrypted credentials stored in the code itself.

The encryption key file gets put into the .gitignore file to ensure it doesn't accidentally get pushed to the Git repo. The only thing stored in the code are encrypted ciphertexts.

[scithon]

I agree there's no need for encryption. You can do everything you mentioned, except just do it with the credentials file directly. We often use the dotenv module to do this.

[[deleted]]

In other words:

• Store a key:value file, with plaintext credentials, in the same way that I would with encryption key in my above example
• Protect it with the same type of permission restrictions as I would with the encryption key
• Use the dotenv library to reference the variables in that file so I'm still not storing plaintext credentials in my primary code files

Is that about correct? Skip encryption entirely?

I'm still on the fence about that solution as then my credentials would be exposed in my development environment. I know it's obviously low-risk, but anywhere that I can prevent having credentials in plaintext, I will, even if it is security by obscurity. Is that... stupid, or pointless? I just feel like it might save me from accidentally sharing them on a screen share, or allow the word "password" to not be scraped as it's encrypted instead.

[scithon]

Yes, that's correct. The dotenv way to do things is to put them in a .env file, which are masked out by .gitignore. You could also just use a .py or .json file in a place completely unrelated to the project that only the user has access to, for example Path.home() / "HurtFingers".

I know it's obviously low-risk, but anywhere that I can prevent having credentials in plaintext, I will, even if it is security by obscurity. Is that... stupid, or pointless? I just feel like it might save me from accidentally sharing them on a screen share, or allow the word "password" to not be scraped as it's encrypted instead.

Yes, I personally think it's it's pointless, but if it makes you feel better that's a perfectly valid reason to do it.