I work with a hardware system that traditionally authenticates users by the entry of a short numeric password on a physical keypad. Despite the small password entropy, this system has proven to be fairly robust because mechanisms are in place to detect brute-force (repeated incorrect password entry). Each user has an associated name string and numeric password. The name string is used only for administrative purposes and not for the authentication process. So, to be clear: The only way for a user to interact with the system is to be on-site and walk up to a physical keypad, at which point they only have X tries to enter the correct numeric password.
We now wish to introduce remote mobile device access to the system by means of an integral HTTPS server and REST API. Because the system is a very constrained, bare-metal embedded platform, implementing a HTTPS server has been possible (and is now achieved), but I believe that accommodating a token-based scheme such as OAuth will be too difficult at this time, and therefore I wish to rely on TLS-encrypted Basic Authentication.
To comply with standards, remote users shall need to provide a password each time they use the phone app. Product management are inevitably going to stipulate that existing legacy user name strings and passwords are used to authenticate a user remotely via HTTPS REST (in other words, when they use the phone app), but clearly the existing short numeric passwords could be brute-forced easily, and I suspect that trying to implement a lock-out mechanism over HTTPS could be difficult and troublesome. Changing the existing system to use longer, more complex passwords isn't an option because the existing legacy system won't support them. Therefore I conclude that each user is going to need a secondary, higher entropy password for the purpose of remote access, alongside their legacy numeric password. I suspect that product management however aren't going to like the fact that the user now has to memorise and use a separate remote-access password.
The scheme I have thought of as a way around this is as follows:
User initially sets up their app to work with the hardware device. The hardware device provides the user (via its LCD) with a long, high-entropy key. The user enters that long key into their mobile app.
The app internally stores that key permanently, associated with the user's short numeric password.
Each time the user wants to use the app, they enter their numeric password. If the app has a key stored internally for that password, then it is used within the Basic Authorization header (possibly appended to the legacy password) to make HTTPS API calls to the hardware.
This way, there is a high-entropy password for the purpose of remote access, reducing the risk of Basic Auth brute-force. The short legacy password is now just used for the app to retrieve the HTTPS password from local storage. In some sense, I suppose this is like pre-sharing a 'salt' via a separate communication channel (which in this case would be the user reading the key from the hardware LCD). It achieves the end goal of giving the user the impression that they're accessing the system (through the app) by means of their regular numeric password.
The one flaw I see with this is that it relies on the mobile device storing the remote access key. How much of a vulnerability that presents is an unknown to me at this time. What I'm thinking is that, if the Basic Authentication process requires a concatenation of both the remote key (permanently stored) and short numeric password (entered by user each time, never stored) then it means that whatever is stored permanently on the device isn't sufficient for an attacker to gain access without further work.
With my constraints considered, are there any flaws or opportunities for improvement with what I have proposed?
