[ 
https://issues.apache.org/jira/browse/JSPWIKI-205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14146057#comment-14146057
 ] 

Jürgen Weber commented on JSPWIKI-205:
--------------------------------------

Keeping the key only in memory indeed requires a way to get the key into memory 
;-)

Over the web gui: the wiki is not usable until the admin enters the key

>From the console as command line parameter: key is visible with ps

Require the admin to enter the key on console during startup: secure, but 
requires admin interaction on startup, also no startup in background possible 
(catalina.sh start).

A variant is a unix command line tool that is run after startup of the server 
and that reads the key from console and enters the key into the server via REST 
or similar. 

But, all ways that require admin interaction on each server startup are crap.

So I suggest the a little less secure way: the wiki reads the key from a file 
which is encrypted with a masterkey (which is buried in the wiki code). 

This is the way application servers store their admin passwords.  


> Obfuscate on disk content type
> ------------------------------
>
>                 Key: JSPWIKI-205
>                 URL: https://issues.apache.org/jira/browse/JSPWIKI-205
>             Project: JSPWiki
>          Issue Type: Improvement
>          Components: Core & storage
>            Reporter: Chris Lialios
>            Priority: Trivial
>         Attachments: BasicOverview.doc, EncryptingProviderSource.zip, 
> encryption.patch, encryption.patch, encryption.patch, encryption.patch
>
>
> We would like to store passwords within the wiki pages. 
> Securing the page is trivial, however the contents on disk remain clear text.
> It would be very nice to have a page type that could be stored in an 
> obfuscated form on disk. 
> As an addition  have a secondary password to display/edit the encrypted 
> contents on disk for those who do not want to use wiki security on the page.
> I suspect this will have potentially drastic effects on the revisions 
> process, but it would be a small price to pay for security.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to