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.
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.
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.
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.
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.
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.
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?
you can jusr jamf script parameters as long as you're not concerned about having exposed credentials in your jamf portal.
you can jusr jamf script parameters as long as you're not concerned about having exposed credentials in your jamf portal.
use*
https://developer.jamf.com/jamf-pro/docs/classic-api-authentication-changes
You can try these new tokens?
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.
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.
Since you're using GitHub Actions, put the credentials in GitHub Secrets.
