4 ms·
We just implemented this in-house today against our user logins, except we pulled the entire 30+GB data file locally, instead of doing the API callout like 1p d
by zie 9y ago
We just implemented this in-house today against our user logins, except we pulled the entire 30+GB data file locally, instead of doing the API callout like 1p does it.
So far no owned passwords have been found!
Highly recommend doing this.
- rootlocus 9y ago> except we pulled the entire 30+GB data file locally, instead of doing the API callout like 1p does it. Lucky for Troy he has a special arrangement with Cloudflare, otherwise everyone doing this would contribute to a massive bandwidth bill.
- zie 9y agowell, I used torrent, like he asks, if possible to please do.. But yes, thankfully he still provides a straight download thanks to CloudFare. We did it locally, because we are a regulated industry, and doing random calls out to the internet, especially from a authentication server, is all kinds of nightmare to make happen.
- moviuro 9y agoSee [0] [0] https://twitter.com/troyhunt/status/897571703202603008 https://twitter.com/troyhunt/status/897571703202603008
- dajonker 9y agoSo you mean to say that you store all your users logins with just SHA1, no salt?
- zie 9y agoLOL. EXACTLY! :) No.. @ password time, we do the normal path PLUS we take the plaintext password, encrypt it with SHA1, see if it's in the pwned database, if it is, warn user. Then we throw the SHA1 away. So sure, it's stored in memory as a SHA1 hash, briefly, but that same memory has the plaintext password...briefly so :) Our normal auth path just attacks AD, so we use AD as the primary store for passwords. After it's been in production for a while, and we see it's still working like gangbusters, then we will turn on that @ password change time, if it's in the DB, we will ban that password from being used. Probably in the next week or two, it depends.