Password storing strategy

[Lykurg]

Hi,

I know, I know, this subject is asked again and again, and now I ask it again because I am very doubtful how to proceed.

The case: An app which need access to a SQL server. The app is something like a recherche tool running at a public library. Port, user and password should be freely changeable by the library administrators, so


storing the password inside the application: No (no change possible)!
creating a login promt querying the password: No, because the app should be opened and closed freely by the strangers coming to the library and using the work terminal.
Store an encryption master key inside the app and make a encrypted password file, which is read in by the app. Possible, because the file could be altered with a new password. And normally save, because not everybody can encrypt that file easily.
Like the above only that the file is send through the "Fortune Server" (->see docs), so the port to Fortune Server could lay encrypted on the client site. More secure, since more knowledge is needed to break in.


So I lean towards the last solution or is there a better way to protect the password in my case? (The application is only running in the library intranet, so the security is a priori better than with a internet based app)

Suggestions, hints, anything is appreciated!

Thanks

[nish]

anything is appreciated!
Thanks

The password should be more than 10 char long and should contain mix of number letters and at least one of !@#$%^&* chars..:p:rolleyes:;)

[lyuts]

What if you store password hashes in your db?
Your applications may be opened by any stranger, right? Let say that the data displayed by your app can be of 2 kinds: public and private. Public data can be viewed by any users without logging in. Private - only by logged in users. When a user logs in he types his login and password. Your application gets a hash out of typed in password and checks it with the one stored in your db. Upon successful authorization the application gets user's id which is later used for querying private data.

These are my thoughts that came up at the very beginning.

[Lykurg]

What if you store password hashes in your db?
Your applications may be opened by any stranger, right? Let say that the data displayed by your app can be of 2 kinds: public and private. Public data can be viewed by any users without logging in. Private - only by logged in users. When a user logs in he types his login and password. Your application gets a hash out of typed in password and checks it with the one stored in your db. Upon successful authorization the application gets user's id which is later used for querying private data.

The thing is I don't want to have a user management. The only question is how to secure provide a company to change the connection settings inside the application without that anybody can see their used user and pass. (The reason is to avoid that people could connect to the database with any other tool and mirror it. The data should only be accessible through the programm.)

Thanks

[wysota]

How about making a small dedicated application for changing settings which you can protect without touching the main application? Would that help?

There is also a possibility to store the settings on some server and using SSL to connect to the server to read the data and another trusted certificate protected channel to modify the data.

Just some thoughts... I'm not sure what you're after precisely.

[Lykurg]

How about making a small dedicated application for changing settings which you can protect without touching the main application? Would that help?
That is exactly my plan, but the problem is more theoretical where and how to store the db access data...


I'm not sure what you're after precisely.
Ok, my thought are also still a bit confuse, but the main points are:

I have a MySQL database on a server, of whom I don't know the url, port, user and password at the compilation time of my program.
The program must not ask the user for any detail of the connection. It should be possible to open the program and use it right away.
So the configuration (DB access) of the program must be done by the system operators.

And the point is that I am not sure, which way I should take to provide the configuration mechanism to the administrators and at the end how and where to store the connection data, that the application can read the MySQL login informations.

My real intention to hide the password and user login to the DB is, that only my program should be able to access the database.


I thinks all is pointing to the Fortune Server with an additional SSL, and since I am not very familiar with that I will have some further investigations on that. Thanks for the hint.

Lykurg

[lyuts]

Sorry if I'm saying the same (I think I'm not).

Solution 1:
We have a server "A" which has MYSQL on it. We also have a client machine "B" which will have your application installed.

What if just create a server-listener which will live on "A"?

A client on "B" will have a configuration consisting of an IP and Port for the server which has server-listener running.
A server-listener waits for client connections and when it gets one it tells the client the credentials for db and the client on "B" will use them for its further work.

Solution 2:
The client on "B" doesn't need any credentials. What it will do is communicate with the server-listener on "A".
Something like this:
a) client on "B" tries to reach server-listener on "A"
b) server-listener on "A" gets this connection and creates an instance of server-worker for client
c) further work looks like this - client communicates with this server and depending on commands the server runs some db queries and returns the result to client.

Sort of thin client.

[wysota]

My real intention to hide the password and user login to the DB is, that only my program should be able to access the database.

So maybe it's easier to perform server-side certificate verification of the SSL connection between the client the MySQL server? I'm sure you can configure MySQL for that and it should be transparent to Qt.

[Lykurg]

b) server-listener on "A" gets this connection and creates an instance of server-worker for client
That's a nice thought. I will think about it!

So maybe it's easier to perform server-side certificate verification of the SSL connection between the client the MySQL server? I'm sure you can configure MySQL for that and it should be transparent to Qt.
Ok this is probably the safest variant, but as said I need to read more about the SSL stuff and how to certificate only one single application etc. But at least I know now what to do the next weekends;)