What is a "breach" and where has the data come from?
A "breach" is an incident where data is inadvertently exposed in a vulnerable system, usually due to insufficient access controls or security weaknesses in the software. HIBP aggregates breaches and enables people to assess where their personal data has been exposed.
Are user passwords stored in this site?
When email addresses from a data breach are loaded into the site, no corresponding passwords are loaded with them. Separately to the pwned address search feature, the Pwned Passwords service allows you to check if an individual password has previously been seen in a data breach. No password is stored next to any personally identifiable data (such as an email address) and every password is SHA-1 hashed (read why SHA-1 was chosen in the Pwned Passwords launch blog post.)
Can I send users their exposed passwords?
No. Any ability to send passwords to people puts both them and myself at greater risk. This topic is discussed at length in the blog post on all the reasons I don't make passwords available via this service.
Is a list of everyone's email address or username available?
The public search facility cannot return anything other than the results for a single user-provided email address or username at a time. Multiple breached accounts can be retrieved by the domain search feature but only after successfully verifying that the person performing the search is authorised to access assets on the domain.
What about breaches where passwords aren't leaked?
Occasionally, a breach will be added to the system which doesn't include credentials for an online service. This may occur when data about individuals is leaked and it may not include a username and password. However this data still has a privacy impact; it is data that those impacted would not reasonably expect to be publicly released and as such they have a vested interest in having the ability to be notified of this.
How is a breach verified as legitimate?
There are often "breaches" announced by attackers which in turn are exposed as hoaxes. There is a balance between making data searchable early and performing sufficient due diligence to establish the legitimacy of the breach. The following activities are usually performed in order to validate breach legitimacy:
1. Has the impacted service publicly acknowledged the breach?
2. Does the data in the breach turn up in a Google search (i.e. it's just copied from another source)?
3. Is the structure of the data consistent with what you'd expect to see in a breach?
4. Have the attackers provided sufficient evidence to demonstrate the attack vector?
5. Do the attackers have a track record of either reliably releasing breaches or falsifying them?
How does HIBP handle "plus aliasing" in email addresses?
Some people choose to create accounts using a pattern known as "plus aliasing" in their email addresses. This allows them to express their email address with an additional piece of data in the alias, usually reflecting the site they've signed up to such as firstname.lastname@example.org or email@example.com. There is presently a UserVoice suggestion requesting support of this pattern in HIBP. However, as explained in that suggestion, usage of plus aliasing is extremely rare, appearing in approximately only 0.03% of addresses loaded into HIBP. Vote for the suggestion and follow its progress if this feature is important to you.
How is the data stored?
The breached accounts sit in Windows Azure table storage which contains nothing more than the email address or username and a list of sites it appeared in breaches on. If you're interested in the details, it's all described in Working with 154 million records on Azure Table Storage – the story of Have I Been Pwned
How do I know the site isn't just harvesting searched email addresses?
You don't, but it's not. The site is simply intended to be a free service for people to assess risk in relation to their account being caught up in a breach. As with any website, if you're concerned about the intent or security, don't use it.
BULGARIAN and English
Just upload pwned_passwords.ocmod.zip via Extension Installer and Refresh Modifications.
Add permissions to this module via User Groups
In Extensions -> Security -> Pwned Password - Have I Been Hacked Integration, select Activated and Save
When your new customers trying to register or the yours old customers change existing password, this module will checks the passwords via huge HIBH Database and if the requested customer password is hacked, your customer will should changing this password because the store will stop registration.
Thats all! Kind regards..
If you have some problems with this module, just write comment and I will connecting with you!
Works ONLY with passwords!! Not checks email or anything else!