Greenfield Application Development (GAD)

I’ve been very busy of late, focusing on prototyping little things (along with some personal things). This is the first time I’ve had a real level of control of how a greenfield application will be built. In the past I’ve experienced too many obstacles to achieve a desirable outcome.

Dilbert Failure

But now a twist of fate along with; a bit of planning, brainstorming and prototyping is on track as a “greenfield” application.

Green Field

I can’t go into the details of the application and it’s operation, so I thought I’d share a little summary list of things we’ve considered, discussed, and even decided* upon for our application.

*Decided as far as we haven’t changed our mind yet.

Disclaimers
1. This is by no means a complete checklist – but if you’ve got the opportunity to be part of creating a new application which has some degree of flexibility in terms of deadline pressure and implementation. When I say flexibility I mean ability to make choices without intense time pressure or a lot of other external pressures. I hope we’ll discover if the time we’re taking was viable based on our final delivery time frame and delivery outcome.

2. This is biased towards patterns and technology common in the Microsoft.NET space.

Once there are some more interesting prototypes/concepts, I’ll post some lessons learnt or just cool solutions (if we do end up producing something “cool”).

So onto the list.

Consider:


How long you spend on:

  • A pure research phase.
  • Brainstorming sessions with stakeholders / domain experts.
  • General discussions amongst developers

When to:

  • Lock down some big decisions, only to change course if it’s an impedance.
  • Restrict new ideas from even more stake holders, (people with opinions).

How to conduct the:


Choice of:

  • System architecture.
  • Presentation platform; web, desktop, mobile.
  • Presentation framework; ASP.NET MVC, WPF, Silverlight.
  • Development patterns; MVC, MVP, MVVM.
  • IoC container.
  • Mocking and Unit-Testing frameworks.
  • ORM frameworks.
  • Database approach in general
  • Using a non-tradition database technology along the lines of NoSQL.

How many:

  • Initial features you need to deliver, before you have a beta.
  • Newish techniques to adopt/use. (New to developer community or just your team).
  • Beta technologies to take a bet on.

but most importantly, how you will deliver:

  • Business/customer value.
  • A pleasant end user experience.
  • Support and help.
  • Confidence in the system.

Obviously several of the above choice branches are reasonably trivial, and come down to personal preference and familiarity, clear cut example is the choice of a unit testing framework.

As a summary point for our choices, the current set of “locked down” technology choices revolve around:

  • WCF – for a distributed deployment of system services.
  • ASP.NET MVC 3 – the way to go on the web space with .NET 😉
  • NHibernate – a popular ORM in the .NET community, and due to some unpleasant experiences with other ORMs in the past.
Advertisements

Taking a concept way too far, password similarity prevention.

I’m hooked on a very entertaining podcast called Security Now, I’ve been listening for a few months now if you’re looking to expand your podcast library, I encourage you to check it out. With security in mind there’s a small undertaking at work to strengthen the login and password aspects of the web application. This got me thinking about how far you could actually take securing a login process, I’m sure with a brain storming session of security aware developers a lot of wild ideas could be hatched, so I thought I would explore one that came to me.

In an ideal world we would all have perfect memory and an extremely strong randomly generated password would be easily remembered, but that’s not the case.

Users are already encouraged to change their passwords regularly, and often (at least in the corporate world) systems track N-number of your previous passwords and prevent them from being selected again. But this password history checking is done in a very secure fashion of having only the password hashes stored.

So how about we take that concept much further…
When a user changes their password and submits it for processing, the system determines if this password has “been seen before”.

If so the user is presented with such a message:

Invalid password choice.
Your newly entered password is similar in theme one of your last 10 passwords.
Please select a new and different concept for your new password.

The simplest examples as to what would triggers this are:

  • One of your previous passwords was the name of a female. Please don’t select another female name.
  • One of your previous passwords was the name of a fruit. Please don’t select another fruit.
  • One of your previous passwords was a type of vehicle. Please don’t select another vehicle.

Leaking Information Concern

At this point, we’re crossing a line and storing data that leaks information about the users previous passwords. In this approach only previously used categories would be stored and associated with the user, and of course the hashed values of the previous passwords. So it does raise the question if this additional data about passwords, approach breaches the current level of acceptable “salt and hash” rules for passwords.

Over-coming the leak
I believe the ‘leak danger’ is mitigated by never storing the current passwords ‘category’. This can be achieved by the approach of requiring a user to enter their current password when changing to a new password. So only in the process of a new password being ‘approved’ is the system aware of the ‘previous’ passwords category, and then the fact that it’s a ‘previous’ password can’t it’s ‘category’ be safely stored.

This workflow would work in such a way.

  1. Categories of all but current password are stored.
  2. User is on ‘active’ password, category unknown.
  3. User has selected (or is required) to update password.
  4. User enters existing password.
  5. Category is determined.
  6. User enters new password.
  7. Category also is determined.
  8. These 2 temporary categories are compared with the last N stored categories.
  9. If there are no category collisions – password is updated.
  10. Old password category can now be stored as that password is no longer active.
  11. Newest password category is discared (i.e. not persisted).

Another concerning factor that would be attempting to categories a password that failed to match a category, and if this would be considered a breach of the users trust in supplying new passwords. As such a task may not easily be handled by an algorithm and would require humans selecting categories for unmatched plain text passwords. Again this need not be in an exact loop directly traceable to a specific password, but just as seed data for new future categories.

Implementation ideas for deciphering and categorising the previous password:

  • Common letter to number replacements would be simple pattern match and replace.
  • i.e.: ‘1’ for ‘i’, ‘3’ for ‘e’, ‘4’ for ‘h’, etc
  • Making use of a dictionary for simple word matching.
  • Another dictionary of names of people.
  • Categorisation of the dictionary words, into a large set of common categories.

Going even further to reference human resources style data stored on the individual, but could go in the direction of breaching information leakage concerns.

  • Please ensure not to use names of family members as we have access to that information.
  • We detected your spouse and children are “Jane, Sam, and Amy” your password contains a variation of their names, and is not acceptable.

With such wide reaching password checks to prevent the user from selecting anything even remotely guessable, would force the user to select from
– Something like the GRC equivalent strong password (high entropy)
– Or chaining random words

Realistic Summary

If this was implemented with they way users currently choose passwords, it would just be a major source of frustration, along with a probable fear of information leakage of older passwords. So this was just an exercise in walking through a idea on password security. If you have either negative or positive comments on this idea I welcome you to share them.