So I'm a complete novice in security practices, and an amateur web developer. I have a personal website connected to a personal DB. Currently there is nothing in this DB that would be useful to anyone but me, and I wouldn't care if any of it was stolen. I've had a probably stupid idea, and I'd like some help evaluating HOW stupid, and what I can do to make it slightly less stupid.

I'd like to add a table to my DB to store all my passwords, and add functionality to my website which would allow me to read and write to that table. The obvious and very valid objections to this are: "the personal website of an amateur is probably not at all secure and very hackable. If someone gets access, they'll be able to steal everything." I can think of a few ways to make this bad result less likely. Here's how I'm picturing it working:

  1. Log in to my admin account on my website.
  2. Make a request to get my passwords. Before the request goes out, I have to pass two-factor authentication.
  3. The passwords are encrypted in the db and still encrypted when they are received on the client-side. I store the key completely separate from the website/DB.

Is the above design secure enough to make this a reasonable thing to do? If not, is there something else I could do to improve it?

PS: I am aware that there are password management services available. Please indulge my desire to 'do it myself'

  • With regard to #3, after you receive the encrypted password on the client side, how would the encrypted password be decrypted on the client side? Can you please elaborate on this step?
    – mti2935
    Mar 20, 2022 at 23:34
  • @mti2935 That's a good question. I was thinking I would do it by finding some trustworthy 3rd party encryption/decryption tool to use offline (manually). The goal being for the website to never have contact with unencrypted passwords or the key. Definitely inconvenient the more I think about it, but this isn't something I would use frequently. And again, I know very little about security so my ideas may be wrong.
    – 12345
    Mar 21, 2022 at 1:04
  • 1
    That makes sense. So, the plaintext never reaches your server, only ciphertext reaches your server. In that case, you could simply use openssl (or any number of other tools) to encrypt/decrypt the files client-side (see stackoverflow.com/questions/16056135/…), and upload the ciphertext to your server for it to store/retrieve. Or, you could store/retrieve the encrypted ciphertext using a site like pastebin.
    – mti2935
    Mar 21, 2022 at 1:24
  • @mti2935 thanks for the suggestions! That is definitely more convenient than what I was imagining.
    – 12345
    Mar 21, 2022 at 1:35

3 Answers 3


First off:

  • make sure your database is not vulnerable to injection
  • make sure your admin password is not bruteforceable and the authentication is not bypass-able (by session forging or similar)
  • Make sure your database cannot be accessed without auth, because if you just keep it as a wget-able endpoint ... that's just making it easy to dump
  • obligatory reminder to check for the OWASP top 10

If the passwords are stored encrypted, the website is not your weakest link, but it seems quite inconvenient to have to enter in your passwords in encrypted form and also have to decrypt them. At that point, why store them in your website at all (I presume the purpose of storing them there is accessibility, however keeping them encrypted defeats the purpose so you may benefit from reconsidering this endeavor altogether)

To answer your question: if a secure (at the very least, make sure it isn't in rockyou.txt) master key stays unconnected to your website, your only risk is the database being dumped with hashes cracked offline (which is doable, so make sure you use strong enough encryption - AES-256 should work for your purposes). This also applies for MiTM attacks and other sniffing, but quite honestly your risk is low here (doesn't mean you shouldn't follow best practices though).

In conclusion, given the way you implemented your website, the UX seems awkward and the project rather pointless, however it's secure enough, given your protection measures are properly implemented.

  • 1
    Thank you, I appreciate the list of vulnerabilities to consider. Most of them I didn't know about, so I'll be careful if I end up doing this. You're right it's inconvenient. I was thinking of this as a rarely-used backup, so spending 5 minutes retrieving and decrypting wouldn't be too awful. I can just remember the passwords I have use every day. I'll wait a few days before accepting this answer
    – 12345
    Mar 21, 2022 at 1:24
  • If you're looking for a password backup, just store them offline in a file (json, txt, doesn't really matter) and symmetrically encrypted with a strong key. Exposing a database to the web is wholly unnecessary
    – belkarx
    Mar 21, 2022 at 3:33

Not very experienced in security, but it's one of my hobbies and I try to learn as much as possible.

Some thoughts:

  • Assume your database is going to be copied. It's not a question of if but a question of when. Make sure it's really hard to get useful info from the DB without the proper secrets.

  • If at all possible, don't store your secrets in the server having the web / database. They will be stolen too.

  • The secrets could be encrypted with a key derived from the client's password. Without this password, you can neither decrypt the secrets nor the database.

  • As I've recently been made aware of, most password leaks are not by breaking but by user's fault: phishing, etc.

  • Don't go crazy on encryption, see xkcd: Security


They key point is how you are encrypting the database. If you are saving emails there, an attacker can deduce the contents of an encrypted field if you are using the wrong operation mode (like AES-ECB).

You don't even need to store the key anywhere. You can use a random symmetric key, encrypt the data with it, and use an asymmetric key to encrypt the symmetric one. Use a KDF (such as PBKDF2 or Argon2) to generate the key, so you don't need to store it anywhere. If you need to change the master password, you only have to re-encrypt the symmetric key. Use AES-GCM, AES-CTR or AES-CBC and you are good to go.

Encrypt everything client-side, so no plaintext data gets transmitter, even on TLS. If an attacker manages to compromise your site, he could dump the data if there's any plaintext data there. Encrypting and decrypting client-side is safer.

With those two things you don't need admin passwords, or TOTP, not even keep the database private. An encrypted database consisting of AES-GCM-256 encrypted data is pretty much unbeatable without the password.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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