Sending again, since my email client decided to break the layout of the message ;)
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:
- 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.
- 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/Crypto...
Regards, Dimitar
BaseX-Talk mailing list BaseX-Talk@mailman.uni-konstanz.de https://mailman.uni-konstanz.de/mailman/listinfo/basex-talk