Is HTTPS and Basic Authentication secure enough for banking webservices (RESTful)?
HTTP Basic Authentication is not much used in browser-server connections because it involves, on the browser side, a browser-controlled login popup which is invariably ugly. This of course does not apply to server-server connections, where there is no human user to observe any ugliness, but it contributes to a general climate of mistrust and disuse for Basic Authentication.
Also, in the 1990s, before the days of SSL, sending plaintext passwords over the wire was considered a shooting offence, and, in their folly, people considered that challenge-response protocols like HTTP Digest were sufficient to ensure security. We now know that it is not so; regardless of the authentication method, the complete traffic must be at least cryptographically linked to the authentication to avoid hijack by active attackers. So SSL is required. But when SSL is in force, sending the password "as is" in the SSL tunnel is fine. So, to sum up, Basic Authentication in SSL is strong enough for serious purposes, including nuclear launch codes, and even money-related matters.
One should still point out that security relies on the impossibility of Man-in-the-Middle attacks which, in the case of SSL (as is commonly used) relies on the server's certificate. The SSL client (another server in your case) MUST validate the SSL server's certificate with great care, including checking revocation status by downloading appropriate CRL. Otherwise, if the client is redirected to a fake server, the fake server owner will learn the password... In that sense, using something like HTTP Digest adds some extra layer of mitigation in case the situation got already quite rotten, because even with HTTP Digest, a fake server doing a MitM can still hijack the connection at any point.
If we go a bit further, we may note that when using password-based authentication, we actually want password-based mutual authentication. Ideally, the SSL client and the SSL server should authenticate each other based on their knowledge of the shared password. Certificates are there an unneeded complication; theoretically, SSL client and server should use TLS-PSK or TLS-SRP in that situation, and avoid all the X.509 certificate business altogether.
In particular, in SRP, what the server stores is not the password itself but a derivative thereof (a hash with some extra mathematical structure). One shall note an important point: in the case of a Web API, both the client and the server are machines with no human involved. Therefore, the "password" does not need to be weak enough to be remembered by the meat bags. That password could be, say, a sequence of 25 random characters, with an entropy gone through the roof. This makes the usual password hashing methods (slow hashing, salts) kind of useless. We still want to avoid storing in the server's database (thus as a prey to potential SQL injections) the passwords "as is", but, in that case, a simple hash would be enough.
This points to the following: ideally, for a RESTful API to be used by one server to talk to another, with authentication based on a shared (fat) secret, the communication shall use TLS with SRP. No certificate, only hashes stored on the server. No need for HTTP Basic Auth or any other HTTP-based authentication, because all the work would have already occurred on the SSL/TLS level.
Unfortunately, the current state of deployment of SRP-able SSL/TLS implementations usually means that you cannot use SRP yet. Instead, you will have to use a more mundane SSL/TLS with an X.509 certificate on the server side, that the client dutifully validates. As long as the validation is done properly, there is no problem in sending the password "as is", e.g. as part of HTTP Basic Authentication.
A primary problem with HTTP authentication is that there's no way to log out, other than to close your browser. And since the password goes with each request, the authentication is stateless. You can't log users out after 20 minutes of inactivity, for example.
High-security sites like banks will typically (always?) provide not only a means for a user to log out manually, but will also log user out after a period of inactivity. This helps prevent a number of opportunistic attacks.
Actually I have seen these requests being sent by my bank. However they do still use session identifiers instead of sending the username and password every single time (this is not really restful, I know). The reason why they do not use just username and password but a session is because they require a second factor of authentication. This means that you would need to re-enter your challenge response for every page reload.
If your bank is just using username and password, then honestly I wouldn't care about it. But in my opinion, any self respecting bank application should use a form of two-factor authentication: either through SMS, card readers, tokens,...