This is an automated email from the ASF dual-hosted git repository.

jleroux pushed a commit to branch release17.12
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git


The following commit(s) were added to refs/heads/release17.12 by this push:
     new b06521c  Fixed: fixes wrong wiki URLs
b06521c is described below

commit b06521c356de0be6fdfdc930f818a384d1efacd5
Author: Jacques Le Roux <[email protected]>
AuthorDate: Mon Feb 22 11:44:17 2021 +0100

    Fixed: fixes wrong wiki URLs
---
 .../security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc    | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git 
a/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc 
b/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc
index e1ebcf2..7ad1819 100644
--- a/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc
+++ b/framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc
@@ -33,8 +33,8 @@ endif::[]
 Demo and seed passwords are stored in files loaded through security 
ofbiz-component.xml. To know more about that be sure to read:
 
 
-* 
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+Production+Setup+Guidehttp://url[The
 technical production setup guide] notably "Initial Data Loading" and "Security 
Settings" sections
-* 
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+secure+your+deploymenthttp://url[How
 to secure your deployment]
+* 
https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+Production+Setup+Guide[The
 technical production setup guide] notably "Initial Data Loading" and "Security 
Settings" sections
+* 
https://cwiki.apache.org/confluence/display/OFBIZ/How+to+secure+your+deployment[How
 to secure your deployment]
 
 [CAUTION]
 These configuration steps are not to be neglected for the security of a 
*production environment*
@@ -66,7 +66,7 @@ You might prefer to use pair of public/private keys, for now 
by default OFBiz us
 * 
https://security.stackexchange.com/questions/49725/is-it-really-secure-to-store-api-keys-in-environment-variables
     
 . You may want to tie the encryption key to the logged in user. This is used 
by the password recreation feature. The JWT secret key is salted with a 
combination of the current logged in user and her/his password. This is a 
simple and effective safe way.
-. Use a https://tools.ietf.org/html/rfc7519#section-4.1.7[JTI] (JWT ID). A JTI 
prevents a JWT from being replayed. This 
https://auth0.com/blog/blacklist-json-web-token-api-keys/http://url[auth0 blog 
article get deeper in that].  The same is kinda achieved with the password 
recreation feature. When the user log in after the new password creation, the 
password has already been  changed. So the link (in the sent email) containing 
the JWT for the creation of the new password can't be reused.
+. Use a https://tools.ietf.org/html/rfc7519#section-4.1.7[JTI] (JWT ID). A JTI 
prevents a JWT from being replayed. This 
https://auth0.com/blog/blacklist-json-web-token-api-keys/[auth0 blog article 
get deeper in that].  The same is kinda achieved with the password recreation 
feature. When the user log in after the new password creation, the password has 
already been  changed. So the link (in the sent email) containing the JWT for 
the creation of the new password can't be reused.
 . Tie the encryption key to the hardware. You can refer to this 
https://en.wikipedia.org/wiki/Hardware_security_module[Wikipedia page] for more 
information.
 . If you want to get deeper in this get to this 
https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/Key_Management_Cheat_Sheet.md#user-content-storage[OWASP
 documentation] 
 

Reply via email to