• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 194
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic