Does this mean that if I am using the JDBC realm, tomcat will hit the database for verifying username and password for every request? Also, if this is really happening, then the user will need to authenticate himself for each of his request, meaning that nonce for the digest challenge will be different. Therefore, the same authentication information is useless for hitting other pages. Am I right in that assumption?
On 11/9/05, Peter Menzel <[EMAIL PROTECTED]> wrote: > > Hi, > > Khawaja Shams schrieb: > > Hello everyone, > > I have a few strict requirements for security on my project, and I am > having > > a hard time understanding some concepts. I cannot use SSL due to the > > performance loss, and the application must be accessed only by > authenticated > > users. Meanwhile, I am required to never send the password in cleartext. > I > > have successfully implemented a DIGEST authentication with the helpful > > response from Mark Thomas, but I am curious about how authentication for > > further requests takes place. I notice that the user is prompted for the > > password only the first time, and subsequent requests are automatically > > authenticated. Is the authentication information stored in a session > > somewhere? > > The browser caches your username and (digested) credentials and sends > them with each request in a HTTP request header. If you close your > browser, the information are cleared, unless you tell your browser to > memorize them. > > Is this easy to obtain through sniffing? Could a sniffer > > potentially fake an authenticated client's session id to get access to > an > > application? > > Yes, A sniffer only needs to capture only one request with your > username/credentials and may subsequently misuse them for accessing the > webapp. > > DIGEST is nearly as weak as BASIC/FORM, the only difference is, that the > password is going through a hash function, which creates a digest of > your password, from which the original password can not be restored. > > For optimal security SSL is a good option. > > Peter > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
