Jump to content
parrishk

Could not check 'Have I Been Pwned' API at this time

Recommended Posts

Good morning,

 

It seems that the "Confirm Have I Been Pwned Status" button is not successfully hitting the API (image below).

This is allowing weak/compromised passwords to be saved...

 

I do not believe it is an API rate limit issue as I am able to run a report on compromised passwords fine, I just can't use the button on the password page.

 

Any tips on troubleshooting? I have checked the error console but nothing is listed there.

 

Thank you!

image.thumb.png.b0dbac6afca568b5b2c82bb74b94db32.png

Share this post


Link to post
Share on other sites

Hello,

 

I've just checked this icon, and it is currently working for us. Can you let us know what build of Passwordstate you are using, and is this issue reproducible every time - possibly there was any issue with their API when you were testing.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hello,

 

Build is 8679.

 

So far, this has occured every time since we updated to the version that supports this feature.

I can run a report within Passwordstate to check against the API and that works fine.

I can also query the API directly (outside of Passwordstate) without issue.

 

Thank you.

Share this post


Link to post
Share on other sites

Hi PArrishK,

 

I still can't seem to reproduce this on a couple of different environment.  Build 8679 here as well.  Do you have any special characters in the password?  Maybe this is breaking our call to the API somehow.  You are welcome to email that through to us if you'd like is to test this.

 

Can you try this password, as this is working for me:  VT2ycjifLwZWr%_e

 

Regards,

Support

Share this post


Link to post
Share on other sites

I have the same problem on a fresh install 8679 right now.

Works on our other Passwordstate install on 8573

 

No HaveIbeenPwned integration i passwordstate 8679 is working for me right now.

 

I have checked the firewall for blocks but it is not even trying to connect according to the session data in the firewall.

 

 

Share this post


Link to post
Share on other sites

Hi Guys,

 

Can you tell is the following about this:

  • Does the HIBP report on the screen Administration -> Reports return records for the report, is does it return no records?
  • Are you using any reverse proxies or load balancers

Thanks very much.

Regards

Click Studios

Share this post


Link to post
Share on other sites

For me the report does not work, I dont get the email even when I shedule and run the report.

And all I get when I click the export to excel in the Reports menu is a CSV with the top column definitions.

 

I can se in the firewall that it gets 250 Kb of data from 104.18.206.87 whitch is 

Name:    api.pwnedpasswords.com
Addresses:  2606:4700::6812:ce57
          2606:4700::6811:ac66
          104.18.206.87
          104.17.172.102

 

so it is doing something...

We are not using any Loadbalancer or Proxy, reverse or other types.

We do have a firewall but it says the trafic is alowed.

Share this post


Link to post
Share on other sites

Still no attempt to go to api.pwnedpasswords.com when saving new passwords, it only takes forever to save while it is "trying" to check the password.

Share this post


Link to post
Share on other sites
7 hours ago, support said:

Hi Guys,

 

Can you tell is the following about this:

  • Does the HIBP report on the screen Administration -> Reports return records for the report, is does it return no records?
  • Are you using any reverse proxies or load balancers

Thanks very much.

Regards

Click Studios

 

Hello!

  • Does the HIBP report on the screen Administration -> Reports return records for the report, is does it return no records?
    • This DOES work. I am able to return reports globally and per password list
  • Are you using any reverse proxies or load balancers
    • We DO use a reverse proxy to access the server from the outside.

Thank you.

Share this post


Link to post
Share on other sites

Hello parrishk,

 

Thanks for the detail. When you say it does work, I assume you mean it does return records showing issues with certain passwords? If the report had issues communicating to their API, it would just skip the password record, returning no results for it.

Regards

Click Studios

Share this post


Link to post
Share on other sites

Hi some update... and questions...

I finaly had some time yesterday to do some digging in to this in our system.

I found that all the haveibeenpwned integration works when logged in localy to the server and running it from a webbrowser there but not when connecting to the server from a different server.

Can you maybe point me in the right direction as to what we have locked down to tight, the GPO is basically the same for the server and the connecting server.

Is any of the haveibeenpwned code running in the browser?

 

could I enable some debug mode?

 

I'll contakt you thru the support channel as well but just wanted to post it here for the rest to see.

Share this post


Link to post
Share on other sites

Ok I solved the problem....

 

This is a Client side Script!!!

 

You need to say this as this is important for all of us not giving internet access to all of our systems....

So opening acces to the haveibeenpwned site from the clients made it work...

You actually don't even need the passwordstate server to be able to access haveibeenpwned.

 

Problem solved...

Please update your Documentation on this so others will not go into the same problem.

 

Best Regards Ulf

Share this post


Link to post
Share on other sites

Hello Ulf,

This integration is both client and server based, depending on which feature you are using i.e. reports run at the server end, and UI buttons is client based - we will update our documentation - thanks.

Regards
Click Studios

Share this post


Link to post
Share on other sites

Ha! Found the culprit.

 

It looks like there were two "Connect-Src" declared in the Content-Security-Policy header...not sure if this was on your end or my end as I already had some CSP headers in place before Passwordstate began implementing them.

 

Removed the second (CSP will only look at the first declared and ignore any additional) and all is good.

 

Was:

default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; img-src 'self'; connect-src 'self'; font-src 'self' fonts.gstatic.com fonts.googleapis.com; form-action 'self'; connect-src api.pwnedpasswords.com

 

Changed to:

default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline' fonts.googleapis.com; img-src 'self'; connect-src 'self' api.pwnedpasswords.com; font-src 'self' fonts.gstatic.com fonts.googleapis.com; form-action 'self'; connect-src api.pwnedpasswords.com

 

Share this post


Link to post
Share on other sites

Thanks for sharing - below are the headers we currently have, so we don't think these are the culprits - otherwise all customers should be having the same issue as you. Let us know what you think.

 

headers.png

 

Regards

Click Studios

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...