This is an automated email from the ASF dual-hosted git repository.
jleroux pushed a commit to branch trunk
in repository https://gitbox.apache.org/repos/asf/ofbiz-framework.git
The following commit(s) were added to refs/heads/trunk by this push:
new 67e4f61 Fixed: fixes wrong wiki URL
67e4f61 is described below
commit 67e4f61a664b0b7eeb159ed4344161d0a4b8282a
Author: Jacques Le Roux <[email protected]>
AuthorDate: Mon Feb 22 11:45:43 2021 +0100
Fixed: fixes wrong wiki URL
---
framework/security/src/docs/asciidoc/_include/sy-password-and-JWT.adoc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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 b4812e4..2bd20d7 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
@@ -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]
