[GH-ISSUE #41] Integration with haveibeenpwned (HIBP)

kerem commented

2026-03-14 09:54:54 +03:00

Owner

Originally created by @Twiglet1022 on GitHub (Apr 11, 2020).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/41

One of the downsides I've realised of using an email forwarding service is that if you want to sign up for notifications on HIBP you will need to sign each alias up individually. It would be a nice feature if every alias you create could be automatically signed up to it using the HIBP API, much like how Firefox Monitor lets you monitor multiple email addresses at once for involvement in any breaches.

I would prefer not to clutter up my Firefox Monitor with all these aliases, but more importantly it would also be easier to see if you've forgotten to sign any aliases up.

Admittedly though, by using a distinct alias for each website, a different password for every website, and limiting the personal information you give out to each website, it matters a lot less if one of those websites is breached. But I still think it would be a nice feature for added peace of mind and also to see who it was that let your data get into the wrong hands.

Originally created by @Twiglet1022 on GitHub (Apr 11, 2020). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/41 One of the downsides I've realised of using an email forwarding service is that if you want to sign up for notifications on HIBP you will need to sign each alias up individually. It would be a nice feature if every alias you create could be automatically signed up to it using the HIBP API, much like how Firefox Monitor lets you monitor multiple email addresses at once for involvement in any breaches. I would prefer not to clutter up my Firefox Monitor with all these aliases, but more importantly it would also be easier to see if you've forgotten to sign any aliases up. Admittedly though, by using a distinct alias for each website, a different password for every website, and limiting the personal information you give out to each website, it matters a lot less if one of those websites is breached. But I still think it would be a nice feature for added peace of mind and also to see who it was that let your data get into the wrong hands.

kerem commented

2026-03-14 09:55:00 +03:00

Author

Owner

@willbrowningme commented on GitHub (Apr 28, 2020):

Sorry for the late reply, I didn't get notified about this issue!

I agree that would be a great feature.

The only thing I'm not sure on is the best way to implement something like this.

Looking at the API docs - https://haveibeenpwned.com/API/v3 it appears requests to check breaches/pastes on email accounts are limited to one every 1.5 seconds.

So if say 50,000 aliases needed checking daily on AnonAddy then this would take 75,000 seconds (just over 20 hours).

Does anyone know if there would be a better way to do this? For example checking an entire domain in one go instead?

@willbrowningme commented on GitHub (Apr 28, 2020): Sorry for the late reply, I didn't get notified about this issue! I agree that would be a great feature. The only thing I'm not sure on is the best way to implement something like this. Looking at the API docs - https://haveibeenpwned.com/API/v3 it appears requests to check breaches/pastes on email accounts are limited to one every 1.5 seconds. So if say 50,000 aliases needed checking daily on AnonAddy then this would take 75,000 seconds (just over 20 hours). Does anyone know if there would be a better way to do this? For example checking an entire domain in one go instead?

kerem commented

2026-03-14 09:55:05 +03:00

Author

Owner

@stefanschramek commented on GitHub (Apr 28, 2020):

What do think about letting the users set their own API key for the integration? Otherwise you would need to buy the subscriptions for this and the limits would not be that relevant this way!

@stefanschramek commented on GitHub (Apr 28, 2020): What do think about letting the users set their own API key for the integration? Otherwise you would need to buy the subscriptions for this and the limits would not be that relevant this way!

kerem commented

2026-03-14 09:55:10 +03:00

Author

Owner

@willbrowningme commented on GitHub (Apr 28, 2020):

@stefanschramek That's an interesting suggestion, it would be good if there was an API for the https://haveibeenpwned.com/DomainSearch that way I could do entire domains at a time.

@willbrowningme commented on GitHub (Apr 28, 2020): @stefanschramek That's an interesting suggestion, it would be good if there was an API for the https://haveibeenpwned.com/DomainSearch that way I could do entire domains at a time.

kerem commented

2026-03-14 09:55:15 +03:00

Author

Owner

@Coderdude112 commented on GitHub (Dec 7, 2021):

I totally see your point. I just feel like if we could get integration with HIBP we could setup automatic actions such as disabling the email address, now that it's been leaked. I still feel like integration with HIBP would be nice and helpful

@Coderdude112 commented on GitHub (Dec 7, 2021): I totally see your point. I just feel like if we could get integration with HIBP we could setup automatic actions such as disabling the email address, now that it's been leaked. I still feel like integration with HIBP would be nice and helpful

kerem commented

2026-03-14 09:55:20 +03:00

Author

Owner

@Coo-ops commented on GitHub (Jan 31, 2022):

just feel like if we could get integration with HIBP we could setup automatic actions such as disabling the email address

You still need to intervene to make sure your emails actually go somewhere before disabling the alias.

FWIW - HIBP can do entire domains. So AnonAddy would only need query HIBP for the unique user domain, or the users custom domain.

Doesn't help those using non-personal shared Anonaddy domains though.

It is the responsibility of a breached company to inform their customers though. So maybe its not that necessary.

@Coo-ops commented on GitHub (Jan 31, 2022): > just feel like if we could get integration with HIBP we could setup automatic actions such as disabling the email address You still need to intervene to make sure your emails actually go _somewhere_ before disabling the alias. FWIW - HIBP can do entire domains. So AnonAddy would only need query HIBP for the unique user domain, or the users custom domain. Doesn't help those using non-personal shared Anonaddy domains though. It is the responsibility of a breached company to inform their customers though. So maybe its not that necessary.

kerem commented

2026-03-14 09:55:25 +03:00

Author

Owner

@Coderdude112 commented on GitHub (Feb 6, 2022):

You still need to intervene to make sure your emails actually go somewhere before disabling the alias.

Yeah totally see your point, the disabling the alias was an example. Currently we have the opportunity to set custom rules which is pretty nice. So my ideal move would be to be able to setup a custom rule that allows an email sent to a leaked alias to have something like the subject changed and then my actual email can handle it with rules from there.

It is the responsibility of a breached company to inform their customers though.

My person (non aliased) email shows like 10+ leaks on HIBP and I can only remember like 2 ever emailing me. I can be the company's responsibility but in my experience most dont do crap

@Coderdude112 commented on GitHub (Feb 6, 2022): > You still need to intervene to make sure your emails actually go somewhere before disabling the alias. Yeah totally see your point, the disabling the alias was an example. Currently we have the opportunity to set custom rules which is pretty nice. So my ideal move would be to be able to setup a custom rule that allows an email sent to a leaked alias to have something like the subject changed and then my actual email can handle it with rules from there. > It is the responsibility of a breached company to inform their customers though. My person (non aliased) email shows like 10+ leaks on HIBP and I can only remember like 2 ever emailing me. I can be the company's responsibility but in my experience most dont do crap

kerem commented

2026-03-14 09:55:30 +03:00

Author

Owner

@jikamens commented on GitHub (Oct 9, 2024):

I honestly don't think having this integration is needed. The entire point of having this anon addy service is to not care if your single address is compromised. If so, gen a new one and move on with your day. HIBP is useful when you continuously use a single address and therefore have a single point of failure for all your logins.

Hard disagree, because we have know way of knowing if that "single address is compromised" without something matching up AnonAddy addresses against the Have I Been Pwned database. As others in the thread have pointed out, most compromised accounts do not, in fact, result in notifications being sent out. That's one of the main reasons why Have I Been Pwned exists.

@jikamens commented on GitHub (Oct 9, 2024): >I honestly don't think having this integration is needed. The entire point of having this anon addy service is to not care if your single address is compromised. If so, gen a new one and move on with your day. HIBP is useful when you continuously use a single address and therefore have a single point of failure for all your logins. Hard disagree, because we have know way of _knowing_ if that "single address is compromised" without something matching up AnonAddy addresses against the Have I Been Pwned database. As others in the thread have pointed out, most compromised accounts do not, in fact, result in notifications being sent out. That's one of the main reasons why Have I Been Pwned exists.

kerem commented

2026-03-14 09:55:35 +03:00

Author

Owner

@jikamens commented on GitHub (Oct 9, 2024):

I think the way this integration would work would ideally be something like this:

AnonAddy subscribes to notifications from HIBP for all of the domains it has email addresses in. When it starts managing a new domain it subscribes to that one as well.
When AnonAddy is notified by HIBP that addresses in one of these domains have been compromised, it queries HIBP for details about all the compromised email addresses in that domain.
The resulting data are mapped to AnonAddy users and stored in the database associated with those users' accounts.
AnonAddy users with new compromises added to the database are sent notification emails that they have new compromised email addresses.
Information about the compromised email addresses for each user are displayed in a table in a tab for that user, with a "compromise date" column that the table can be sorted by, perhaps sorted most-recent-first by default, so the user can easily see new compromises.

The functionality described above would essentially mimic the HIBP functionality provided to people who monitor their own customer domains in HIBP (as I do, but that is becoming less and less useful as I move more and more of my web accounts over to AnonAddy email addresses).

I don't know if the current HIBP API would support everything described above, but if not, then I think @troyhunt might be open to discussing enhancements to the API to support it, given that this would all be in the service of a service (AnonAddy) whose entire purpose is to help protect people's privacy and security.

@jikamens commented on GitHub (Oct 9, 2024): I think the way this integration would work would ideally be something like this: 1. AnonAddy subscribes to notifications from HIBP for all of the domains it has email addresses in. When it starts managing a new domain it subscribes to that one as well. 2. When AnonAddy is notified by HIBP that addresses in one of these domains have been compromised, it queries HIBP for details about all the compromised email addresses in that domain. 3. The resulting data are mapped to AnonAddy users and stored in the database associated with those users' accounts. 4. AnonAddy users with new compromises added to the database are sent notification emails that they have new compromised email addresses. 5. Information about the compromised email addresses for each user are displayed in a table in a tab for that user, with a "compromise date" column that the table can be sorted by, perhaps sorted most-recent-first by default, so the user can easily see new compromises. The functionality described above would essentially mimic the HIBP functionality provided to people who monitor their own customer domains in HIBP (as I do, but that is becoming less and less useful as I move more and more of my web accounts over to AnonAddy email addresses). I don't know if the current HIBP API would support everything described above, but if not, then I think @troyhunt might be open to discussing enhancements to the API to support it, given that this would all be in the service of a service (AnonAddy) whose entire purpose is to help protect people's privacy and security.

kerem commented

2026-03-14 09:55:40 +03:00

Author

Owner

@jikamens commented on GitHub (Oct 10, 2024):

Apparently, SimpleLogin already has this feature. Ref: https://fosstodon.org/@simplelogin/112439143741650400

@jikamens commented on GitHub (Oct 10, 2024): Apparently, [SimpleLogin](https://github.com/simple-login) already has this feature. Ref: https://fosstodon.org/@simplelogin/112439143741650400

kerem commented

2026-03-14 09:55:46 +03:00

Author

Owner

@tobilinz commented on GitHub (Dec 27, 2024):

There is another website called https://databreach.com/ that can do the same thing as https://haveibeenpwned.com/.
They also claim to have an even bigger database than https://haveibeenpwned.com/.
I wasn't able to find any API limits either, but they might of course have put some in place that are just not shown publicly.
If they don't allow the volume of requests that would be required for a service like addy, then it might make sense to limit this feature to lite / pro subscribers. This would probably also motivate more people to pay for this service too.

Unrelated: I was also wondering, what the term Active Shared Domain Aliases on https://addy.io/#pricing means and what makes it different from Standard Aliases. Can someone explain that to me? I might just be stupid, but if that terminology confuses more people than me, then it might make sense to make that more clear on the homepage.

@tobilinz commented on GitHub (Dec 27, 2024): There is another website called https://databreach.com/ that can do the same thing as https://haveibeenpwned.com/. They also claim to have an even bigger database than https://haveibeenpwned.com/. I wasn't able to find any API limits either, but they might of course have put some in place that are just not shown publicly. If they don't allow the volume of requests that would be required for a service like addy, then it might make sense to limit this feature to lite / pro subscribers. This would probably also motivate more people to pay for this service too. Unrelated: I was also wondering, what the term `Active Shared Domain Aliases` on https://addy.io/#pricing means and what makes it different from `Standard Aliases`. Can someone explain that to me? I might just be stupid, but if that terminology confuses more people than me, then it might make sense to make that more clear on the homepage.

kerem referenced this issue

2026-03-14 11:31:50 +03:00

[GH-ISSUE #647] verification email is not being sent / AWS SES / Email is bouncing with "Email address is not verified" error #1027

Rows
Columns

[GH-ISSUE #41] Integration with haveibeenpwned (HIBP) #647