How do you store a username/password securely in a rails app when using it for many ldap searches?

The connection in the app requires

ldap_bind_authenticate(Net::LDAP.new, username, password)

each time a search is made, and the credentials of the user are not stored at logon. I often see developers using a test user for the searches and storing a plaintext username/password pair in the user.rb model. Is there a more secure way to do this?

  • I've heard of people storing the hashed and salted creds in an environment variable on the machine, but I'm not sure if this is any better.
    – essefbx
    Mar 25, 2015 at 13:36
  • 1
    How would the hashed creds help? This is the client to the ldap. The LDAP server wouldn't accept a hashed password. It take the password and hashes it. If you give it a hashed password, it will hash it again.
    – user93353
    May 24, 2015 at 17:29
  • Yeah you're right - right now I'm decided on storing the creds in a conf file with locked down permissions
    – essefbx
    May 24, 2015 at 17:43
  • Environment variables are generally the way to go. Config files are too easy to accidentally (or worse, intentionally) commit to your repository, which is never a good idea. Oct 21, 2015 at 19:48

1 Answer 1


Disclaimer: I have never used ruby / ruby on rails and in this answer I describe how I would act in general.

You have two ways to solve this problem:

  1. Use an additional user for all your searches.

    • Pro: You don't have to store the users credentials after he/she logged in.
    • Con: I don't know if this matters in your application but you can't track which user has started a caused the query based on your LDAP logs.
    • Implementation: Your have to store sensitive credentials for an external service inside your application. This is the exact same problem as with database credentials so I think you should store your LDAP credentials in the same manner as them.
  2. Use the logged in user for searches

    • Pro: You can track what every user has done using your LDAP logs
    • Con: You have to store the unencrypted user information somewhere while the user is logged in.
    • Implementation: Save the unencrypted user information in the session or something so you can access them when you need to.

Personally I would prefer the first solution as it does not involve storing a lot of plaintext user passwords somewhere.

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.