Skip to main content
Information Security

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

6
  • 1
    How does this work? Does it check the username against the password stored in the database, if they match, force reset? Is this web based or also at the Windows/LDAP level? If so, is this a custom or off the shelf product? Commented Mar 6, 2013 at 5:14
  • @EricG: It's a custom system, and I didn't build it, so I don't really know how it was implemented. That said, I believe it works by hashing the username and checking the hashes against the password hashes. My understanding is that they keep a database somewhere of "passwords found under suspicious circumstances" and expire any active passwords that match that list. Commented Mar 6, 2013 at 6:23
  • 1
    @jcolebrand: Sorry, I thought I explained that: hash whatever gets entered into the username field and check the hash against the password database. Optionally use something like a Bloom filter if you have a really big password database and want to check quickly. I have no idea if this is what they actually do, though: maybe there's an even better way. Commented Mar 6, 2013 at 22:05
  • 3
    That may actually be a valid thing to do. Then the problem is I can put in 1234567 or password1 etc and invalidate a whole lotta passwords. If I think I know my buddies password, etc. Commented Mar 6, 2013 at 22:21
  • 2
    I'm with EricG. I don't understand how to actually implement this in a secure way. If the password database is storing password using a salt (and using a slow password hash like bcrypt), it's not easy to verify whether an incorrect username is actually someone's password, and if so, find whose it was -- the best you can do is exhaustive search over all users in the database, which is not scalable. If the password database doesn't use a salt (or doesn't use a slow password hash), you've got more serious problems -- that's a definite no-no. Commented Mar 7, 2013 at 8:57