Steven, no probs with wanting to use Digest. As you say a low barrier is better than no barrier.
OBF works because the real password can be recovered. It is intended only to protect from casual "look over the shoulder" attacks. I've no idea why our MD5 is different to the unix utils (I wrote the code literally decades ago!). But it must be correct in some form, else the browsers would not agree on the hashes they create and send? I'll do a little research... cheers On 7 December 2017 at 20:19, Steven Hirsch <[email protected]> wrote: > On Thu, 7 Dec 2017, Greg Wilkins wrote: > > I think the problem is with the Digest algorithm plus the concept of MD5 >> hash. Digest avoids sending the password over the wire by using it to >> encrypt a nonce, then the server does the same calculation to see if the >> same result can be achieved. This means that the server needs to have the >> raw password with which the algorithm can be run. >> >> This is unlike BASIC auth, which sends the password over the wire all the >> time, but then the server can get by with only a MD5 hash of the password >> as it just hashes the received password and checks if it gets the same MD5 >> result. >> >> So you are beginning to see why these auth methods suck! >> > > Yup. But I'm just trying to put up a low barrier anyway. > > However, all is not lost. It turns out that the first step of the digest >> algorithm is to get an MD5 hash of user:realm:password, So if you hash >> that combination rather than just the password, then it should work! >> > > Yes, it does work - PROVIDED that I use the Jetty java API to generate > MD5. If I use the one in Tomcat (or Linux md5sum) I get a different MD5 > hash that does NOT work. > > I thought MD5 == MD5. Why does the Jetty algorithm fail to produce the > same results? > > And, inquiring minds want to know, why does OBF work with only the > password? > > We really should document that !! Chris??? >> > > I'll second this. I actually _started_ with user:realm:password, but > since it was generated using md5sum it failed (the same result works fine > in Tomcat). > > Thanks for getting back! > > > >> On 7 December 2017 at 16:54, Steven Hirsch <[email protected]> wrote: >> I know HTTP 'Digest' is not recommended for production, but the use >> case is an internal web >> service that doesn't rise to requiring certificates, SSL, etc. >> >> Actual deployment is on Tomcat 7, where everything went very >> smoothly. However, the test >> framework relies on Jetty 9 under 'gretty' as part of the build >> process and that's where I ran >> into problems. >> >> If I setup the realm.properties file to hold the password in >> plain-text, it works fine, but an >> MD5 hash does not. I tried generating the hash using both md5sum >> at the command line and the >> Apache Tomcat 'digest.sh' tool. Both generate identical results. >> I placed the hash in the >> properties file with an 'MD5:' prefix per documentation but it >> simply does not authenticate. >> >> Since plain-text works, I have to assume the problem is either a >> Jetty bug or misunderstanding on >> my part. Would appreciate some input on this problem - thanks! >> >> >> >> -- >> _______________________________________________ >> jetty-users mailing list >> [email protected] >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit >> https://dev.eclipse.org/mailman/listinfo/jetty-users >> >> >> >> >> -- >> Greg Wilkins <[email protected]> CTO http://webtide.com >> >> >> > -- > _______________________________________________ > jetty-users mailing list > [email protected] > To change your delivery options, retrieve your password, or unsubscribe > from this list, visit > https://dev.eclipse.org/mailman/listinfo/jetty-users > -- Greg Wilkins <[email protected]> CTO http://webtide.com
_______________________________________________ jetty-users mailing list [email protected] To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/jetty-users
