JSS API Authentication with Hashed Password?

[seansb]

Hey all,

Quick question - does anyone know if you can authenticate to the JSS api using a hashed password via curl? If so - how is it done? Just wanted to be a bit more secure especially if the account has the ability to modify records.

Thanks!

[rderewianko]

I don't know of a way to hash it for the api. I know you can encode it... but this is reversible.
In Bash using curl you can do the following to encode it in base64:

eg: ```

!/bin/sh

response=$(curl -X "GET" "Https://jss.domain.com:8443/JSSResource/advancedcomputersearches/id/43" -H "Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ= -H "Accept: application/json")

where: dXNlcm5hbWU6cGFzc3dvcmQ= when unencoded would equal: username:password


The other option is to only store the creds in the casper database and call them through parameters (then the user never has access to this data) it is stored in clear text in the mysql database mind you:
EG:

CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 5 AND, IF SO, ASSIGN TO "apiuser"

if [ "$5" != "" ] && [ "$apiuser" == "" ]; then apiuser=$5
fi

CHECK TO SEE IF A VALUE WAS PASSED IN PARAMETER 6 AND, IF SO, ASSIGN TO "apipass"

if [ "$6" != "" ] && [ "$apipass" == "" ]; then apipass=$6
fi

find out the url of the JSS!

jss=defaults read /Library/Preferences/com.jamfsoftware.jamf.plist jss_url
echo "jss is $jss"
response=$(curl "$jss"JSSResource/users/name/"$username" --user "$apiuser:$apipass")
```

[BrysonTyrrell]

@seansb Jason Van Zanten and I worked up something for that. I put it up on Github:

https://github.com/brysontyrrell/EncryptedStrings

Using an OpenSSL command we can create an encrypted string (usernames and passwords to API accounts we use in our scripts) that is decrypted when the script runs using a unique salt and passphrase.

The only way to get the passwords we use is to have access to the encrypted string in the policy and the salt/pasphrase values in the script.

In the repo is the function for getting the string and the values and the function to put into the script to decrypt it.

[seansb]

@brysontyrrell][/url - Thanks for your response.

I'm not entirely understanding this useage. So it sounds to me like you set up a policy in the JSS with a custom trigger that maybe executes a command that echos out the encrypted string (I've set it up this way). From there you can use the hash, passphrase and encrypted string to decrypt the username / password for the API.

But what my question is, how do I make a GET / POST / etc. Request to to the API with the script using encrypted information. I'd prefer my API credentials not sent in the clear during the curl request. In the above workflow, it seems like we would be successfully hiding the username / password from anyone reviewing the script, which is good. Also - not all the components are in the script to decrypt - which is also good (as you mentioned). However, if you're decrypting the password and sending it to the JSS API via curl, you're now sending your username / password over the wire essentially cleartext. What I'm looking to do is send an encrypted username / password to the JSS via the curl command so I'm not sending the username / password cleartext.

Please let me know if I'm misunderstanding or if some aspect of the sending in cleartext is wrong.

[vao]

bump @brysontyrrell

[sggr57a]

I'm looking to use encrypted values to avoid our campus passwords getting leaked. Is there any reason one couldn't use parameters $4, $5, $6 for the encrypted string, salt and passphrase so that it's all obscured from the user? Did I misunderstand how this script can be used?

[BrysonTyrrell]

What I'm looking to do is send an encrypted username / password to the JSS via the curl command so I'm not sending the username / password cleartext. Please let me know if I'm misunderstanding or if some aspect of the sending in cleartext is wrong.

@seansb - That's not currently possible. You need to provide the username and password using HTTP basic auth. The purpose behind the encrypted parameters is provide further obfuscation of the credentials. You need access to both the policy and the script to decrypt the values. However, that decryption MUST happen client-side for your API script to be able to pass the credentials in the request. Jamf Pro has no mechanism for accepting encrypted payloads/headers.

Is there any reason one couldn't use parameters $4, $5, $6 for the encrypted string, salt and passphrase so that it's all obscured from the user? Did I misunderstand how this script can be used?

@sggr57a - You could do that too. In my case, while I was the Casper Admin, Jamf staff had access to viewing policies so I opted to split the pieces up between the policy parameters and the script (which staff did not have access to view). Nothing prevents you from adapting this to have all values passed as parameters.