Re:A Better Way to Manage the Rails Secret Token
by iguana on Monday May 20, 2013 @02:01AM
(#5736150)
Your environment is not secure. The solution for this type of problem (keeping secrets out of source control) is to create a deployment-specific configuration file that is not kept in source control. It can be created out of a generic version that is kept in source control. Then, OS-level permissions are applied so the file is only readable by the processes that need access.
[ Parent
| on HN ]
Re:A Better Way to Manage the Rails Secret Token
by danielfone on Monday May 20, 2013 @07:09AM
(#5736958)
It's worth noting that with 'dotenv' the configuration is stored in a file on the production server before it's loaded into the environment. The security of the method is not based on storing the token in the environment.
The primary advantage I intended was that the secret is confined to one part of the infrastructure (e.g. production server) instead of many (e.g. developer workstations, github, etc).
Re:A Better Way to Manage the Rails Secret Token
by duaneb on Monday May 20, 2013 @02:36AM
(#5736239)
How is the environment any less secure than memory? If someone can read or mutate your environment, you should assume your app is already compromised and OS-level permissions aren't going to do anything.
Certain weird-shit UNIX operating systems do not provide privacy for a process's environment. (eg. another user on the same box can see them with 'ps e'). More relevantly, POSIX does not require it. The same is not true of process memory.
Re:A Better Way to Manage the Rails Secret Token
by justincormack on Monday May 20, 2013 @04:36AM
(#5736585)
Most people probably set the environment for all processes not just on a need to know basis perhaps.