[xwiki-devs] A problem of secret with jobs
Hello, I use the Job Module [1] for an extension, and discovered something that could be a concern ... Logs of job execution are stored in permanent directory, which is good. But when using the "{}" notation for writing logs as recommended, the following is output in the "status.xml" file: <org.xwiki.logging.event.LogEvent> <level>DEBUG</level> <message>blablabla</message> <argumentArray> [[ dump of arguments ]] <argumentArray> Inside <ArgumentArray>, all attributes of the object passed as argument to the logger method seem to be dumped - not just a toString(). Currently, in my case sometimes the object I pass contain a password ... I thought I prevented this password from being output in logs by taking care of printing "***" in the related toString, but in fact this way it gets in clear in the status.xml ... I see those possibilities: a- store this password encrypted and decrypt it only when used b- have a possibility to filter what is output in this <argumentArray> (blacklist some attributes) c- only pass individual attributes as parameter and not my full object Obviously a- is the best solution in terms of security. Would xwiki bring me some helpful methods to implement it (server side) ? c- is the short term efficient workaround of course, but I would still be interested to know if there are some crypto tools provided by xwiki (well, most problematic would be to know where/how to store the secret needed for encryption/decryption in an extension, if I want to do more than some scrambling). WDYT ? Thanks, Jeremie [1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Job+Module
Maybe this can help? http://extensions.xwiki.org/xwiki/bin/view/Extension/Encryption+Application -- View this message in context: http://xwiki.475771.n2.nabble.com/A-problem-of-secret-with-jobs-tp7589308p75... Sent from the XWiki- Dev mailing list archive at Nabble.com.
Hello, Yes it could help, I saw it but didn't see at first there was an API behind the UI. Should do the trick thanks ! BR, Jeremie 2014-02-26 8:08 GMT+01:00 Hamster <[email protected]>:
Maybe this can help?
http://extensions.xwiki.org/xwiki/bin/view/Extension/Encryption+Application
-- View this message in context: http://xwiki.475771.n2.nabble.com/A-problem-of-secret-with-jobs-tp7589308p75... Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jeremie, The latest XWiki release (5.4.1) now provides an extensible Crypto API. This is still an @Unstable API, but it is already very modular and complete. I have just added some information about it in the RN and link to its javadoc, see [1]. Depending on your needs, you may use a symmetric cypher, or a one way encryption based on a key derivation function. Do not hesitate to ask if you need my help to use this API, until I write an appropriate documentation. Regards, [1] http://xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki541#HNewextens... On Wed, Feb 26, 2014 at 10:37 AM, Jeremie BOUSQUET < [email protected]> wrote:
Hello,
Yes it could help, I saw it but didn't see at first there was an API behind the UI. Should do the trick thanks !
BR, Jeremie
2014-02-26 8:08 GMT+01:00 Hamster <[email protected]>:
Maybe this can help?
http://extensions.xwiki.org/xwiki/bin/view/Extension/Encryption+Application
-- View this message in context:
http://xwiki.475771.n2.nabble.com/A-problem-of-secret-with-jobs-tp7589308p75...
Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
Hi Denis, Well in my case the (current, for a Password field) flow would be: a- XObject save or update : Browser ---save---> Server, password in clear in save request b- XObject storage in DB : value encrypted as it's a password field ? I didn't check that, right now I don't know c- Later, use of the password (Server side) for a connection : retrieve password from DB (now, in clear anyway in a Java object), do some logging (issue initially described), connect to the system with user/password, done For a- clearly I have no option unless using some javascript to do some encryption at this stage. To be honest it doesn't trouble me much, but if it were I would go for HTTPS... For b- not only would I need to encrypt the password, but I must be able to do that before the XObject is actually saved by xwiki. I suppose I could register some events to manage pre-creation or pre-update encryption (maybe it's the same thing btw) For b- and c- question is of course of using your nice Crypto API, but also where to store the secret. Both sides being the same (xwiki server), I think it has little meaning to use something else than a symmetric cipher with a secret key stored somewhere, but I'm open to proposals. Regards, Jeremie. 2014-02-26 10:47 GMT+01:00 Denis Gervalle <[email protected]>:
Hi Jeremie,
The latest XWiki release (5.4.1) now provides an extensible Crypto API. This is still an @Unstable API, but it is already very modular and complete. I have just added some information about it in the RN and link to its javadoc, see [1].
Depending on your needs, you may use a symmetric cypher, or a one way encryption based on a key derivation function. Do not hesitate to ask if you need my help to use this API, until I write an appropriate documentation.
Regards,
[1]
http://xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki541#HNewextens...
On Wed, Feb 26, 2014 at 10:37 AM, Jeremie BOUSQUET < [email protected]> wrote:
Hello,
Yes it could help, I saw it but didn't see at first there was an API behind the UI. Should do the trick thanks !
BR, Jeremie
2014-02-26 8:08 GMT+01:00 Hamster <[email protected]>:
Maybe this can help?
http://extensions.xwiki.org/xwiki/bin/view/Extension/Encryption+Application
-- View this message in context:
http://xwiki.475771.n2.nabble.com/A-problem-of-secret-with-jobs-tp7589308p75...
Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Jeremie, You will find a snippet of what you need from the crypto API here: http://hastebin.com/dapolufafi (This snippet is more java style then groovy, so you get the details, and require PR) I used lazily the bytes from the encryption key configured in xwiki.cfg, to show you how you may store your own key in config. However, I would suggest to store it in base64, for having a better key (not limited to ascii bytes), or you may as well use a password and get the key from a derivation function. I may provide another snippet for that if you need. Password encryption is salted for a better protection, and I have choose AES for encryption here. Enjoy, On Wed, Feb 26, 2014 at 9:34 PM, Jeremie BOUSQUET < [email protected]> wrote:
Hi Denis,
Well in my case the (current, for a Password field) flow would be: a- XObject save or update : Browser ---save---> Server, password in clear in save request b- XObject storage in DB : value encrypted as it's a password field ? I didn't check that, right now I don't know c- Later, use of the password (Server side) for a connection : retrieve password from DB (now, in clear anyway in a Java object), do some logging (issue initially described), connect to the system with user/password, done
For a- clearly I have no option unless using some javascript to do some encryption at this stage. To be honest it doesn't trouble me much, but if it were I would go for HTTPS... For b- not only would I need to encrypt the password, but I must be able to do that before the XObject is actually saved by xwiki. I suppose I could register some events to manage pre-creation or pre-update encryption (maybe it's the same thing btw) For b- and c- question is of course of using your nice Crypto API, but also where to store the secret. Both sides being the same (xwiki server), I think it has little meaning to use something else than a symmetric cipher with a secret key stored somewhere, but I'm open to proposals.
Regards, Jeremie.
2014-02-26 10:47 GMT+01:00 Denis Gervalle <[email protected]>:
Hi Jeremie,
The latest XWiki release (5.4.1) now provides an extensible Crypto API. This is still an @Unstable API, but it is already very modular and complete. I have just added some information about it in the RN and link to its javadoc, see [1].
Depending on your needs, you may use a symmetric cypher, or a one way encryption based on a key derivation function. Do not hesitate to ask if you need my help to use this API, until I write an appropriate documentation.
Regards,
[1]
http://xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki541#HNewextens...
On Wed, Feb 26, 2014 at 10:37 AM, Jeremie BOUSQUET < [email protected]> wrote:
Hello,
Yes it could help, I saw it but didn't see at first there was an API behind the UI. Should do the trick thanks !
BR, Jeremie
2014-02-26 8:08 GMT+01:00 Hamster <[email protected]>:
Maybe this can help?
http://extensions.xwiki.org/xwiki/bin/view/Extension/Encryption+Application
-- View this message in context:
http://xwiki.475771.n2.nabble.com/A-problem-of-secret-with-jobs-tp7589308p75...
Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO
Hi Denis, Many thanks for the sample ! Interest of using key from xwiki.cfg is that everything is already there and extension does not have to create new params or file or whatever. Or define a new property as you propose and fallback to xwiki.auth.encKey if not present. Maybe I'll write this encryption/decryption process in a dedicated component, so it can be replaced with more sophisticated encryption if necessary. BR, Jeremie 2014-02-27 12:11 GMT+01:00 Denis Gervalle <[email protected]>:
Hi Jeremie,
You will find a snippet of what you need from the crypto API here: http://hastebin.com/dapolufafi (This snippet is more java style then groovy, so you get the details, and require PR) I used lazily the bytes from the encryption key configured in xwiki.cfg, to show you how you may store your own key in config. However, I would suggest to store it in base64, for having a better key (not limited to ascii bytes), or you may as well use a password and get the key from a derivation function. I may provide another snippet for that if you need. Password encryption is salted for a better protection, and I have choose AES for encryption here.
Enjoy,
On Wed, Feb 26, 2014 at 9:34 PM, Jeremie BOUSQUET < [email protected]> wrote:
Hi Denis,
Well in my case the (current, for a Password field) flow would be: a- XObject save or update : Browser ---save---> Server, password in clear in save request b- XObject storage in DB : value encrypted as it's a password field ? I didn't check that, right now I don't know c- Later, use of the password (Server side) for a connection : retrieve password from DB (now, in clear anyway in a Java object), do some logging (issue initially described), connect to the system with user/password, done
For a- clearly I have no option unless using some javascript to do some encryption at this stage. To be honest it doesn't trouble me much, but if it were I would go for HTTPS... For b- not only would I need to encrypt the password, but I must be able to do that before the XObject is actually saved by xwiki. I suppose I could register some events to manage pre-creation or pre-update encryption (maybe it's the same thing btw) For b- and c- question is of course of using your nice Crypto API, but also where to store the secret. Both sides being the same (xwiki server), I think it has little meaning to use something else than a symmetric cipher with a secret key stored somewhere, but I'm open to proposals.
Regards, Jeremie.
2014-02-26 10:47 GMT+01:00 Denis Gervalle <[email protected]>:
Hi Jeremie,
The latest XWiki release (5.4.1) now provides an extensible Crypto API. This is still an @Unstable API, but it is already very modular and complete. I have just added some information about it in the RN and link to its javadoc, see [1].
Depending on your needs, you may use a symmetric cypher, or a one way encryption based on a key derivation function. Do not hesitate to ask if you need my help to use this API, until I write an appropriate documentation.
Regards,
[1]
http://xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki541#HNewextens...
On Wed, Feb 26, 2014 at 10:37 AM, Jeremie BOUSQUET < [email protected]> wrote:
Hello,
Yes it could help, I saw it but didn't see at first there was an API behind the UI. Should do the trick thanks !
BR, Jeremie
2014-02-26 8:08 GMT+01:00 Hamster <[email protected]>:
Maybe this can help?
http://extensions.xwiki.org/xwiki/bin/view/Extension/Encryption+Application
-- View this message in context:
http://xwiki.475771.n2.nabble.com/A-problem-of-secret-with-jobs-tp7589308p75...
Sent from the XWiki- Dev mailing list archive at Nabble.com. _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Denis Gervalle -
Hamster -
Jeremie BOUSQUET