6

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?

essefbx
  • 172
  • 12
  • 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 '15 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 '15 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 '15 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. – Stephen Touset Oct 21 '15 at 19:48

1 Answers1

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.

Martin
  • 535
  • 3
  • 11