Bachelor's and Master's in CS from MIT. Previously, worked @ Microsoft & Zynga. Currently Co-Founder of Moesif (moesif.com), the most advanced API analytics platform.
Never put your api keys in repos. period. (public or private).
Put them in environment variables but keep them completely separate from the source code repo. like development.env, production.env.
Always follow the practice of least privilege. Even most engineers at a company should only need development.env variables if they are just writing code and not doing production support.
production.env should be guarded with only very few people that must have access to production system.
I do not think that this is a good idea. You would put encrypted keys and the decryption algorithm in the repo. It is still possible to get to the keys.
First of all: The named function hash_hmac does not encrypt. It creates a hash, which cannot be used to restore the original value. It is one way.
If you would use a proper encryption the logic is still faulty.
You have a secret, that cannot be added plainly to the repository. You add some decryption logic, encrypt the original secret and add it to the repository. The original secret is now safe. But now you have another secret (the private key needed for decryption) that cannot be added plainly to the repository.
You still have the same situation plus some extra decryption code, which has to be maintained. Also your build process has to handle the encryption.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
few more ideas:
Never put your api keys in repos. period. (public or private).
Put them in environment variables but keep them completely separate from the source code repo. like development.env, production.env.
Always follow the practice of least privilege. Even most engineers at a company should only need
development.env variables if they are just writing code and not doing production support.
production.env should be guarded with only very few people that must have access to production system.
I had the impression KMS is the way to go here.
Put the encrypted keys in the repo and decrypt them before usage.
I do not think that this is a good idea. You would put encrypted keys and the decryption algorithm in the repo. It is still possible to get to the keys.
First of all: The named function hash_hmac does not encrypt. It creates a hash, which cannot be used to restore the original value. It is one way.
If you would use a proper encryption the logic is still faulty.
You have a secret, that cannot be added plainly to the repository. You add some decryption logic, encrypt the original secret and add it to the repository. The original secret is now safe. But now you have another secret (the private key needed for decryption) that cannot be added plainly to the repository.
You still have the same situation plus some extra decryption code, which has to be maintained. Also your build process has to handle the encryption.