TITLE="Digest Authentication PHP Implementation" -- loggedIn) { // $auth->authenticate(); // } else { // echo '
Login successful
'; // .... // } // - A users table is required in a database with at least the following fields: // userid INT PRIMARY Unique user id // username VARCHAR User name // a1 CHAR(32) Password hash // trust INT Indicates user trust (affected by auth method used) // - Passwords should be stored in the database in the form: // a1 = md5($username.":".REALM.":".$password); // where REALM is the predefined realm name for this login system. // - (OPTIONAL) Somewhere at the bottom of every page, include the following code: // $auth->authenticationInfo($contentMD5); // where $contentMD5 is the md5 checksum of the web page. // Notes: // - Code is not provided here for the creation of user accounts. In particular, a secure // arrangement for allowing the user to choose their password in the first place would be // needed. This could maybe be done using a true secure method such as SSL, or by some kind // of public key method (would probably need to use javascript for this). // - Digest Authentication is not the world's answer to web security. If you need a truly secure // system you should almost certainly be using SSL instead. In particular, all data except for // the user's password is sent in plain text as usual. Additionally, this implementation is // unavoidably vulnerable to certain "Man in the Middle" attacks as detailed in section 4.8 of // RFC 2617 - HTTP Authentication (http://www.ietf.org/rfc/rfc2617.txt). Also, if Auth is used // instead of Auth-int, POST requests could potentially be modified en-route by a malicious // proxy. // - ':' symbol is not allowed in user name to allow for compatibility with Basic authentication. // Current browser issues: // - Currently only Opera is known to support Auth-int. IE and Mozilla only support Auth. // Mozilla bug: http://bugzilla.mozilla.org/show_bug.cgi?id=168942 // - Mozilla and IE completely ignore the Authentication-Info header (they neither reject the page // if the server sends an incorrect rspauth, nor do they use the nextnonce value for the next // request, resulting in a 401 with stale=true being sent after the 2 minute stale nonce grace // period has expired even if other pages have been accessed). // Mozilla bug: http://bugzilla.mozilla.org/show_bug.cgi?id=116177 // - IE doesn't resend the Opaque value for subsequent requests, therefore if it is not present, we // allow the request anyway. I don't believe this should actually affect security in any way // since the Opaque value never changes, and if the response is valid then the client must have // the correct Opaque value. // - If the URI has a querystring (ie. ?foo=bar) IE does not include it in the URI it sends in the // Authorization header. This is a violation of RFC2617 section 3.2.2.5. This implementation // works around this bug by being more leniant than the spec allows. This functionality can be // disabled by setting the IECOMPAT constant to false. // - WWW-Authenticate line specifies Digest before Basic since otherwise IE will use Basic. Note // that this goes against the advice in RFC 2617: "Note that many browsers will only recognize // Basic and will require that it be the first auth-scheme presented." // Current implementation issues: // - Nonce count is currently ignored by this system. This should be implemented as extra security // against replay attacks. To do this, we need a method of "remembering" which nonce counts have // been used for the current nonce. Maybe this could be stored in the database, but this would // result in extra queries. Another alternative is to write the used nonce values in a file. // - Error logging code for incorrect password not yet implemented // Issues fixed since last release // - FIXED: Auth-int support will almost certainly break when faced with multipart form data. // eg.