• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Password check against HaveIBeenPwned API

Mike

XenForo developer
Staff member
#3
That's not a password check -- all it could tell you is if the email (or maybe username) was in a compromised set of data. Taking action on that alone can actually be user hostile.
 

Alfa1

Well-known member
#4
There is increased risk and a need to increase security if the user is in HIBP. If a user is in the HIBP database (email address) then this should increase the password requirements in terms of complexity and expiration. It would also be useful to send the user a clear message explaining that they should not reuse the same password that was used on the breached website.
 

Fred.

Well-known member
#5
That's not a password check -- all it could tell you is if the email (or maybe username) was in a compromised set of data. Taking action on that alone can actually be user hostile.
From what I understand of it it was like that earlier but he extended it to passwords. Check the bottom of the page where it says "Pwned Passwords".
 
Last edited:

Alfa1

Well-known member
#6
I suggest the following:
IF the member is in the HIBP database (email match) AND the password also matches one of the 3.6 million passwords in the database, then force the user to change their password and force high complexity.

Show the user a notice:
It appears that you are using a password that you also use on other sites and is listed in the www.haveibeenpowned.com database. More information here.
Please change your password now.
 
#7
IF the member is in the HIBP database (email match) AND the password also matches one of the 3.6 million passwords in the database
You want to send a users email address, then another request to check password, to a third-party during registration to make sure they aren't in the database? What's to stop that third-party from logging the requests? Then they would have the users login info. I wouldn't send the password. Display a message with a link if you want members to check if they're in there or not before they register.
 
Last edited:

Martok

Well-known member
#8
You want to send a users email address, then another request to check password, to a third-party during registration to make sure they aren't in the database? What's to stop that third-party from logging the requests? Then they would have the users login info. I wouldn't send the password. Display a message with a link if you want members to check if they're in there or not before they register.
I'd have to agree with this.

Whilst the suggestion is a useful one and the HaveIBeenPwned is very good, I don't think that forum owners have the right to submit user's emails or passwords to 3rd party sites without their explicit permission. Even saying this would happen in the registration form might put people off registering. Starting to add options to make it optional starts to complicate things for integration. Therefore it's probably better to make a post explaining the HaveIBeenPwned site to members and creating a notice for this to show on the new registration page.
 

Arty

Well-known member
#11
There is increased risk and a need to increase security if the user is in HIBP. If a user is in the HIBP database (email address) then this should increase the password requirements in terms of complexity and expiration. It would also be useful to send the user a clear message explaining that they should not reuse the same password that was used on the breached website.
Which leads to user writing password on paper if he actually cares about community or always forgetting it if he doesn't, resulting in fewer users. I hate websites that have arbitrary password requirements and avoid them unless I really really need something from that website.

Password expiration and requirements make sense only for people with moderator/admin access. That's what 2FA is for.
 

Alfa1

Well-known member
#12
In essence I agree with you @Arty but this only concerns members who use a password that is known to hackers and who risk their account getting accessed. The alternative is indeed forcing 2fa on them, but I dont think thats friendly either.
You want to send a users email address, then another request to check password, to a third-party during registration
This suggestion is not necessarily about registration. But its not much different than StopForumSpam or ProjectHoneypot where you use the API to find email, name and IP. As @Fred. says passwords can be hashed.
I believe @DragonByte Tech uses something like this API in their security addon.
This is correct, but I would not use their implementation as it will only confuse my members and erroneously lead them to think my website is hacked. I don't think the message to members is clear enough. I have their security addon and other functions in it are very good.
 

Alfa1

Well-known member
#15
Couldn't you just change the phrase though, to make it more clear?
No, its not just a phrase. Its a combination of text and data presented in a way that will confuse the average person a lot. Its important to let rhe person know exactly what the problem is without installing fear that their account is hacked.
 

ozzy47

Well-known member
#16
No, I reported this bug but changed to a feature request and Still Under Consideration ... :mad:
No, its not just a phrase. Its a combination of text and data presented in a way that will confuse the average person a lot. Its important to let rhe person know exactly what the problem is without installing fear that their account is hacked.
Sounds to me like @DragonByte Tech / Fillip needs to get to work on that, but it may be something returned from the API.

But back on track, yes it is possible as it is used in their security addon, but not sure if I would want it to show up during registration though.
 

Sim

Well-known member
#17
You want to send a users email address, then another request to check password, to a third-party during registration to make sure they aren't in the database? What's to stop that third-party from logging the requests? Then they would have the users login info. I wouldn't send the password. Display a message with a link if you want members to check if they're in there or not before they register.
I know Troy - he's one of the good guys and is very careful how he manages stuff like this.

If you ever get a chance to go to one of his security talks or courses, I highly recommend them - he is a great presenter and has really useful and practical information.
 

ManagerJosh

Well-known member
#18
I just noticed Troy Hunt has an API on HaveIBeenPwned.com so it would be possible to check new (or maybe even used?) passwords against the API and warn the user.
This would improve security and make the user aware his password is Pwned. :)
There's absolutely no way Troy stores passwords or potentially sensitive data of that kind. It would make him an even greater target than some of the other places that have been breached.

I suggest the following:
IF the member is in the HIBP database (email match) AND the password also matches one of the 3.6 million passwords in the database, then force the user to change their password and force high complexity.

Show the user a notice:
While viable and a good idea on paper, it's a terrible idea on terms of implementation because it's heavily dependent on 'dumps' being submitted. Who knows how old a dump finally appears and surfaces and the time it actually hits the database.

For example, a website dump from 2010 suddenly appears, and it forces a password change all of the sudden? Potentially that user used that password somewhere else between 2010 and present and they no longer use it. Therefore when this dump surfaces, we assume the password is the same and therefore we burn a completely valid and safe password even though it hasn't been used?

More to the point - the idea in the long run isn't very useful because because XF we're still dealing with single factor authentication. Just take advantage of the XF feature set and leverage the XF two factor authentication. That second factor should act as a decent safeguard even though the password could potentially be compromised.
 
Last edited:

Sim

Well-known member
#19
There's absolutely no way Troy stores passwords or potentially sensitive data of that kind. It would make him an even greater target than some of the other places that have been breached.
Troy has a new dataset - completely separate from the HIBP system.

See here: https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-passwords/

His original HIBP system just lets you check email addresses against breaches (no password matching), while this new (separate) system lets you check a password against a set of previously hacked passwords (no account matching) to make recommendations about password strength based on NIST recommendations about checking against "passwords obtained from previous breach corpuses".

He is not cross referencing account signons with passwords or anything like that - there is no matching occurring, it's simply a dictionary of previously hacked passwords.
 

DragonByte Tech

Well-known member
#20
Couldn't you just change the phrase though, to make it more clear?
Yes, you can. The phrase is dbtech_security_account_breach_alert_body :)

No, I reported this bug but changed to a feature request and Still Under Consideration ... :mad:
Changing the wording (which is something you can do yourself using the aforementioned phrase) is not a bug.

Sounds to me like @DragonByte Tech / Fillip needs to get to work on that, but it may be something returned from the API.
The data returned is, IIRC, quite limited, which is understandable since you don't want to prove enough information that it actually becomes an exploit vector in and of itself.

At the moment the phrase reads "DragonByte Security has detected that your account has been the subject of a breach on another site. We recommend you change your password and enable two-factor authentication to stop your account from being a target of further breaches." then a list of sites, one per line, in the format SiteTitle - SiteUrl

The SiteTitle - SiteUrl format cannot be changed at this time but the phrase absolutely can :)

Furthermore, a recent version of the mod added the option to disable the username check, instead only checking emails, which can significantly cut down on false positives if the member(s) in question use a common user name.

Considering the fact that people have voiced opinions saying it's confusing, without actually offering alternative solutions that I can evaluate, I'd say that it's not a high priority at this time. If anyone has constructive feedback with actual suggestions for improvement, it's certainly something I can look into changing for the update that enables XF2 compatibility :)


Fillip