Encrypting passwords for api help

[AVmcclint]

I'd really love to use my newly learned API knowledge in scripts that would be immensely helpful. The main use would be for a policy to run a script that collects all kinds of various system information and saves that info in various text files and then those zip files are zipped up into a single .zip file. I got that part figured out. The part that's tripping me up is how to use the fileuploads in script form. If I run the following command manually in terminal, it works fine. 

curl -sku USERNAME:PASSWORD https://jss.company.com/JSSResource/fileuploads/computers/id/100 -X POST -F name=@/PATH/TO/FILE

The problem is that in order to run this in a script, I have to input the username and password - a huge no-no. I figure there's gotta be a way to encrypt the password for the script.  I've found lots of articles that explain how to run commands on my local admin Mac to create the encrypted PW. The problem is once I have that info, then what?  If my apiuser's PW was Password01, there's no way I could run Password01 through the encryption to get 3h5gtv3k4htviue4gv and then use "3h5gtv3k4htviue4gv" in the password portion of the command because that obviously is not the password.   How do I tell the server to accept this encrypted password?

Or is there another way of running api commands in scripts?

[cpresnall]

We do this using Salt Hash. https://auth0.com/blog/adding-salt-to-hashing-a-better-way-to-store-passwords/ gives a good rundown of this.

[AVmcclint]

While that article does give a nice explanation of what salting does, I don't see where it tells you how to USE the salted hash that you create. 

[cpresnall]

You need to supply the local salt, and local key in the script, then pass the hashed value as a variable from the JSS. 

hashed_jss_value="$4"

function DECRYPT_STRING
{
# Usage: DECRYPT_STRING "Encrypted String"
local SALT=<your salt>
local K=<your key>
protected_val=$(echo "${1}" | /usr/bin/openssl enc -aes256 -d -a -A -S "$SALT" -k "$K")
}

call the function with DECRYPT_STRING "$hashed_jss_value"

this example lets you pass the resulting password as ${protected_val}, but you can do the same with a second function if you need to pass the user name as well.

[Tribruin]

Just a fair warning. This method is really not much more secure than putting the credentials (or B64 encoding) in the script. While you are obfuscating the password, all the data necessary to decrypt your password is in the script (and the hash value is passed in the arguments, which can be easily scrapped)

My analogy:

Plain text user name & password = Front door key left in lock

B64 encoded username, password = key is laying on the ground in front of the door

Salted/Hashed password (with salt, hash, and function in script) = Key is under that welcome mat with a big sign on the door "Don't look under the mat" 

I can't say don't use API calls in scripts (but other will.) But make sure you are restricting the API credentials to the absolute minimum permission they need. 

[AVmcclint]

That’s exactly how I was thinking about it.  So if even hashing the passwords is still inherently insecure, are we supposed to never run api calls from scripts? If that’s the case then what’s the point of having api calls - especially the fileuploads where we can collect files from the computers?

[anuj530]

you can jusr jamf script parameters as long as you're not concerned about having exposed credentials in your jamf portal. 

[anuj530]

use* 

[sdamiano]

https://developer.jamf.com/jamf-pro/docs/classic-api-authentication-changes

You can try these new tokens? 

[anuj530]

Yeah, but even to get the tokens, He would need to pass the credentials somewhere. We run some policies that make the API call to GitHub action, and then the GitHub action makes the Jamf API call. We pass GitHub token through jamf script parameters. 

[petersonjdARPAH]

Since you're using GitHub Actions, put the credentials in GitHub Secrets.