I marked the question as a dupe after I figured out exactly what was being asked.
Here's an answer about how you'd roll your own Auth system, which is originally what I thought your question was about :)
If your site is visible on the Internet, HTTP Basic Auth alone will not secure your content.
Sending the username and password to the server
You shouldn't store the username and password anywhere but inside your DB. The password should never be stored in plain text. It should be hashed, using a Salt.
When you authenticate, hash the password with the same Salt, and verify that the resulting hashes are the same.
You could also consider a pre-hash of the password (in addition to the server-side hash) so the plain-text password is never sent over the wire.
Session cookie instead of username/password with each request
Authenticate with the username and password only once, and return a session cookie to the user.
This cookie should be used to look up which user owns the session, and when they authenticated (so the session can expire). If they've got a valid cookie that matches up to an unexpired session, you can consider them authenticated.
Security issues
The remaining problems with this scheme are that it is still going to be prone to a replay attack or a man-in-the-middle attack.
You could mitigate some of this by only allowing authenticated sessions to access your site through SSL.
Another thing that could help (though not completely solve the problem) is store the IP the auth request came from in the session data, and make sure it is the same IP with each request.
If you can, I'd suggest you reuse an existing authentication system rather than rolling your own. It is a little complicated (and prone to problems), and other people have already thought through the details. I'm sure there are details I'm missing, too.