Password Reuse testing

[Serhii_Yaholnyt]

I need to test #password_reuse function on SandBlast Agent for browser, but I can not find enough information about it. My client computer is in AD domain, I've  entered into my internal RDWeb Access page with AD credentials few times to make my Agent store my password, but I still can use it anywhere in internet without alerting or logging. What makes SBA for browser record my internal password and in what situation it would alert/log? (Policy is configured correctly and SandBlast Agent for browser is installed automaticaly after installing SandBlast Agent dwonloaded from SmartEndpoint Server -> Packages For Export.)

[PhoneBoy]

Have you configured Protected Domains by chance?

Credentials entered in these sites on a web browser are the ones that are tracked.

Refer to: R77.30.03 Endpoint Security Administration Guide 

[Serhii_Yaholnyt]

Yes, my Domain is in Protected Domains list in Zero Phishing settings.

[Ziv_Sahar]

Hi Serhii,
please find bellow the information about the Password Reuse functionality and use:

The basic flow of the “Password Reuse” feature is as follows:

1. The admin defines the protected corporate domains in SBA4B policy.
2. A user submits his/her credentials in a form that belongs to one of the protected domains.
3. The password hash will be taken (sha256, hmac) and saved in local browser storage
4. Once the user will use the same password in a non-protected domain, the system will trigger according to configuration (log, usercheck)
   
   It is importent to note point#2 - the user must enter his credentials of the protected domain after the domain was add to the protected domains, and the configuration was synced to the extension.
   there is no integration with AD, so the extension "learns" the password it needs to protect once the user type them in the a protected domain web site

[Serhii_Yaholnyt]

Hi, Ziv
I have configured SBA4B policy, added my domain to pretected domains list, made my computer a domain member and after that installed CheckPoint SBA4B on my machine (with installer which was downloaded from SmartEndpoint Server). Is it possible that SBA4B does not recognize site as protected domain's one if there is an error with certificate or if I address it with IP in URL string?

Thank You for answering.

[Ziv_Sahar]

Hi,
The extension domain need an exact domain match according to the protected domain list,
if you will use IP instead of the domain name the password reuse will not be triggered.

[Olga_Kuts]

Hi, Ziv!

Tell me, please, if we clear browser cache - will SandBlast Extension recognize the domain password, or we need to re-enter it on the domain site again?

[PhoneBoy]

Pretty sure the answer to this is no as it wouldn't make sense to use the browser cache for this (which may not cache the password anyway).

[Ziv_Sahar]

Hi Olga,

clearing the browser cache won't delete the extension data, so the extension will still recognize the domain passwords

[Tobias_Karsbo]

Hi.

Anyone who knows how to "exclude" domain. For example. The user have the same password in the local domain and in "portal.office.com" (Office 365 login portal)
That is because the local AD syncs credentials with MS 365.

So they have to use the same credentials on local domain and MS 365.
So when the user tries to logon to Office 365 portal, they get the message saying they are using corporate password... and they have to do that....

So if anyone know a way to exclude some domain (white list) it would be good..

Thanks, Tobias

[Tobias_Karsbo]

Hi again. 

My misunderstanding.

Just add those domains in "Protected Domains" and it will work just fine

[John_Fenoughty]

I was looking for something related to this and tripped over this thread.

Just in case anyone else looking to make the password re-use protection feature work properly for Office 365 - as in making Office 365 authentication be the 'trusted' side for the corporate credentials - either synchronised with the on premises AD or stand-alone - it doesn't really matter which, trusted is trusted

The portal.office.com FQDN redirects to the basic 'office.com' so doesn't really play a key part.

The domains that you need to put in to the 'trusted domains section of the 'Zero Phishing Settings' 'protected domains' list are:

login.microsoftonline.com

office.com

Very possibly portal.office.com (I don't believe so but just in case, and it'll do no harm to add it)

Just today I did a step by step test on a new implementation and tried just using login.microsoftonline.com; this was *not* sufficient for the zero phishing to hash the password, even though it redirects to that FQDN prior the the user typing in the login name and password - office.com is essential too!

Funny old thing Microsoft authentication - but add these two to the protected domains and it works a treat! Everyone who sees this for the first time is impressed, just try logging on to any other site with the same credentials after logging in (on a browser) and when the new browser tab opens with the warning about how this is not a secure practice there is always a gasp from the person watching!

Lovely piece of technology, nice work Check Point!