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.
- 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?