First of all, try to understand how SSL (HTTPS) and HTTP authentication works.
The usual HTTP authentication methods (Digest, Basic, and any forms+cookie based authentication scheme you can implement on top of HTTP) are all insecure by themselves, because they send authentication information more or less in clear text. Whether the data is in POST fields or headers, and whether base64-encoding is applied, doesn't matter at all in this regard, the password is clearly visible to anyone with access to the network traffic. This means that HTTP authentication over an untrusted channel is worthless: all it takes for an attacker to read your password is a little network sniffing.
SSL implements a secure communication channel over an inherently insecure channel. This works, roughly, as follows:
- Server sends a signed certificate
- Client validates certificate against a list of known-good signing keys; certificate signatures can be chained, so that each node says "if the signature that signs me is good, then so am I", but ultimately, the chain needs to resolve to one of the handful of trusted authorities preconfigured on the client.
- Client uses server's public encryption key to send a shared secret
- Server decrypts shared secret using private key (because only the legitimate server has the private key, other servers will be unable to decrypt the shared secret)
- Client sends actual request data, encrypted using the shared secret
- Server decrypts request data, then sends an encrypted response
- Client decrypts response and presents it to the user.
Note a few important points here:
- The certificate chain allows clients to make sure that the server they're talking to is the real one, not someone intercepting their requests. This is why you should buy a real SSL certificate, and why browsers throw scary warnings at you when you hit a site that uses an invalid, expired, or otherwise incorrect certificate: all the encryption in the world doesn't help if you're talking to the wrong person.
- The public/private encryption used to exchange the secret makes sure that succesful communication will only work between this particular pair of client and server: sniffed network packets will be encrypted, and they will require the server's private key to get at the data.
- Symmetric encryption is used for the bulk of the request, because it has a much lower performance overhead than private/public key encryption. The key (shared secret) is exchanged using private/public key encryption though, because that is the only way to do so in a secure way (except transporting it over a separate channel, such as a courier service).
So obviously, there is some overhead involved, but it's not as bad as you'd think - it's mostly on the scale where "throw more hardware at it" is the appropriate response, unless you're preparing for absolutely massive amounts of traffic (think Google or Facebook). Under normal circumstances, that is, typical web application usage, the SSL overhead is negligible, and consequently, as soon as you have any confidential data at all, it's best to just run everything over SSL, including resources. SSL is also the only viable way of securing HTTP traffic; other methods are simply not as standardized and thus not widely supported, and you absolutely do not want to implement these things yourself, because honestly, it's just too easy to get them wrong.
TL;DR: Yes, SSL + Basic Authentication is a good idea, yes, you need a secure server (and a valid certificate), yes, it will slow things down a bit, but no, this is not something to worry about right now.