I've been getting better and better about sticking to a TDD based development approach. However I'm at something of a loss for how to write a useful test case for driving the development of storing hash/salted passwords.
I've been generally doing both Acceptance and Unit TDD. So I currently have accepance tests wrapping the account creation, and the login/logout process, along with the lower level unit tests. However at present passwords are not hashed nor salted. How do people tend to drive this development?
I mean I could easily write some trivial "security acceptance" tests asserting that the stored password in the database isn't the same as the password entered, but the simplest thing that would pass that woud be something like ROT-13.... The more "correct" test would be something that tested how brute-forcible the stored value was.... but that's going to be a difficult test to write, not to mention a long running one.... Now i guess I could write a test that checks if the database side password matches the known salt+hash for the entered password, but that seems a little silly ... and would hard code the choice of salt/hash algorithms in the acceptance test which seems unreasonable....
Or would you just skip the acceptance test in this case... not having a story that drives the security, just relying on the overarching true customer stories, that cover the feature and considering "security" one of those implementation details open to refactoring under the test harness, etc?
I could see myself writing tests for application code collaborating with the data access object responsible for the password hashing ("This object should invoke the DAO correctly") and tests for the DAO itself to verify that the hash the DAO would store to the database (combined with the used salt) matches the original password.