Building solutions

It was today morning when I was thinking of writing a server application that I had an idea for, that I stumbled across a weird situation.

“ Databases have a username and password that allows a user to access its tables. Where do production servers store these ? ”

Me being fairly new to building production servers, was confused.

I asked around a couple of people that I had acquainted with in the past. Found a few solutions. Googled it, found a few answers on stackoverflow.

THEN, during my shower, I came up with a solution of my own. AND yes, it is based off of my love for the Server architecture. It is to maintain another server, which when queried, provides all the relevant data.

Thus, I began instantly thinking — Let me write some code to do this.

It was quite easy to visualize it at first as I didn’t know how exactly I’d make it work.

Thus it began, one fine Sunday, the rest day.

Initially my solution was simple. The user sends me a JSON of the User Name and the encrypted password and I somehow have to return it back to him whenever the same person asked for it.

Then, realized, to determine the authenticity of a particular user is gonna be a tough task. Because, if just the User Name was used to identify the authenticity, anyone can spoof the User Name and gain access to the projects.

Thus, I decided to add 2 layers of safety.

• Layer 1 : The password sent will be encrypted and only the User (admin) of the project can decrypt it to obtain the password.
• Layer 2 : The Users have to first register themselves before creating any entries of passwords.

Layer 2 provides high level security against spoof as, once the User is registered, a hash of the (User Name +a random string) is sent back to the user as a confirmation.

On all further transactions, this “hash” must be sent first to confirm the identity of the user and then, the password is registered under that User.

So the current flow is like this :

• The User registers using his User Name.
• The server creates a hash of this User Name along with the a random string and returns it.
• Now, when the User needs to store passwords of a DB for a new project, the User sends a request with the “hash” , project name and the encrypted password of the DB he uses(the key to decrypt exists with the user) .
• The server returns back a new hash of the given combination which can be used by the user to obtain this password from now on.

Let’s get technical now. Given below is the API of the server. Once the server is running, the User can ask the server to ping and do all the transactions.

• The “/register” end-point is used for the initial registration of a user. This creates a mapping of the User and returns the “hash” of the User Name and a randomly generated string of length [10–20]. This is a POST request and takes in the “UserName” of the user. It checks whether this user exists and if true, returns an error pointing out the same.
• The “/storePassword” end-point is used for subsequent queries by the server needing the password. This is a POST request that needs the “UserHash”, “ProjectName” and the “EncryptedPassword” that will be returned once queried for with the right credentials. This returns a new “hashString” based on the above data to maintain the uniqueness.
• The “/getPassword” end-point is used to obtain the encrypted password from the server. This is a POST request that needs the “hashString” returned by the server to obtain this data.

Server must possess the “HashString” and the “private key” (or any other means to decrypt the password) of the encrypted password from its end to function based on this solution.

The person breaking into any one server cannot gain access to the passwords as :
1. If they break into the server containing user hash mappings, the password is encrypted and theres no key to decrpyt.

2. If they break into the web server, there only exists the private key and not the password.

3. When the server starts the user can input the password and open the DB connection and needed only once the connection needs to be opened.

Now, after all the contemplation. I. Realized. That. This is a loop that I’m stuck in.

Let’s look at it again.

Without the idea : The user can either keep the password in the files where the web server can access it OR enter it every time the browser restarts.

With the idea : The user has to enter his “hashString” to recognize the path to the password OR store it in the server.

So, in both the solutions, there must be some human interaction of some sort, or there must be a storage of the password or the path to the password.

This is no good. The solution I tried to build was to remove human interaction AND/OR provide the server machine with an inherent way to obtain a password.

I tried to find alternates like using the server machine MAC ID’s or the IP addresses where the server is hosted on but one way or another its a direct mapping to the password.

Philosophical part of the brain kicked in and made me realize that the human brain can only lead to a path only when there is a path to it similar to getting the password from a direct mapping.

If only, there was a way to indirectly map the user to the password. Alas.

PS : I’ve been wanting to write a blog for a long time and this “IDEA” was a way for me to get into it. Since, I am learning from the world around me, this might not be a place to learn something new but it might be a trigger to make yourself think and learn something new. (hah! direct mappings again)

Anyway, hopefully I’ll be able to think about more stuff and fail and learn and end up with something nice some day.

PPS: I’d really like to hear thoughts on this topic, especially since I want to build this system (https://github.com/SUMUKHA-PK/Database-password-manager here is the progress). Please do hit me up if there are any new insights on this.