Store password in database

Asked

Viewed 901 times

5

I have an application that needs to store passwords and get them again, this is not just for login check because the stored passwords will be used to provide access to another system (there is no access token for that system). A hash function is clearly inappropriate for this and the database used (Mongodb) does not provide support for encrypting/decrypting documents in the database.

Is it a good alternative to use symmetric keys to make this encryption? In this case, you would only have the availability of a single server and how could you safely store the key on that same server? Should I expose in the production environment the algorithm (source code) that performs this encryption/decryption or it is safer to just generate the "binary" and send the entries?

  • 1

    Will passwords be used with or without user intervention? The question was a little open, if you can [Edit] and give more detail of what will be the data flow between applications, maybe it will help.

  • No intervention. The system is a bot that the user will login only once and the bot will use the user password to access another system.

  • Good afternoon! @Daniela Morais, password in a section for reuse by bot? Passwords are usually encrypted on a one-way street, otherwise what is the need to encrypt? See if you can save the logged in user pass in a section!

  • 1

    When a password to be stored does not give access to the system itself, but to third-party systems, it is commonly called "secret" and not "password". Keeping secrets safe is a common problem, but unfortunately I don’t know any simple and/or generic solution for this. About your last paragraph, it’s no use to hide the encryption algorithm, so don’t worry about it, you can leave the algorithm in the production environment. But how to hold the key safely, unfortunately I do not know answer.

1 answer

4


The normal in these cases is that the secret configuration is a token - which will be used as a symmetric password for DB - which will be available in a file or in a server environment variable.

Of course this token should never be part of a versioned file - at least not along with the source code.

If you look at all the existing deploy automation systems - Chef, Salt, Puppet and even Docker - they all have a way for you to pass via command line settings that will be available on the Deployed systems but are not part of the repository - this information can be environment variables, or something else.

In your case, it seems to be a small deploy, which will not be automated - the best thing to do is to log into the server and manually generate the token in a file that will not be versioned - create a small script for this. Anyone who has access to your server will have access to this token - normal Unix file permissions can give some extra protection if the server is shared - but practices are in favor of using VPS and assuming that anyone who has access to the server can see these tokens (and you isolate the server with restricted IP login only, private key, etc).

Above is what is cool to know and regardless of whether the system is in Python or not. Now something specific about Python: a package that I like to use that gives good flexibility to settings of this type, allowing ease in development and security environments in the Deployed environment is the prettyconf (The author is Osvaldo Santana who was once president of the Pythonbrasil association). It’s a simple package, but it allows your system at runtime to try to recover a value from an environment variable - and if it’s not available, take by default from a configuration file)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.