- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
04-11-2019 07:16 AM
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?
04-12-2019 11:34 AM
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.
04-11-2019 07:32 AM - edited 04-11-2019 07:37 AM
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.
04-11-2019 07:40 AM
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?
04-11-2019 07:51 AM
@Sec101 , Hi.
where have you seen this suggestion. i have browsed the gen help files and can't see such advice.
04-11-2019 07:56 AM
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.
04-11-2019 08:00 AM - edited 04-11-2019 08:07 AM
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?
04-11-2019 08:17 AM
well this is what it looks like... so i assume this is not a ceaser cypher...
䱎䵌塮桹奔灮灊睷㕯汄㈫歱㑬婒佈偗浵ㅇ䑌䑉䝰㴴
04-11-2019 08:19 AM
ha. Nice. I wonder what it is? Probably too picky, but am curious on it now....
04-11-2019 08:24 AM - edited 04-11-2019 08:26 AM
well it's almost lunchtime over at washington DC so somebody will jump in with the answer, I know who it will be, but lets see,,,,,
04-12-2019 06:45 AM
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?
04-12-2019 11:34 AM
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.
04-12-2019 12:29 PM
That was the answer i was looking for. WOW. Thank you very very much!
12-05-2019 03:32 PM - edited 12-05-2019 03:41 PM
Not sure if this will add to what you already know..
GlobalProtect does not store the credentials in the Registry, this may have been how it worked historically, but It changed sometime prior to v4.1.11, and several TAC engineers I've spoken with also thought this - But I know from experience this is not the case, after working on an AD Domain migration project, which required us to clear stored credentials on all endpoints as part of the migration process, we followed all the advise given from PA (and I spend hours on remote-sessions with TAC), but still, stored credentials remained!
In the end, I identified they were being stored in the Windows Credential Manager, stored under "gpcp/LatestCP", they did eventually confirm this, and I'm surprised this is still not commonly known. If you cannot see it using Control Panel->User->Credentials Manager, run the legacy Key and Credentials Manager from the CMD - rundll32.exe keymgr.dll, KRShowKeyMgr
12-06-2019 12:08 PM
running this cmd -
rundll32.exe keymgr.dll, KRShowKeyMgr
I do not show mine stored, however, I'm not saving credentials either - only username.
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!