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;
}







3















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?










share|improve this question







New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 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


















3















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?










share|improve this question







New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.















  • 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














3












3








3


1






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?










share|improve this question







New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











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






share|improve this question







New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










share|improve this question







New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








share|improve this question




share|improve this question






New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.








asked 10 hours ago









Toby SmithToby Smith

1193 bronze badges




1193 bronze badges




New contributor



Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.




New contributor




Toby Smith is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.










  • 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





    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










1 Answer
1






active

oldest

votes


















7














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:




  1. Security is an area where many like to skimp, and implementing such a system takes additional effort.

  2. It takes time for new best practices to become common knowledge for institutions

  3. It takes even more time for institutions to get caught up with best practices

  4. 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.






share|improve this answer


























  • @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














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.










draft saved

draft discarded


















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









7














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:




  1. Security is an area where many like to skimp, and implementing such a system takes additional effort.

  2. It takes time for new best practices to become common knowledge for institutions

  3. It takes even more time for institutions to get caught up with best practices

  4. 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.






share|improve this answer


























  • @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
















7














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:




  1. Security is an area where many like to skimp, and implementing such a system takes additional effort.

  2. It takes time for new best practices to become common knowledge for institutions

  3. It takes even more time for institutions to get caught up with best practices

  4. 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.






share|improve this answer


























  • @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














7












7








7







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:




  1. Security is an area where many like to skimp, and implementing such a system takes additional effort.

  2. It takes time for new best practices to become common knowledge for institutions

  3. It takes even more time for institutions to get caught up with best practices

  4. 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.






share|improve this answer















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:




  1. Security is an area where many like to skimp, and implementing such a system takes additional effort.

  2. It takes time for new best practices to become common knowledge for institutions

  3. It takes even more time for institutions to get caught up with best practices

  4. 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.







share|improve this answer














share|improve this answer



share|improve this answer








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



















  • @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










Toby Smith is a new contributor. Be nice, and check out our Code of Conduct.










draft saved

draft discarded


















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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...