File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Testing and the fly likes TDD: How to drive the security of an application... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Testing
Bookmark "TDD: How to drive the security of an application..." Watch "TDD: How to drive the security of an application..." New topic

TDD: How to drive the security of an application...

Eric Nielsen
Ranch Hand

Joined: Dec 14, 2004
Posts: 194
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?
Lasse Koskela

Joined: Jan 23, 2002
Posts: 11962
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.

Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
subject: TDD: How to drive the security of an application...
It's not a secret anymore!