I have a public database where users need to store configuration files. The file can contain passwords. Everyone can read config files but only the server can read passwords in them.

In the browser, when a user wants to add a password to the the config file:

  • User hash the password using bcrypt
  • User encrypts the hashed string with public key A
  • User adds the encrypted string to the config file and saves it to the database

A third party server will then connect to the database, this server knows the private key for A. This server verifies if some plaintext password match with the encrypted hash. Other users see the config file, but they can't see what passwords are in it.

Some precision :

  • I don't care if another user edits the encrypted password, and I don't care who edits the password, so I don't think I need to sign anything.
  • It's really a public database, like a mysql instance without any security.
  • I do the hashing on the client in case the private key gets stolen. It will take a long time to reverse the hash for all passwords.

It seems secure to me. Is it? Is there a simpler way?

  • $\begingroup$ I'm a bit confused in the first paragraph. What I've understood is configuration files contains passwords... Are you trying to say there is also a file that contains password other than the user's configuration files that can be read by everybody? Maybe you should first mention your problem then your solution. $\endgroup$
    – kelalaka
    Feb 7, 2019 at 18:33
  • $\begingroup$ What are you trying to accomplish with "crypt the hashed string with public key A"? Knowing the bcrypt output reveals nothing. $\endgroup$
    – zaph
    Feb 8, 2019 at 0:02
  • $\begingroup$ @kelalaka I will try to be more specific. Passwords needs to be stored directly in the config file, and this config file will be visible to every user (it's a requirement). If user A put a password in the file, I don't want User B to see it. But User B will be able to see/edit other part of the config file, no problem with that. And it's also a requirement to store config in a public database without intermediary server. $\endgroup$ Feb 8, 2019 at 8:08
  • $\begingroup$ @zaph I want to avoid bruteforce by other users... Because it's possible that there is very weak passwords in the file... $\endgroup$ Feb 8, 2019 at 8:10
  • $\begingroup$ If you don't put a layer that removes the part of the file that contains others passwords then enables to read and write it is impossible. And this part is already off-topic here. $\endgroup$
    – kelalaka
    Feb 8, 2019 at 8:14

1 Answer 1


It's generally not a good idea to store passwords of any kind in a database that's not secure, let alone a database that's intended to be publicly available.

Is it secure?

If you don't care about tampering and wrong entries in the database then I guess this setup is okay.

Bcrypt already incorporates a salt to prevent rainbow attacks, so all passwords should have a different hash. Since you then encrypt the hash with the public key of an asymmetric encryption algorithm it should actually be secure. To try and brute-force a password in the database you would first have to brute-force the asymmetric encryption, which is infeasible on any time-scale.

Is there a simpler way?

Yes, implement security-conventions (secure database, etc.), no need to reinvent the wheel.

  • $\begingroup$ For the record: I do this because the server can't modify/filter fields in the config file dynamically. And the file will be available to multiple users, and possibly not really trusted users. Of course in real life there is a lot of security layers before accessing the config file. $\endgroup$ Feb 8, 2019 at 9:29

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.