13

I have a Bash script that automatically authenticates with a service using my username and password. The credentials are currently stored as plain text within the script.

What precautions should I take to most securely store these credentials while still allowing the script access?

Points of clarification:

  • I understand that, if available, other methods of authentication should be used instead. I still want to know what to do in the case that password authentication is the only option.
  • Not storing the password at all is not an acceptable answer here. I am asking about the case in which the script must have unattended access to the password.
5
  • 2
    not store the passcode part of the credentials, perhaps?
    – Thomas Ward
    Jul 7, 2011 at 19:04
  • Wouldn't it work to access GNOME Keyring or something similar? Jul 14, 2011 at 21:12
  • Perhaps if you could store it as a cryptographic hash (such as SHA-1), that would be nice.
    – Anonymous
    Oct 25, 2011 at 17:03
  • ROT13 would obscure it, but would NOT secure it in any way.
    – Anonymous
    Oct 25, 2011 at 17:04
  • @Anonymous If the password is stored as a cryptographic hash, how do you recommend retrieving it?
    – ændrük
    Oct 25, 2011 at 17:07

3 Answers 3

14

Instead of hardcoding the password in the file, store the password in a separate file and protect the file (chmod 700 or chmod 500) so that only the authorised users can access it.

Retrieve the password with cat /dir/to/file/with/.password instead of reading the file and storing the content of it into a variable.

3
  • Some tools even have an option to read the password from a file directly for precisely this reason, such as gpg's --passphrase-file option.
    – user21322
    Jul 13, 2011 at 6:36
  • 2
    ...and make it a .dotfile (/dir/to/file/with/.password)
    – knb
    Oct 25, 2011 at 17:16
  • 2
    chmod 400 for files (read-only). Of course, you have to secure the leading directories (700 or 500, or even 100 if you are paranoid). Note that 400 (or 500 for directories) is sufficient, other modes (100) can be considered as security through obscurity, just like hiding the file by putting a dot in front of the name.
    – Lekensteyn
    Feb 13, 2013 at 20:49
8

What kind of service? Certain services have other methods to authenticate, e.g. SSH keys for SSH in conjunction with SSH agent.

I'd store the password separate from the script, and make sure that all path components have the correct permissions set. E.g., make sure that in the path /path/to/file, /, /path and /path/to are owned by a user you trust (root) and that these are not writable by someone who is not allowed to see your files. Finally, the recommended permissions for file is 600 or 400.

That file could look like this:

PASSWORD='something that you cannot remember'

In your script, use the below code to import the variable:

. /path/to/file

As for your script, make sure that it does not contain holes which may allow attackers to execute code in the script context (e.g. uncontrolled environment which may have an arbitrary $PATH variable set or invalid use of other files (e.g. sourcing a world-writable file).

As for the actual protection of your password, you can't. It must be available somehow to the other service. As an alternative, you can encrypt the file/ script containing the password using openssl or gpg so you need to enter a password before the credentials are unlocked. This is especially useful if your service's password is hard to remember.

1

I know this is an old question but i faced this similar issue and i used Ubuntu's key ring to solve it. Here is a solution on ubuntu 18.04LTS Open the terminal Write down keyring set {{service}} {{username}} for example if you are using this for school password logging:

keyring set school mohamed

It will log you for a password enter the password. Now the password you entered is stored in Ubuntu keyring.

To get this password write in the terminal:

keyring get school mohamed

to use this in the context of an script:

password=$(keyring get school mohamed)

Now the password contatins the password you previously entered.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .