use of keyring for every session

[Sanjmeh]

I run a shiny app where I connect to a MariaDB database using the admin user id and password.
To avoid sharing my DB access password every time I connect to it, I have stored it on a keyring using the keyring package of R and then call the dbConnect.

con <- DBI::dbConnect(RMariaDB::MariaDB(),user = "admin",password = keyring::key_get("MARIADB",keyring = "shiny",username = "admin"),dbname = "newdb")

But for every session the keyring needs to be unlocked and hence I have to use the following in my source code.

keyring_unlock("shiny",password = "XXXXXXX")

This exposes my keyring password in the source code that is then checked in github,

My question is: how safe are we if, to protect one password, we encrypt it with another password but expose the other password in the source code?

[andresrcs]

I store credentials on a Renviron file and obviously I don't keep that under version control. Then I call Sys.getenv() in the code to retrieve them programmatically.

[Sanjmeh]

Ok, well the Renvron file is a plain text and if the system is compromised, all .txt or /etc files are immediately checked for passcodes. So we still are vulnerable to the same extent.

[andresrcs]

@Sanjmeh

to protect one password, we encrypt it with another password but expose the other password in the source

Yes, but I think what you describe is even worst.
It would be harder to hack a well secured production server where the attack surface is minimized, than an app that is purposely exposed to the public. The file system is not deliberately exposed.

The idea of interactively unlocking a keyring is way safer but not practical for deployment, because it requires human intervention.

If you want to ensure only authorized people gets access to your database, I think you should implement per user access control at the database level, that way only people with a user and password (or any other security measure) can access the data you have gave them access to.

[Sanjmeh]

@andresrcs

I think you should implement per user access control at the database level,

To implement per-user access control, we have to prompt for a passcode at the shiny app level, which is fine. But finally I have to save the passwords on a keyring. To encrypt the keyring, I still have to use a password. And this password is embedded in the code. So we are still there where we started from.

[andresrcs]

I think you misunderstood what I meant, the access management for the data base is handled by the RDBMS so there is no need to unlock any keyring at run time, if necessary at all, that would be an administrative task for setting the RDBMS.

Even if you want to implement access control at the shiny app level, the way this is handled is that the user credentials are stored encrypted and decryption happens when the user logs in so there is no need to store any password as plain text.

@Sanjmeh

And this password is embedded in the code. So we are still there where we started from.

Can you explain why you think this is necessary so I can try to clarify what I am proposing?