I'm looking for the best secure way to manage password history when an user resets(or creates a new) user id in a secure pci dss website.
Should we maintain single user Id per account and wipe out or overwrite the existing user Id and password history .
(this defeats the purpose of maintaining a password history as the user can always reuse the same Id and password)
Or
Should we create a new second user Id
Associated to this account and make sure the previous Userid is not used again ? In this case should we map the old password history to new one or let the user use his previous passwords on the new id?
This is on top of the rsa two factor authentication , the credentials referred here are what is stored in the application database to enforce password history(passmark authentication does not enforce password history)
Please advise ,
Thanks
Subin
Sent from my iPhone
From: Subin subin.net@gmail.com
Date: November 10, 2011 3:22:13 PM EST
To: "websecurity@lists.webappsec.org" websecurity@lists.webappsec.org
Subject: [WEB SECURITY] What's the best way to maintain password history?
I'm looking for the best secure way to manage password history when an user resets(or creates a new) user id in a secure pci dss website.
Should we maintain single user Id per account and wipe out or overwrite the existing user Id and password history .
(this defeats the purpose of maintaining a password history as the user can always reuse the same Id and password)
Or
Should we create a new second user Id
Associated to this account and make sure the previous Userid is not used again ? In this case should we map the old password history to new one or let the user use his previous passwords on the new id?
This is on top of the rsa two factor authentication , the credentials referred here are what is stored in the application database to enforce password history(passmark authentication does not enforce password history)
Please advise ,
Thanks
Subin
Sent from my iPhone
Steve,
On Thu, Nov 10, 2011 at 3:30 PM, Steven M. Christey
coley@rcf-smtp.mitre.org wrote:
A software weakness, as we use in CWE, is a property of
software/systems that, under the right conditions, may permit
unintended or unauthorized behavior. For example, if a routine does
not perform input validation, then it might permit unintended or
unauthorized behavior. (In the CWE world, we generally think of a CWE
entry as a weakness "type.")
I prefer "vulture" i.e. a play on the words "vulnerability" and
"feature", which was suggested by Shawn Moyer and Nathan Hamiel at
Black Hat USA 2008 in their presentation was "Satan is on my Friends
List: Attacking Social Networks".
--
Regards,
Christian Heinrich