I'm asking here because many people here have solid apache experience. As you know you can put this code in the .htaccess file:

AuthType Basic
AuthName "RelateBase Application Library"
AuthUserFile "/home/relbase/.htpasswds/lib/passwd"
require valid-user

and then the passwd file would look like this:

relbase:Ap.baxgseHgvJ

I am writing a php application and can read the files without ht access. However I want to simulate a login window and honor the login username and password. My question is, how do I read the password submitted by the user and encrypt it so I can compare it with "Ap.baxgseHgvJ" above? It is obviously not an md5() encryption.

Thank you for your response.
Samuel

    hmm... maybe you can invoke the htpasswd program with the user supplied password so as to update the password file.

      sfullman;10950958 wrote:

      and then the passwd file would look like this:

      relbase:Ap.baxgseHgvJ

      Is that an actual value you've found in a .htpasswd file? The Apache documentation states that htpasswd hashing is done using either the crypt() function (on non-Windows OS's) or the MD5 algorithm. The example password hash you gave above doesn't match either of those algorithms.

        yes that is an actual value I pulled off an htpasswd file (OK I modified some characters for security), but NO it's not MD5 as it was not hexidecimal even before my minor changes, nor was it 32 characters long.

        What I need is how to translate the one and only RIGHT password into that string so I can compare. I do NOT want to modify this password but keep it as is, since outside users are still going to be logging in through the standard password protection interface.

        thank you..

          sfullman wrote:

          What I need is how to translate the one and only RIGHT password into that string so I can compare. I do NOT want to modify this password but keep it as is, since outside users are still going to be logging in through the standard password protection interface.

          Ah. Basically, you need to figure out the password file format. If you happen to know what is the options used to create that password, then it'll be easier, otherwise it is a matter of reading documentation, and maybe also testing to see what are the markers used to differentiate between the use of the different algorithms offered, and from there deducing what algorithm to apply.

            Looks like the password you supplied above is using the crypt algorithm (so I'm guessing it was from a Unix OS). Problem is, an htpasswd can simultaneously hold passwords in 3 different hashed forms, not including an unhashed form (which is valid). Basically, if you're trying to parse the htpasswd file yourself, you need to check the password 4 different ways before rejecting it as invalid.

            The problem is this:

            Apache 2.2 Manual wrote:

            The crypt() and MD5 formats permute the representation by prepending a random salt string, to make dictionary attacks against the passwords more difficult.

            I'm not sure how Apache generates this salt string, so I'm not sure how you'd go about validating passwords on your own.

              bradgrafelman wrote:

              I'm not sure how Apache generates this salt string, so I'm not sure how you'd go about validating passwords on your own.

              Following the normal practice, the salt will be included with the password, so there should be no need to reproduce it. What is needed is to determine the format such that the salt can be differentiated from the password hash, and then to determine how the salt is combined with the original password to obtain the input to the hash function.

                laserlight;10950977 wrote:

                Following the normal practice, the salt will be included with the password, so there should be no need to reproduce it. What is needed is to determine the format such that the salt can be differentiated from the password hash, and then to determine how the salt is combined with the original password to obtain the input to the hash function.

                In other words, this?

                Apache Manual wrote:

                The salt for a CRYPT password is the first two characters (converted to a binary value).

                  bradgrafelman;10950971 wrote:

                  Basically, if you're trying to parse the htpasswd file yourself, you need to check the password 4 different ways before rejecting it as invalid.

                  The problem is this: I'm not sure how Apache generates this salt string, so I'm not sure how you'd go about validating passwords on your own.

                  youare correct. I don't want to write to this file, only read it and validate my own logins. I don't mind checking 3 times 🙂 but mainly if someone can provide a starting point or link to the encryption algorithm.

                  you are correct my os is a *nix system, and apache/PHP is:

                  Apache/1.3.41 (Unix) PHP/4.4.8

                  Thanks

                    bradgrafelman wrote:

                    In other words, this?

                    Yes. It looks like you have also unearthed the relevant password format documentation, though the "Apache-specific algorithm using an iterated (1,000 times) MD5 digest" does not look promising unless one wants to dig up what exactly is the algorithm.

                      One way to sidestep this whole reverse engineering thing would appear to be to use the server itself.

                      Have your program construct a request for a protected resource (which could be a dummy, because we don't actually care what it is - if you can make it a HEAD request instead of a GET then that would be even cheaper); include an "Authorization:" header that contains the supplied credentials.

                      Send that request to the server being controlled by this .htaccess and see whether the response is a 200 or a 401/403.

                      Not only will this check the username/password combo, but any other rules that might be in play.

                        on checking the server - I can use curl for this and just tunnel through if the password validates. I'm always going to be calling from the server to the server, so is tehre any chance these auth requests are going to be visible to the outside world?

                        thanks

                          Write a Reply...