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(a)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