> ...wipes out the existing data allowing only one user Id > associated to an account . And hence allowing user to > have same old user id and password always, after reset. That sounds like a bug in their implementation. If the user id stays the same then I would expect the password history check to kick in to prevent a prior password from being used. If they change the user id at the same time then I don't believe the prior password check is as important, though I'd still implement it anyway to be thorough. > But again even if it dint allow this and the application remembers > last 4 passwords , the user can reset the password 4 times > allowing him to reuse the same old password, very few sites > restrict the no of password reset you can do on a day, That can be easily negated by adding a time limit to those stored hashes (or encrypted versions) of their old passwords in addition to the counter. Make it so they can't reuse a password within 30 days or the four previous passwords regardless of time and their incentive to play that game will disappear. Someone else mentioned using reversible encryption instead of a hash to to more detailed analysis of newer passwords. This could be useful in high-security environments (and only if you have proper key management in place), but would be overkill for many basic applications. Just remember that the more restrictions you place on their password, the more likely it will be that their password ends up as a sticky note on the edge of their monitor. -Justin