# Apache: Make login last longer



## ralphbsz (Oct 5, 2017)

I have a really dumb question, which has little to do with FreeBSD, and is really more about Apache and how the HTTP protocol is implemented.

I have a web site (served via https) which requires a username/login password for security.  No problem, it's configured in the httpd-ssl.conf file, works great.  I'm copying the stanza below for your amusement.  Once the user has logged in, they can follow links within the directory tree being served securely.  The only drawback is this: the "authentication" is good for a limited period; it seems to last typically 12 to 24 hours.

Is there a way I can adjust it so once a user has logged in, they can continue using this area for a very long time, like a month or so?  The number of people who have that username/password combination is very small, and they are highly trusted.  It leads to a general question: Where is the "authentication state" actually stored?  Does the server send a cookie to the browser which the browser then presents on followup requests?  Does the server store the IP address or some similar identity of the client?  How does authenticated HTTP actually work?


```
<Directory /home/www/secure>
      AuthUserFile /home/www/secure/.htpasswd
      AuthGroupFile /dev/null
      AuthName "LindaRalphJohn: by permission only"
      AuthType Basic
      Require valid-user
    </Directory>
```


----------



## ShelLuser (Oct 5, 2017)

ralphbsz said:


> Is there a way I can adjust it so once a user has logged in, they can continue using this area for a very long time, like a month or so?


That's usually done using a cookie.


----------



## ekingston (Oct 5, 2017)

AuthType Basic happens every time you send a request. It's part of the headers that the browser sends. Your browser will typically cache the name/password until you close it. Browsers may put a time limit the cache. At least that's what it looks like you are experiencing to me.


----------



## obsigna (Oct 5, 2017)

ralphbsz said:


> ... The only drawback is this: the "authentication" is good for a limited period; it seems to last typically 12 to 24 hours.



HTTP Basic Authentication by itself does not impose time limits. The browser is required to inform the authentication information by the way of the HTTP header for each single request to the server. So, a dumb browser would need to ask in this scenario for the username/password combo for each single load, and therefore sophisticated browsers (of which presumably we are talking about) cache the login information and reuse this during the session - usually this extends to until the browser is restarted.



ralphbsz said:


> Is there a way I can adjust it so once a user has logged in, they can continue using this area for a very long time, like a month or so? ... It leads to a general question: Where is the "authentication state" actually stored?  Does the server send a cookie to the browser which the browser then presents on followup requests?



You are looking at the wrong place. As long as we are talking about the two generic HTTP authentication schemes, the server does not cache the authentication information, the browsers do, and most browsers that I know of, offer to store the username/password combo into their site specific local login database (s. the screenshot of my Safari browser). This would last, until the user resets said login database, or until you renew the password (invalidating the old one) on the server side.






ralphbsz said:


> Does the server store the IP address or some similar identity of the client?



NO -- not in both generic HTTP authentication schemes Basic and Digest. Third party schemes implemented on dynamic web sites (like the FreeBSD Forums) usually do this by the way of cookies.



ralphbsz said:


> How does authenticated HTTP actually work?



https://tools.ietf.org/html/rfc7617

See also:

https://tools.ietf.org/html/rfc7616


----------



## ralphbsz (Oct 6, 2017)

Thanks.  Seems I was barking up the wrong tree.  This won't work.

What I want to accomplish is: Set up an area on the web browser that's easy and convenient to use (even from a cellphone, where typing passwords is impractical), but highly restricted to a small set of people (in this case, immediate family).  All that with the minimum amount of labor to set up.  Clearly, the central question is: How to store authenticators on the client device and keep them secure there.  I'll think about other solutions.


----------



## ekingston (Oct 6, 2017)

ralphbsz said:


> Thanks.  Seems I was barking up the wrong tree.  This won't work.
> 
> What I want to accomplish is: Set up an area on the web browser that's easy and convenient to use (even from a cellphone, where typing passwords is impractical), but highly restricted to a small set of people (in this case, immediate family).  All that with the minimum amount of labor to set up.  Clearly, the central question is: How to store authenticators on the client device and keep them secure there.  I'll think about other solutions.



My old Android phone stored passwords and my current iPhone does a well. Once entered and saved, like obsigna pointed out, I haven't had to re-enter credentials. Just select which one and submit.

If that's not working, you can do client certificate authentication but that requires configuring the web server to validate the certificates and that is a lot more complicate. Also, I don't know if mobile browsers support client authentication yet.

If you are only allowing access from within a private network (like your home WiFi) you could provide access restrictions based on IP address. But this means it won't work remotely (or at least won't work safely unless everything you care about is assigned static IP addresses on the Internet, which isn't the case with cell phone data plans).

Otherwise, the universal solution of authenticate and save cookie is your best bet. This will require that you write it yourself, or find some suitable open source project that provides it.


----------

