After reviewing a few documents, I'm hearing that doing this is not a best practice.... If I choose to do so, does anyone know where those credentials are saved and how they are saved in the agent on the endpoint?
I'm guessing encrypted cookies are the way to get around this with longer validity times?
Solved! Go to Solution.
I can only guess about the actual implementation so I assume everything is done correctly. We have two different methods: authentication cookie and safed credentials. Both methods store something encrypted on the client computer but only with the cookie you have control over the encryption key as you can choose an encryption certificate and this key is stored on the firewall. For encrypting the username and password a key is required too but about this key we know almost nothing (at least me). The only thing I know is that this encryption key is somehow available on the client computer as GP needs to decrypt username/password in order to send it in cleartext (over an encrypted connection) to the portal and gateway. Both of these encrypted blobs in theorie can be stolen from a device and used by an attacker to connect but if the attacker is able to decrypt the username and password he is able to do (in the case of domain credentials or credentials in general that are not only used for the vpn connection) even more when connected where this isn't possible with the cookie (even the decryption isn't possible as long as the attacker does not have already compromised your firewall).
--> So giving these facts my opinion is, it is more secure to use the authentication cookie instead of saving username/password on the device.
theyy are saved and encrypted on the device under current user reg settings.
HKEY_CURRENT_USER\Software\Palo Alto Networks\GlobalProtect\Settings\LatestCP
Mac stuff is stored in local keychain.
we do not class username and password as an acceptable auth method, so not an issue or concern for us.
It must be a security concern if Palo is suggesting that this is not a best practice I'm guessing? But the encrypted cookie is a better "workaround" of sorts from saving the user from login prompts?
I only ask because if it was a VPN access concern then why would they not suggest the same for SSO and certificate authentication as once you are logged into the device then access is available without adding further credentials.
or.. do they feel that they have not encrypted securely enough.....
i'm also wondering if this is more directed at OTP authentication as using the stored credentials would cause the gateway auth to fail every time.
best practices assessment tool is where I saw it. You may be correct on this, as the reference for cookie auth does directly mention OTP.
I wonder what the encryption settings are for storing the username/password, or if that is propietary? I'm not sure I've read anything regarding this however. Any further detail on how this is stored/secured on the endpoint?
Bumping this post- to see if anyone else responds. Are there benefits to using an ecrypted cookie, vs. flatout saving the credentials? If not, how does the agent save the user credentials on the machine itself? -I believe we've determined that if "save users credentials" is on- the users credentials are encrypted on the local machine in the registery, but how are they encrypted, and is that any better/or safter than using the encrypted cookie for auth bypass?
I noticed there was just a warning out -Vulnerability Note VU#192371- about GP and other agents storing cookies insecurely, but i'm guessing if your using an encrypted cert for auth bypass- this shouldn't matter?
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!