Build an API to check common passwords?

[flytzen]

Hi,

I was thinking about building a simple API to allow web developers to check a password provided by a user against the top-n list. It would be provided free to the community. As in, either me or my company would build and host it for free.

It raises some important questions;

1. You have put all this effort in to collating these lists, and I would not build anything like this without your explicit approval.
2. I have been thinking about whether there is a downside to building this as an API and I would really like someone else's opinion on whether this could potentially be abused.

If this API is indeed built, there are a couple of things to think about;

• There is something unnerving about a site sending a user's new password to this random API on the internet to check whether it is in the most-commonly-used. If the API was nefarious, it could potentially store the data and correlate it to the site, thus providing an easier attack vector. That may be the thing that kills the idea dead :) Unless there is a way to ensure the data cannot be correlated and provide assurances around that.
• The API would return the position on the list, i.e "1000th most commonly used". It is then up to the calling site to determine what they consider acceptable.

This may be a stupid idea, but I thought I'd put it out there to see what other people think.

[DarrenRainey]

sounds like a cool idea but it looks like the haveibeenpwned site with a rating system

[adamdecaf]

I would recommend not building such a tool. It's bad for reasons outside of what you said as well, but those reasons you said kill the idea already.

Another reason why it won't work is latency. Assuming your service is super fast and responds in 150-250ms, it's still easily beaten by even the most naive attempts in memory/from a file.

[flytzen]

@DarrenRainey Yes, Haveibeenpwned is a big inspiration for this :) The difference is that haveibeenpwned list email addresses of people that have been compromised, whereas this would have an anonymous list of the most common passwords in use.

[DarrenRainey]

sounds like a cool idea if you want I could help you with this as instead of sending a password why not send a password hash and compare it with a database of other password hashes that way you don't have to worry as much about a man in the middle attack

[flytzen]

@adamdecaf Thanks for the response. I think you are right that latency would be a problem - in reality, one of the reasons I'd like to build this is a technical exercise to see how low I could get that latency :) That said, even 250ms latency probably isn't really a problem as this would only be checked when the user is changing their password, so quite infrequently. You still have to wait ~500ms for the password to be hashed so you could probably run the two in parallel.

The comparison to in-memory/file is very valid for the people who care enough to roll their own. But I suspect most people don't. The thinking here is to do something that is very easy to just add a single call and not worry about it any more than that.

I do worry deeply about whether there are any security implications I haven't thought about, though.

[flytzen]

@DarrenRainey sending a hash is a great idea to mitigate MIM, thank you.

People should of course still worry about me knowing what the hash relates to :)

Also thanks for the offer of help! If @danielmiessler agrees to let us use the data in this way and I can secure the hosting funding my end (shouldn't be a problem) then this would all certainly be OSS and I'd love your input.

[DarrenRainey]

No problem it should be pretty simple to build server side maybe just a php script that receives the hash looks it up in a database and sends a response back. As for the client side you could build a custom app or ui or just use curl with something like md5sum, sha256sum etc.

[adamdecaf]

@flytzen It's not really "just adding a call". By sending this data off to a third party the site is likely violating implied and explicit privacy protections of consumers. How would this work with EU data export laws? Why should a site be sending off the most private information about an account/login to a third party? I wouldn't use any site that sent the password off to a third party knowingly.

What happens if the call to this verification site failed? Or was slow? Are users of this expected to fail-open or fail-closed?

I hope you understand that this site would only become a target for being broken into. The access logs alone would be a goldmine. It's easier to check a dictionary of 10k, 100k passwords in your app than rely on external network calls to do the same thing.

Please, don't make this a public site.

[adamdecaf]

@DarrenRainey How are you going to protect the hashes going forward? What happens when whatever hash function(s) used are broken/weakened? Are the clients and this site going to each agree on unique salts per req/resp? If you're just hashing the passwords and sending them over the wire they can be captured and stored for later (or offline brute force attempts).

[adamdecaf]

There are many examples of what a tool like hashcat can do on modest hardware and unsalted passwords (especially "average" consumer passwords) really don't stand a chance against determined attacks.

(search "hashcat" in the transcripts) https://www.grc.com/sn/sn-593.htm https://www.grc.com/sn/sn-594.htm

[DarrenRainey]

@adamdecat That is a good point but with all security there is a degree of risk and its only a matter of time until it is broken or cracked by the ever increasing amount of computer power but as long as the hashes are sent in a secure way such as https or even tor this shouldn't be too much of a problem and there will always have to be some amount of trust in the sites operators not to do anything malicious.

[flytzen]

@adamdecaf I think you are making a very good point about the access logs, that I hadn't thought about, thank you. I can make sure the API itself doesn't log anything, but it's not so easy to stop the underlying hosting infrastructure from logging it. And if I want to keep it simple and use a GET then the password (or the hash) would be in the querystring and therefore probably in the logs.

I think I'll instead write an example microservice for people to deploy themselves, but not actually offer a hosted version of it - unless I can figure out a way to avoid any access logs :)

[DarrenRainey]

pkill syslogd and rm -rf /var/logs/* :)

[flytzen]

I think Troy Hunt beat us to it ;) https://www.troyhunt.com/introducing-306-million-freely-downloadable-pwned-passwords/