Am Sonntag, 18. März 2012, 12:16:48 schrieb Charles Duffy:

On Sun, Mar 18, 2012 at 10:16 AM, Dimitar Popov < Dimitar.Popov@uni-konstanz.de> wrote:

...

Am Sonntag, 18. März 2012, 09:08:36 schrieb Charles Duffy:

...

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.

Hashing could work, but adds a requirement that only basic auth be supported. Given the number of other credential-proving mechanisms in the world (Kerberos, NTLM, etc), this seems a very unfortunate limitation to place on future development.

As for encrypted swap -- in a typical commercial environment, that's outside of the dev team's control unless they bother to do a great deal of paperwork and politics; in short, not an acceptable solution.

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.

Again, to make that keystore secure, you're creating requirements that the typical user won't implement. Better to design things to be secure out-of-the-box, rather than "secure if only you do A, B, C and D".

Well, then it seems after all, that the token alternative provides the highest degree of flexibility and security :) I guess, if there are no other suggestions, it should be discussed how to implement it.

Regards, Dimitar