# Password Protecting Rails Configuration Passwords

**URL:** <https://www.ruby-forum.com/t/password-protecting-rails-configuration-passwords/87460>\
**Category:** Rails\
**Created:** [March 2, 2007, 6:43pm UTC](https://www.ruby-forum.com/t/password-protecting-rails-configuration-passwords/87460 "2007-03-02T18:43:10Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![ara-vartanian](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/a/b38774/32.png) [@ara-vartanian](https://www.ruby-forum.com/u/ara-vartanian)\
**Post date:** [March 2, 2007, 6:43pm UTC](https://www.ruby-forum.com/t/password-protecting-rails-configuration-passwords/87460/1 "2007-03-02T18:43:10Z")

</div>

There is about a year-old thread on the list on the topic of password  
protecting the Rails database password (typically stored in the clear in  
database.yml). A lot of people dismissed the idea, since any key to  
decrypting the password would have to be stored on the same box.

I was wondering what people thoughts were on the  
feasibility/desirability of passing argument to Capistrano deployment  
tasks that would pass the decrypting key along to the application.

In many applications, the database password may not be the only  
sensitive password on the box. After all, web servers might need to  
interact with all kinds of different systems, each system requiring its  
own authentication credentials. So even if you don’t think that the  
MySQL password is all that sensitive, there is still the general issue  
of leaving sensitive configuration details in plaintext (and embedded in  
the code) on the server.

Any thoughts, help, comments would be appreciated.