[
https://issues.apache.org/jira/browse/OFBIZ-9833?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16241590#comment-16241590
]
Jacques Le Roux commented on OFBIZ-9833:
----------------------------------------
Something I want to note here, and will maybe create a Wiki page for, is about
the security strategy suggested for storing the
ExternalServerJwtMasterSecretKey in ExternalLoginKeysManager class.
The question is simple: what is the best place to store a secret key? Of course
there are several answers to this question and you might prefer your own, but
be sure that it's as safe as you imagine.
Here is a good summary about this question:
https://security.stackexchange.com/questions/12332/where-to-store-a-key-for-encryption
Traditionnaly in OFBiz we use properties files. There is at least 2 examples
OOTB: janrain.apiKey and login.secret_key_string.
So this seemed the most appropriate to me when I first thought about it. But
then because here it's about getting access to another server I began to be
more cautious. What happens if someone get a read access to the server and can
read the content of this properties file? Then this person might get access to
the other server, and the purpose of the JWT token is completly lost!
The problem with a properties file is you need to keep it on the server to be
able to read it when needed, I already commented about that above.
You might be tempted to store the secret key in the Database. When it's only
about a server it's IMO far from the best solution
* see point 7 in link above
*
https://stackoverflow.com/questions/13991100/where-do-you-store-your-secret-key-in-a-java-web-application.
But when, like here, the functionnality allows access to another server then if
the Database on the source server is compromised this possibly grants access to
the other server for an attacker. Since the funcionnality allows access from
one server to another, by transitivity this potentially allows access to more
than 1 target server.
For me the best simple solution is a file that you remove from the production
server. Nicolas suggested, a file where the secret key is modified by sed using
uuidgen on each build, and I agreed. But we missed something: the
ExternalServerJwtMasterSecretKey must be the same on both servers (and etc.).
So using uuidgen during build on each machine is innapropriate. Nevertheless
the uuidgen solution is still interesting because it increase the difficulty
for an attacker to know the ExternalServerJwtMasterSecretKey, but you could use
a fixed ExternalServerJwtMasterSecretKey as well.
A solution is to generate a uuid using uuidgen somewhere safe, or use a fixed
ExternalServerJwtMasterSecretKey, and copy it using sed on the production
servers. Since it's preferable to have the same deployment script on each
production server I suggest to generate the uuid on a devlopment machine, or
use a fixed ExternalServerJwtMasterSecretKey, and pass it to the deployment
script. I recommend to not use an environment variable to pass the uuid as
those can be considered weak:
* http://movingfast.io/articles/environment-variables-considered-harmful/
*
https://security.stackexchange.com/questions/49725/is-it-really-secure-to-store-api-keys-in-environment-variables
Several means can be used to pass the ExternalServerJwtMasterSecretKey to the
deployment script, among them
* copy it from the deployment machine using a temporary connection, possibly
from an USB key removed after from the deployment machine to guarantee a total
confidentiallity!
* from an USB key removed after from the production servers to guarantee a
total confidentiallity (harder with cloud solutions)
* manually by the OPS somehow (again avoid an environment variable)
* etc.
> Token Based Authentication
> --------------------------
>
> Key: OFBIZ-9833
> URL: https://issues.apache.org/jira/browse/OFBIZ-9833
> Project: OFBiz
> Issue Type: New Feature
> Reporter: Deepak Dixit
> Assignee: Deepak Dixit
> Attachments: JSON Web Tokens.pdf,
> OFBIZ-9833-external-server-test-example.patch,
> OFBIZ-9833-external-server.patch, OFBIZ-9833-external-server.patch,
> OFBIZ-9833-external-server.patch, Token Based Authentication in Apache
> OfBiz.pdf, Token Based Authentication.pdf, rfc7519.pdf
>
>
> Here is dev list discussion for token based authentication work:
> http://markmail.org/message/vyskeh2wujqpkbwg
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
