Is using Basic Authentication in an iOS App safe?

Question

I am working on an iOS app that will be sending the user's username and password for each URL request. Currently, only because for simplicity until it's ready to be launched, the username and password is being passed over HTTPS in a GET request like the below.

https://www.example.com/api/login.php?username=user&password=pass

The HTTPS secures the parameters for transmission, but I know that the security concern with this is that the URL can be stored in browser history and any server logs.

My question is... if I get rid of passing the username and password like I currently am doing and I base64 encode them prior to being sent, include them in the header like below, is this safe? Will the username and password be stored in any history or logs?

Authorization: Basic aHR0cHdhdGNoOmY=

EDIT: I already know base64 can easily be reversed... that's not what I'm asking about. I'm just asking about the security of putting usernames and passwords in HTTPS GET parameters vs. the header.

UPDATE: I am now using basic authentication for the login endpoint and returning a JSON Web Token to be used for all requests thereafter.

Answer 1

Will the username and password be stored in any history or logs?

Commonly authorization headers are not logged but, of course, one could configure the application or server to log these data. Thus check your setup.

As for storing in the history: In case of a browser, such credentials will not be stored in the history but might be stored similar to cookies and automatically sent when visiting the site. Yet, since you are not using a browser but your own app, it is up to you how you manage this information.

Answer 2

You should use a temporary token after the first exchange, to avoid transmitting the real credential with every requests. Thus your apps only have to remember the temporary token, not the full credentials.

And yes, it's better to put it in the headers than in the url:

• urls may be logged by the client
• urls are probably logged by the server
• urls may leaks ( https://www.contextis.com/resources/blog/leaking-https-urls-20-year-old-vulnerability/ )

Answer 3

I am not entirely sure whether the OP is asking outright whether the scheme is entirely safe once headers are used:

My question is... if I get rid of passing the username and password like I currently am doing and I base64 encode them prior to being sent, include them in the header like below, is this safe?

...or, if the question only relates to client-side logging, and not the overall safety:

Will the username and password be stored in any history or logs?

However, assuming the question is of overall safety, I'd like to make the point that although the OP is using HTTPS, my understanding is that transferring the credentials over every request is considered bad nowadays because MITM replay attacks are still possible (even though HTTPS is employed). Therefore, even when using HTTPS, a token scheme such as JWT should be favoured over using Basic Authentication on ever request.

Answer 4

is this safe?

Not especially. Base64 encoding can be easily reversed.

Will the username and password be stored in any history or logs?

Maybe, not really possible to tell from the information available. It is, of course, possible that the data would be recorded in a MitM attack.

This really comes down to a question of risk. Is it good practice, absolutely not. Would it be suitable for Financial/Health records, certainly not. Would it be good enough while testing a new product, almost certainly, especially if you are not recording live data and will reset the database before go-live.

Answer 5

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.

Answer 6

is this safe? Will the username and password be stored in any history or logs?

You will mitigate the GET risk at least, as typically no header logs are captured in a proxy or a web-server.

But better to use HTTPS within your application as you don't have to purchase a digital certificate if you are dealing with your own web-server. You can utilize Certificate Pinning and self-signed certificate will be secure enough: https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning.