[CoffeeOnWrite]

> sys admin accessing password hashes placed under his care

Parent commenter never mentioned anything about comparing stored password hashes. What you do is block bad passwords at password set time by hashing the prospective password and comparing with HIBP. A prospective password you haven't accepted or stored or transmitted off the application server - common sense says that's not a privacy violation - and many giant companies including my employer do this routinely.

[Edit] Oh yea I remember HIBP has an online API. Don't use this. Take the HIBP dumps that they make freely available and compare locally. If not for reasons of privacy, for reasons of simplicity and removing an unnecessary external business/legal/software dependency.

[twisteriffic]

> Oh yea I remember HIBP has an online API. Don't use this.

That's not the greatest advice IMO. The API gets updated data more frequently, doesn't require that you transmit the password or a useable hashed form, and it's dead simple to consume. I'd argue that it's more effort to maintain an internal store and synchronization infrastructure, and you're less likely to accidentally breach anonymity and leak a weak hash by using the API than you are rolling your own query against the raw data.

It's also used by hundreds of bigcorps and government agencies who have way more pedantic lawyers than you're likely to have. If they couldn't find a good reason not to use it I doubt yours will.

[berkes]

Those are good arguments for using an online service. But your conclusion is premature and certainly cannot be made blanket like that in favor of using the API.

Just as many arguments can be made for an offline check. Or against an online check. From added latency via required uptime to added dependencies.

My point being: no. "It depends"

[CoffeeOnWrite]

Well said. I should have said “you don’t have to use the API if you don’t want to” instead of “don’t use this”.

[Vicinity9635]

Ideally, but what if you're a new hire and the passwords already exist?

[CoffeeOnWrite]

Be satisfied with fixing the new passwords going forward. Or gracefully force a new password for everyone, if circumstances permit that (circumstances including decision making authority; if you are the new CTO or CISO, and you're paranoid about reviewing the existing hashes, you should strongly consider the batched graceful forced reset!)

You can set a flag on login to use the password in memory rather than stored.

[uxp8u61q]

That's how you get the whole company to love you as a new CTO - force everyone to change their password, including people who have a strong non-reused password.

[CoffeeOnWrite]

We’re evaluating different options in this thread. The right move is based on the circumstances and your judgement. I would support a new leader with the courage to close a security hole, maybe respect them even if I don’t love them.

By the way, I don’t feel paranoid to flag bad passwords on login (perhaps triggering an email OTP and forcing a password reset), personally. I responded to this thread because a commenter made an unfounded implication about using HIBP data to reduce vulnerability to credential stuffing.

[pavel_lishin]

Your job as a CTO isn't to be loved by the entire company.