0

I am making an app which connects to a DB, and the app will have plenty different userslogins.

Is it a good design choice to have a specific DB login/password for the application, using which the application will connect to the DB, and then verify userlogin/hashed+saltedpassword which are stored in a TABLE? (and for PostgreSQL to then SET ROLE to a user with necessary privileges for different TABLES/SCHEMAS)

My problem with this is I don't fancy the idea of having to store any credentials in the application, as if it's "reverse engineered" and the source code is found the hacker would know the credentials to access the database, and knowing the logic of the application he could then use "SET ROLE" himself and get access to any user he knows.

I just don't know how to access the DB without storing credentials in the application itself. I can make the user credentials = DB credentials, then no credentials would be stored but then the user could access the DB directly. So do we have to store the DB credentials in our source code?

Thanks!

Edit:

So it's like this:

User -> inputs his credentials into the app

App -> has login/password stored in the source code to access the DB, it connects to the DB and does

SELECT hash, salt FROM login_table WHERE userlogin = *given user login*

The app uses the given password and hashes it with the salt it found in the login_table, then it tries to match the just hashed password with the hash from login_table. If those match - the application does

SET ROLE *given user login*

(this is specific to PostgreSQL) and then does all the other stuff using the established connection.

But while this seems great, the app needs to connect to the DB in the first place, so do I store it's DB login&password in the source code?

Improve this question
7
  • Keep the database credentials in the database (password salted and hashed) - your users will have to login, but that's better than storing them in the app (I presume that you might want to keep them in the app to allow the users to be connected directly without having to login?)/.
    – Vérace
    Aug 27, 2014 at 10:05
  • I meant that there're going to be app-credentials (for users to log in into the app) and db-credentials (for the app to login into the DB and being able to "download" the list of users and their passwords). So users put their credentials into the app, the app logs into the DB with app user/password which is stored in the source code, selects the hashed password and salt for the user from a table and using the salt tries to hash the password again and then compare the provided (and now hashed) password with the hash selected from a table. But in order to do this the app has to access the DB.
    – kiradotee
    Aug 27, 2014 at 10:20
  • So the actual passwords of the users aren't stored in the application rather the hash&salt of their passwords is stored in the DB. But to view those the app should be able to access the DB in the first place, so it needs a DB login/password. Should these be stored in the source code?
    – kiradotee
    Aug 27, 2014 at 10:24
  • The point of the login_table is generally when you can't create the accounts as database users, for all sorts of reasons. But if you plan to issue SET ROLE with the login, it has to exist as a db role, so what's the point of not using it to connect in the first place and let postgres deal with the authentication?
    – Daniel Vérité
    Aug 27, 2014 at 10:38
  • Because then they'll be able to access the DB directly. Like using PgAdmin.
    – kiradotee
    Aug 27, 2014 at 13:11

0

Reset to default

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.