3

I have an web service in which I have to save the user password so I can interact with other website later, I need the most secure way to store this password and still be able to recover its original form when needed. I know that as I need to recover its original form there aren't many options, but I need the best one.

I REALLY need the password in the original state, because my web service later access an website that is not mine, and I have to input the raw password to it

Eduardo Amaral
  • 109
  • 2
  • 12
  • Who needs to read the stored password? – Martin Dec 06 '18 at 10:52
  • Are you using PHP? If you are, [this question/answers](https://stackoverflow.com/questions/43833858/mysql-encryption-storing-sensitive-data/43834031#43834031) may be helpful to you. – Martin Dec 06 '18 at 10:57
  • [Possible duplicate Q&A](https://stackoverflow.com/questions/9262109/simplest-two-way-encryption-using-php) ; nod to [Tim Biegeleisen](https://stackoverflow.com/questions/53075970/how-to-store-passwords-safely-to-use-later#comment93050149_53076003) – Martin Dec 06 '18 at 11:02

3 Answers3

1

If I understand correctly your question, so you have just a single pair or few pairs of users/passwords that you want to save as a part of the configuration of your web service.

From my experience on a number of projects, and some of them for institutional clients who really care about the security, the solution, from a developer point of view, is simple:

  • Save the password in a configuration file as an open text

Now you may ask: "Where the heck is the security?" The answer to a software developer is "None of your business". It will be a business of the system administrator who is setting up the application on the production server. This administrator will make sure that:

  • the file contains correct users/passwords required to connect to the production systems that possibly contain sensitive data
  • the file is accessible only locally and only to the user under that runs the web service
  • the file is saved on an encrypted disk so that it will not be readable by someone else if he unplugs the disk and connects it to a different system

(well, I've never worked as such an administrator so I may have omitted something...)

An example of configuration files setup in a particular project that I worked at:

  • In SVN there is a config.properties that contains users/passwords for a testing environment that does not hold any sensitive data, so we don't care that any user of the repository can read these passwords
  • Before loading the config.properties the system looks whether there is present a file called config.properties.local and loads that one instead of the config.properties if present. This local file is ignored by the SVN and not committed.
  • So with this config.properties.local, the developer can override the users/passwords from the config.properties with his values in the development environment and in the same way the administrator deploying the app uses this config.properties.local to provide the production users/passwords and ensure the security of the file as described above.

EDIT: Eventually in fact, above I advised saving into a plain text file protected by appropriate access rights and filesystem encryption.

While what this is still a common solution that I often see when installing applications, so probably you should try to use a support that is built-in into the operating system for this purpose.

For example in Ubuntu, that I use, there is Gnome Keyring. Kind of a password manager that can safely store encrypted passwords and decrypt them when needed again by an application. It is unlocked automatically when the user logs in, so it is convenient to use. GUI is called Seahorse (preinstalled in Ubuntu). For CLI install apt package libsecret-tools (utility secret-tool) or search for an API for your programming language.

David L.
  • 3,149
  • 2
  • 26
  • 28
  • I agree with your points +1. I will note that in general it is bad practice to store passwords encrypted in a reversible way, assuming they do not need to ever be used as clear text. If this _must_ be done, then your suggestions have merit – Tim Biegeleisen Dec 06 '18 at 11:47
0

There is no bullet-proof way to solve this problem, the client finally needs access to the server, and so can do an attacker with enough privileges on the client. What you describe is a typical scenario for the OAuth2 protocol, but from your comments I get, that this is not an option.

  1. If your own service demands a login on its own, then you could derrive a key from the user password, to encrypt the foreign password. This key can then be kept in a session, for later usage.
  2. Even if the user does not login to your service, you could request a password just to decrypt the foreign password.
  3. Another option is, to ask for a password when your webservice is starting up. It can be kept in memory as long as the service runs, so you don't have to store the foreign password in the database.
martinstoeckli
  • 23,430
  • 6
  • 56
  • 87
-1

Don't use a salt, use some technique like PHP has, password_hash()

Fabb
  • 21
  • 5