Password in Repository on Cloud Service

I recently signed up for a cloud hosting service that allows for one click application setup and updates using GIT. I created a WordPress application and pulled the co开发者_C百科de, only to realize that they used my account password as the database password (i.e. the password I used when registering for the service).

This was a bit unnerving. If I ever had my laptop stolen, or accessed without my knowing someone could easily destroy all the apps that I host using the service. When I asked the host about it, they claimed to use AES encryption (as opposed to password salts) and that the connection to the repositories is protected.

Is this a bad design? Is it reasonable never to store passwords in a GIT repo and to enforce salting on passwords? My only other experience is with Heroku where passwords are not included in config files (and my password has never shown up as plain text). Thanks!

I'd like to say that they shouldn't store passwords in a format that can be decrypted at all, instead prefering hashed and salted.

However, the problem here is that they need to access the GIT repository on your behalf. Which means the password has to be decrypted by their servers at the time of use in order to pass it on to the other system.

In reality due to these requirements there is no real way to completely protect it. Sure it's encrypted, however, that decryption key is available to someone that hacks the machine.

It really doesn't matter if you use different passwords or the same one. If their site is hacked then the passwords can be exposed.

So, the real question isn't how are they encrypting it (doesn't really matter). The real question is how are they monitoring the site in general to ensure it hasn't been hacked. This boils down to whether they are using an IDS/IPS (Intrusion Detection/Protection System). If they aren't, then move on to a different provider that is using one.

Ahh, the old "Don't worry, we use AES!" defense. If I understand your statement correctly, it would seem that they're storing their users' passwords unhashed in a single file then encrypting that file with AES. If so, then yes that's bad design generally. The standard method is of course storing hashed and salted passwords in an unencrypted file.

Storing passwords in an encrypted file suffers from a number of problems:

1) What is the password to the encrypted file? For "turtles-all-the-way-down" reasons, you can't encrypt that password. It can be stolen / guessed.

2) You have the standard password problem on the encrypted file. Do you make it low entropy and memorize it? Do you make it high entropy and store it on a disk somewhere. Both have obvious issues, and remember that this key is a single point of failure for the whole system.

3) Anytime their system needs to verify a password, it has to decrypt the file. So in all likelihood, both the file's encryption key and all the file's passwords will be loaded into memory on the server in plaintext.

As for the "They use my one password for both my overall account and my database access" problem, that's more debatable I think. On one hand you might want to limit how much access any one password gets you. But on the other, having to make a different password for every little thing leads to bad password creation and password reuse.