Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy: > On 3/18/2012 6:09 AM, Dimitar Popov wrote: > > Am Samstag, 17. März 2012, 18:36:30 schrieb John D. Mitchell: > >> Note also that there are a few different aspects of this that people may be confusing/conflating... > >> * Protecting the user credentials for long-term storage in the database itself. > >> * Creating security tokens for the (relatively) high-speed access verification on a per-request basis. > >> * Creating a decently secure communication channel. > > > > Hi all, > > > > Now, since I've finally undestood what this thread is about ;) I have two suggestions, regarding the second point: > > > > 1. If opening a database connection is slow (in our case because of slow authentication), then a wide-spread > > solution in the J2EE world is the use of connection pools. > > The REST interface uses credentials from the individual HTTP requests > for the backend database connections. > > So -- how do you keep a persistent pool, while still authenticating each > HTTP request against the backend database's password store, and make it > fast? > > If you use session auth tokens, you can do it -- keep your connection > pool tied to your session pool -- but I don't know that Christian has > said that he considers that an acceptable solution as of yet. > > Caching accepted username/password pairs in RAM, and maintaining a > separate pool using the credentials for each such pair, would _work_, > but it would mean that you'd have to be careful not to let the memory > that information is stored in get swapped to disk -- writing users' > passwords to disk, even by way of the OS's swap operations, being a > serious no-no.
The pairs username/password can be, of course, hashed and additionally, swap partitions can be encrypted, if such a level of security is required. > > 2. Another alternative which comes into my mind is encrypting the whole password file with a "slow" encryption > > algorithm (we could even use Java Crypto API, since we already use it for the XQuery crypto API). On startup, basex > > will decrypt the file once, an the store the "quick" password hashes in- memory. > > How do you store the key for the "slow" encryption? If your > database-startup routine has permission to read that key, why wouldn't > an attacker just steal it too? AFAIK, JCA provides a keystore mechanism, which I guess, provides enough means of protection against steal. I'm, however, too lazy to thoroughly read the JCA guide [1], but the first which comes to my mind is for example, external storage of keys. [1]http://docs.oracle.com/javase/6/docs/technotes/guides/security/crypto/CryptoSpec.html Regards, Dimitar _______________________________________________ BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk
