I think your overall approach is fundamentally flawed. While I can fully understand where you are coming form, your overall approach is misguided.
One of the big contributors to the poor level of security in many applications is due to leaving security to a later stage rather than building it in at the beginning. Too often, the approach is "lets just get the app working and we will deal with security once we have the basic functionality working.
The problem with this approach is that getting the basic functionality to work will often establish restrictions and guide design in such a way that your options when it comes to security become limited.
This is completely understandable. When you sit down to right the new killer app, you want to focus on the cool parts - the key functionality you want to see and you want to see real progress. Often, there are managers and decision makers who increase the pressure to produce something to see. All this secuirty stuff is just scaffolding which gets in the way - a sort of necessary evil.
Unfortunately, all too often, this results in a lack of emphasis on the security. Either the design makes adding in sufficient security too hard or other pressures, such as delivery deadlines, mean corners are cut.
Start witht he security model. Get that working and then start with the app functionality. It will result in a better design and something which is easier to maintain. In this specific case
- Yep, definitely get rid of the GET parameter approach.
- Forget about the base64 encoding. It isn't really buying you anything and is likely to create a false sense of security.
- Look at ways to minimise the need to send the password or even the username. Consider using some sort of authentication token.
- Make sure your tokens are encrypted.
There are many advantages to using an authentication token rather than just username and password. You can encrypt additional information into the token, such as expiration time. I have even seen tokens which include client details, such as the browser version and OS information, which can be used as a type of fingerprint.
The main advantage of using a token is that your only passing around usernames and passwords an absolute minimum number of times. The less you need to send this information the better. However, to use tokens effectively and in a secure manner, they need to be designed into your application and not tacked on afterwards.
the other advantage in building this into your app from the start is that you can more easily test the various different approaches and libraries out there. There are a number of different token based authentication and authorisation solutions out there and you need to identify which one is best suited to your architecture, language and platform. Get this right at the beginning and the rest will fall into place far more easily than trying to retro-fit it to an existing code base.