- I think he knows that it is not good. He's still looking for the best solution under the stated requirements.
NOTE: This comment was originally posted at StackOverflow.com by stefanw
- At the end of the day all you will be doing is carefully implementing an avoidable vulnerability.
NOTE: This comment was originally posted at StackOverflow.com by Rook
- True, but the question was for the most responsible way of doing it ;)
NOTE: This comment was originally posted at StackOverflow.com by stefanw
- @Michael Brooks - I want you to know that I am absolutely in agreement with CWE-257 and would love to just quote that verbatim each and every time I am asked to make passwords recoverable as plaintext. However, in reality, clients and users are rarely interested in NIST regulations and just want me to do it anyway. 90% of the time I can convince them otherwise but in that 10% of time when I can't I am trying to determine the best course of action--in those cases CWE-257 is ashes in my hand (unfortunately).
NOTE: This comment was originally posted at StackOverflow.com by shanee
- @Shane, Perhaps you should ask how you can implement a Buffer Overflow Vulnerability in a Secure way. There is nothing stopping you from implement a secure system. Use password resets, if they don't know their password then they should make a new one.
NOTE: This comment was originally posted at StackOverflow.com by Rook
- @Michael Brooks - I am not arguing--AT ALL--that your suggestion is the best way to do it. But certain user bases (for example, the elderly or actual non-computer users) who are targeted by sites I have worked on are confused by what we consider standard password reset routines. In those cases functionality (not security) would call for a password reminder rather than a reset. Those are the times when this has come up for me--clients don't want to throw away valuable users in certain demographics by asking them to preform what is to them a highly technical task. I hope that makes sense.
NOTE: This comment was originally posted at StackOverflow.com by shanee
- @Shane/Michael: By default let user be able to recover password in plain text. Then have user setting that allows user to make a secure choice as not to be able to recover password in plain text. Advanced users who can will choose this setting.
NOTE: This comment was originally posted at StackOverflow.com by Gladwin Burboz
- Loving this discussion! However, one important point has been very glossed over by nearly everyone... My initial reaction was very similar to @Michael Brooks, till I realized, like @stefanw, that the issue here is broken requirements, but these are what they are. But then, it occured to me that that might not even be the case! The missing point here, is the unspoken value of the application's assets. Simply speaking, for a low value system, a fully secure authentication mechanism, with all the process involved, would be overkill, and the wrong security choice.
NOTE: This comment was originally posted at StackOverflow.com by AviD
- (continuing) Obviously, for a bank, the "best practices" are a must, and there is no way to ethically violate CWE-257. But it's easy to think of low value systems where its just not worth it (but a simple password is still required). It's important to remember, true security expertise is in finding appropriate tradeoffs, NOT in dogmatically spouting the "best practices" that anyone can read online.
NOTE: This comment was originally posted at StackOverflow.com by AviD
- It's amazing to me that you guys are trying to reason with Michael Brooks. Wow, the guy doesn't get it.
NOTE: This comment was originally posted at StackOverflow.com by zumalifeguard
- @AviD: The "low value" of the system has absolutely no bearing on this issue because people reuse their passwords. Why can't people understand this simple fact? If you crack the passwords on some "low value" system, you will likely have several valid passwords for other "high value" systems.
NOTE: This comment was originally posted at StackOverflow.com by Aaronaught
- Another point has also been glossed over, which I just mentioned in the comment stream to my answer: How do you know that the person asking for these requirements is trustworthy? What if the "usability" excuse is just a façade masking a real intent to steal the passwords at some point in the future? Your naiveté may have just cost customers and shareholders millions. How many times must security experts repeat this before it finally sinks in: The most common and most serious security threats are always INTERNAL.
NOTE: This comment was originally posted at StackOverflow.com by Aaronaught
- Is it ironic that the most ethical solution here is to lie and tell the client passwords cannot be stored securely and be recoverable? Offer a more secure solution at the same time, and maybe you'll have convinced someone that passwords must be irreversibly encrypted.
NOTE: This comment was originally posted at StackOverflow.com by ehdv
- I responded to the comments here, down in my response, since it was quite lengthy - i think its important to review the analysis and the discussion of issues raised. stackoverflow.com/questions/2283937/…
NOTE: This comment was originally posted at StackOverflow.com by AviD
- Apart from the whole security discussion, it really eludes me why you would need such a system, even for specific audiences. If your users already have to rely on support for retrieving the lost password, then why don't you have support reset the password for your users in the first place? Let support generate an OTP, send a mail to the user with a link (or password) which will allow him/her to login and change his/her password back to something sensible and there's no need for anyone to see what the password was...
NOTE: This comment was originally posted at StackOverflow.com by wimvds
