Why do websites not use the HaveIBeenPwned API to warn users about exposed passwords?Passwords - any...
How do professional electronic musicians/sound engineers combat listening fatigue?
Monty Hall Problem with a Fallible Monty
How important is a good quality camera for good photography?
Why are off grid solar setups only 12, 24, 48 VDC?
What is "ass door"?
Company messed up with patent and now a lawyer is coming after me
Why are so many countries still in the Commonwealth?
Why do websites not use the HaveIBeenPwned API to warn users about exposed passwords?
Closet Wall, is it Load Bearing?
Determine if a triangle is equilateral, isosceles, or scalene
Why is chess failing to attract big name sponsors?
Is Grandpa Irrational? Another Grandpa Mystery
What should I say when a company asks you why someone (a friend) who was fired left?
What is the life span of a Flerken?
Strange Cron Job takes up 100% of CPU Ubuntu 18 LTS Server
Is the apartment I want to rent a scam?
How to write a sincerely religious protagonist without preaching or affirming or judging their worldview?
Area of parallelogram = Area of square. Shear transform
Book about young girl who ends up in space after apocolypse
Very basic singly linked list
kids pooling money for Lego League and taxes
High income, sudden windfall
Why are angular mometum and angular velocity not necessarily parallel, but linear momentum and linear velocity are always parallel?
What is the difference between $path and $PATH (lowercase versus uppercase) with zsh?
Why do websites not use the HaveIBeenPwned API to warn users about exposed passwords?
Passwords - any statistics on user behavior?An alternative to traditional passwords: is there some merit to this idea?SASL Authentication Protocol with No Cleartext passwordsHow to check if our clients were compromised by security breaches in other web applications?Is this idea for a password manager secure? If so, why doesn't anybody use it?Correct terminology when describing password security to laymanWhat can/should I do about gross lack of IT security at another company?How secure is BCRYPT(SHA1(Password))What password policy should a typical web app have?Is using haveibeenpwned to validate password strength rational?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}
There's lots of talk about the HaveIBeenPwned password checker which can securely tell users if their password appears in one of their known data dumps of passwords.
This tool has a publically available API behind it which websites/apps/etc are free to use to allow their users to check their passwords, but from what I can see all the listed applications are specifically email/password checker tools.
Never have I seen or heard of a user entering a password into a website while creating an account and it then gives them an error message detailing that their chosen password can be found in a well-known data breach. Is there a reason behind this?
If I were to create a website, would it be a bad idea to automatically check my user's passwords against haveIBeenPwned's tool as an additional safety precaution and to require them to pick a password which the site doesn't know about?
passwords have-i-been-pwned
New contributor
|
show 6 more comments
There's lots of talk about the HaveIBeenPwned password checker which can securely tell users if their password appears in one of their known data dumps of passwords.
This tool has a publically available API behind it which websites/apps/etc are free to use to allow their users to check their passwords, but from what I can see all the listed applications are specifically email/password checker tools.
Never have I seen or heard of a user entering a password into a website while creating an account and it then gives them an error message detailing that their chosen password can be found in a well-known data breach. Is there a reason behind this?
If I were to create a website, would it be a bad idea to automatically check my user's passwords against haveIBeenPwned's tool as an additional safety precaution and to require them to pick a password which the site doesn't know about?
passwords have-i-been-pwned
New contributor
1
For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit.
– Ghedipunk
10 hours ago
Why should a website do this? There is a cost to develop the connection to the API and process the inputs. What benefit does the website/app get to do this?
– schroeder♦
10 hours ago
1
Then you should edit your question to reflect your latest comment. What you posted looks like you are asking about their goals, desires, budgets, etc. Ask about what you want to do, not why others have not.
– schroeder♦
9 hours ago
4
@Buffalo5ix - they don't send the password hashed or unhashed. The system works by hashing the password and sending off the first 5 letters of the hash only. Then the API returns all the full hashes that begin with those 5 letters for the client to then check the full hash against. HIBP will never get your password, it's hash, or know if your password was a match or not.
– Toby Smith
9 hours ago
1
@TobySmith thanks, good to know, I haven't actually looked into the HIBP password match implementation
– Buffalo5ix
9 hours ago
|
show 6 more comments
There's lots of talk about the HaveIBeenPwned password checker which can securely tell users if their password appears in one of their known data dumps of passwords.
This tool has a publically available API behind it which websites/apps/etc are free to use to allow their users to check their passwords, but from what I can see all the listed applications are specifically email/password checker tools.
Never have I seen or heard of a user entering a password into a website while creating an account and it then gives them an error message detailing that their chosen password can be found in a well-known data breach. Is there a reason behind this?
If I were to create a website, would it be a bad idea to automatically check my user's passwords against haveIBeenPwned's tool as an additional safety precaution and to require them to pick a password which the site doesn't know about?
passwords have-i-been-pwned
New contributor
There's lots of talk about the HaveIBeenPwned password checker which can securely tell users if their password appears in one of their known data dumps of passwords.
This tool has a publically available API behind it which websites/apps/etc are free to use to allow their users to check their passwords, but from what I can see all the listed applications are specifically email/password checker tools.
Never have I seen or heard of a user entering a password into a website while creating an account and it then gives them an error message detailing that their chosen password can be found in a well-known data breach. Is there a reason behind this?
If I were to create a website, would it be a bad idea to automatically check my user's passwords against haveIBeenPwned's tool as an additional safety precaution and to require them to pick a password which the site doesn't know about?
passwords have-i-been-pwned
passwords have-i-been-pwned
New contributor
New contributor
New contributor
asked 10 hours ago
Toby SmithToby Smith
1193 bronze badges
1193 bronze badges
New contributor
New contributor
1
For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit.
– Ghedipunk
10 hours ago
Why should a website do this? There is a cost to develop the connection to the API and process the inputs. What benefit does the website/app get to do this?
– schroeder♦
10 hours ago
1
Then you should edit your question to reflect your latest comment. What you posted looks like you are asking about their goals, desires, budgets, etc. Ask about what you want to do, not why others have not.
– schroeder♦
9 hours ago
4
@Buffalo5ix - they don't send the password hashed or unhashed. The system works by hashing the password and sending off the first 5 letters of the hash only. Then the API returns all the full hashes that begin with those 5 letters for the client to then check the full hash against. HIBP will never get your password, it's hash, or know if your password was a match or not.
– Toby Smith
9 hours ago
1
@TobySmith thanks, good to know, I haven't actually looked into the HIBP password match implementation
– Buffalo5ix
9 hours ago
|
show 6 more comments
1
For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit.
– Ghedipunk
10 hours ago
Why should a website do this? There is a cost to develop the connection to the API and process the inputs. What benefit does the website/app get to do this?
– schroeder♦
10 hours ago
1
Then you should edit your question to reflect your latest comment. What you posted looks like you are asking about their goals, desires, budgets, etc. Ask about what you want to do, not why others have not.
– schroeder♦
9 hours ago
4
@Buffalo5ix - they don't send the password hashed or unhashed. The system works by hashing the password and sending off the first 5 letters of the hash only. Then the API returns all the full hashes that begin with those 5 letters for the client to then check the full hash against. HIBP will never get your password, it's hash, or know if your password was a match or not.
– Toby Smith
9 hours ago
1
@TobySmith thanks, good to know, I haven't actually looked into the HIBP password match implementation
– Buffalo5ix
9 hours ago
1
1
For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit.
– Ghedipunk
10 hours ago
For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit.
– Ghedipunk
10 hours ago
Why should a website do this? There is a cost to develop the connection to the API and process the inputs. What benefit does the website/app get to do this?
– schroeder♦
10 hours ago
Why should a website do this? There is a cost to develop the connection to the API and process the inputs. What benefit does the website/app get to do this?
– schroeder♦
10 hours ago
1
1
Then you should edit your question to reflect your latest comment. What you posted looks like you are asking about their goals, desires, budgets, etc. Ask about what you want to do, not why others have not.
– schroeder♦
9 hours ago
Then you should edit your question to reflect your latest comment. What you posted looks like you are asking about their goals, desires, budgets, etc. Ask about what you want to do, not why others have not.
– schroeder♦
9 hours ago
4
4
@Buffalo5ix - they don't send the password hashed or unhashed. The system works by hashing the password and sending off the first 5 letters of the hash only. Then the API returns all the full hashes that begin with those 5 letters for the client to then check the full hash against. HIBP will never get your password, it's hash, or know if your password was a match or not.
– Toby Smith
9 hours ago
@Buffalo5ix - they don't send the password hashed or unhashed. The system works by hashing the password and sending off the first 5 letters of the hash only. Then the API returns all the full hashes that begin with those 5 letters for the client to then check the full hash against. HIBP will never get your password, it's hash, or know if your password was a match or not.
– Toby Smith
9 hours ago
1
1
@TobySmith thanks, good to know, I haven't actually looked into the HIBP password match implementation
– Buffalo5ix
9 hours ago
@TobySmith thanks, good to know, I haven't actually looked into the HIBP password match implementation
– Buffalo5ix
9 hours ago
|
show 6 more comments
1 Answer
1
active
oldest
votes
Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2 - see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. So yes, please feel free to do so.
As for why you don't see this more often, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:
- Security is an area where many like to skimp, and implementing such a system takes additional effort.
- It takes time for new best practices to become common knowledge for institutions
- It takes even more time for institutions to get caught up with best practices
- Every developed feature costs money in terms of engineering time to develop and maintain, and may organizations may not consider the cost worth the benefit.
To be fair, none of my systems do this yet, so you can add me to #3 or #4.
Item #4 is worth a bit more mention. The costs of implementing this are obvious - it takes developer time to build and maintain any feature. The benefits are much harder to quantity. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement - it's always up to each business to weigh for themselves potential costs and benefits.
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "162"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Toby Smith is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f214116%2fwhy-do-websites-not-use-the-haveibeenpwned-api-to-warn-users-about-exposed-passw%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2 - see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. So yes, please feel free to do so.
As for why you don't see this more often, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:
- Security is an area where many like to skimp, and implementing such a system takes additional effort.
- It takes time for new best practices to become common knowledge for institutions
- It takes even more time for institutions to get caught up with best practices
- Every developed feature costs money in terms of engineering time to develop and maintain, and may organizations may not consider the cost worth the benefit.
To be fair, none of my systems do this yet, so you can add me to #3 or #4.
Item #4 is worth a bit more mention. The costs of implementing this are obvious - it takes developer time to build and maintain any feature. The benefits are much harder to quantity. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement - it's always up to each business to weigh for themselves potential costs and benefits.
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
add a comment |
Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2 - see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. So yes, please feel free to do so.
As for why you don't see this more often, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:
- Security is an area where many like to skimp, and implementing such a system takes additional effort.
- It takes time for new best practices to become common knowledge for institutions
- It takes even more time for institutions to get caught up with best practices
- Every developed feature costs money in terms of engineering time to develop and maintain, and may organizations may not consider the cost worth the benefit.
To be fair, none of my systems do this yet, so you can add me to #3 or #4.
Item #4 is worth a bit more mention. The costs of implementing this are obvious - it takes developer time to build and maintain any feature. The benefits are much harder to quantity. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement - it's always up to each business to weigh for themselves potential costs and benefits.
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
add a comment |
Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2 - see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. So yes, please feel free to do so.
As for why you don't see this more often, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:
- Security is an area where many like to skimp, and implementing such a system takes additional effort.
- It takes time for new best practices to become common knowledge for institutions
- It takes even more time for institutions to get caught up with best practices
- Every developed feature costs money in terms of engineering time to develop and maintain, and may organizations may not consider the cost worth the benefit.
To be fair, none of my systems do this yet, so you can add me to #3 or #4.
Item #4 is worth a bit more mention. The costs of implementing this are obvious - it takes developer time to build and maintain any feature. The benefits are much harder to quantity. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement - it's always up to each business to weigh for themselves potential costs and benefits.
Latest recommendations from the NIST (SP 800-63b Section 5.1.1.2 - see here or here for a summary) actually suggest checking user passwords against lists of known compromised passwords, so doing just that is actually in line with current best practices. It's also much better than requiring passwords to meet certain "rules" (which the NIST now recommends against). HIBP is just one way (and probably the simplest way) of doing this in practice. So yes, please feel free to do so.
As for why you don't see this more often, I'm sure that varies wildly from site-to-site, but I think it's a safe bet that it boils down to the usual suspects:
- Security is an area where many like to skimp, and implementing such a system takes additional effort.
- It takes time for new best practices to become common knowledge for institutions
- It takes even more time for institutions to get caught up with best practices
- Every developed feature costs money in terms of engineering time to develop and maintain, and may organizations may not consider the cost worth the benefit.
To be fair, none of my systems do this yet, so you can add me to #3 or #4.
Item #4 is worth a bit more mention. The costs of implementing this are obvious - it takes developer time to build and maintain any feature. The benefits are much harder to quantity. Of course when it comes to security issues, many companies make the mistake of assuming benefits are zero and therefore skimp on security (see point #1). However, this is one feature in which the benefits are likely small. There are often real costs to a business related to the compromise of user accounts (more customer support, perhaps rolling back transactions, etc...), but as long as the compromise was due to the user's own mistakes (in this case, by choosing compromised passwords), a business is unlikely to see any direct liability and therefore will probably avoid any larger costs. As a result, features like this may not be worthwhile for all businesses to implement - it's always up to each business to weigh for themselves potential costs and benefits.
edited 9 hours ago
answered 10 hours ago
Conor ManconeConor Mancone
12.1k5 gold badges28 silver badges55 bronze badges
12.1k5 gold badges28 silver badges55 bronze badges
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
add a comment |
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
@ConorMancone thanks for the edit, and is what I was hoping you'd include. Just throwing "good things to do" at a service is never a good idea. There needs to be a benefit to the cost.
– schroeder♦
9 hours ago
add a comment |
Toby Smith is a new contributor. Be nice, and check out our Code of Conduct.
Toby Smith is a new contributor. Be nice, and check out our Code of Conduct.
Toby Smith is a new contributor. Be nice, and check out our Code of Conduct.
Toby Smith is a new contributor. Be nice, and check out our Code of Conduct.
Thanks for contributing an answer to Information Security Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsecurity.stackexchange.com%2fquestions%2f214116%2fwhy-do-websites-not-use-the-haveibeenpwned-api-to-warn-users-about-exposed-passw%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
For your first question: There are too many reasons to count, including ignorance of the service, distrust, different company priorities, etc. That part is far too broad for this site. For your second question: The NIST standards suggest using such a service, though doesn't name the Pwned Passwords API of HIBP. It's up to you to do a cost/benefit analysis, threat assessment, etc., to see if it's right for you, or even if following the NIST standards is right for you; though we'll certainly be happy to give our opinions if this question's scope were reigned in a bit.
– Ghedipunk
10 hours ago
Why should a website do this? There is a cost to develop the connection to the API and process the inputs. What benefit does the website/app get to do this?
– schroeder♦
10 hours ago
1
Then you should edit your question to reflect your latest comment. What you posted looks like you are asking about their goals, desires, budgets, etc. Ask about what you want to do, not why others have not.
– schroeder♦
9 hours ago
4
@Buffalo5ix - they don't send the password hashed or unhashed. The system works by hashing the password and sending off the first 5 letters of the hash only. Then the API returns all the full hashes that begin with those 5 letters for the client to then check the full hash against. HIBP will never get your password, it's hash, or know if your password was a match or not.
– Toby Smith
9 hours ago
1
@TobySmith thanks, good to know, I haven't actually looked into the HIBP password match implementation
– Buffalo5ix
9 hours ago