Industry Insights from Our Experts

Monthly Archives: May 2012

Dr. Neil deGrasse Tyson

Comments Off
Filed under Corporate Culture, Growth & Development

Dr. Neil deGrasse Tyson is a celebrated astrophysicist, and contemporary of Richard Dawkins, Stephen Hawking, and other thought leaders in modern science. Watch more on Dr. Tyson here

Patterns and Practices: Dependency Injection 101

Comments Off
Filed under .NET, Productivity, Software Architecture

This is the start of a series of posts that I’ll be doing on design patterns and best practices; it involves the use of common development concepts that I find a core part of development.  If your interested in following, they will be under the category ‘Patterns and Practices’.

One of the most common patterns seen in ASP.NET MVC is dependency injection (otherwise known as Inversion of Control).  Why? It loosely couples the parts of the application and really emphasizes the ability to unit test the separate layers of your application.  Why is unit testing important? Unit Testing, while it may add more time to your development, it allows developers, testers and the client to feel more confident that their code is doing what it is supposed to do.

So what exactly is dependency injection?  Many of us use patterns without even knowing that we are doing it, so this may sound familiar.  It’s actually pretty straightforward, using an instance of one class, it calls an instance of another class, but not by a concrete implementation, but rather by interface.  In essence, dependency injection, aims to reduce the amount of boilerplate wiring and infrastructure code that you must write and implement one of the core design principles, code to an interface not a implementation.

Here’s a simple example, the AccountService has to get a Account.   It looks like this:

public class AccountService
  private IAccountRepository _accountRepository;
  public AccountService(IAccountRepository accountRepo)
    _accountRepository = accountRepo;

  public Account GetAccount(int accountId)
    return _accountRepository.GetAccountById(accountId);

When we need the AccountRepository, we ask the dependency container to get it for us the instance based on what it’s mapped too.  Why does this benefit developers? It’s good because the AccountService doesn’t know or care about it gets an Account.  You can stub out what the methods and properties on a fake IAccountRepository might return, and test just the AccountService.  You can also use this to change the implementation of the IAccountRepository on the fly based on the type of storage you may be using.  Coupled with a framework such as Ninject, using dependency injection is a powerful pattern that should be used more often.  In one of my following posts I’ll go into using an example of using Ninject and a basic tutorial.

Article source: http://robbiemadan.com/2012/05/09/patterns-and-practices-dependency-injection-101/

Password Storage 101

Filed under .NET, Software Architecture

For all sites that store memberships in a database, security and encryption of sensitive data is extremely important. The password being the obvious field that would need to be protected.  It’s surprising to see how many sites still use plain text passwords or one-way hashes for password storage and don’t realize how easy those are to hack.  Most systems implement a format known as the “one-way hash”. This means that for any input that set the password, the same input will always result in the same hash. But, there is no mathematical method of taking the resulting hash and determining what the original input was.  Using a system such as MD5, hashing the password “qwerty” will result in the string “d8578edf8458ce06fbc5bb76a58c5ca4″, but if I give this same string to people to reverse, it will be impossible for them to determine that the string comes from “password”.

How does this work from an application perspective? Lets assume your building out a membership provider, when you first go to create the user you will store the password as a hash – so instead of storing ‘qwerty’ you will store “d8578edf8458ce06fbc5bb76a58c5ca4″. When that user logs in next, they will enter their password, the system will hash this password using the same algorithm and compare the hashed values, there is no way for you to compare the actual passwords without hashing them. This is quickly becoming standard practice.

Now what if I wanted to break into this account? The fact that the same input always generates the same hash tag means I can build up a database of inputs and outputs and use that to attack an account, this is called using a ‘rainbow table’, a database of inputs/outputs used to determine a hashed password.  Rainbow tables are easily found on the internet, so this one-way hash is not as safe as once thought.  If your interested in learning more about rainbow tables, check out http://ophcrack.sourceforge.net/.

So what’s the best way of stoping rainbow table hacking? Salting. By generating a random “salt” for every user and attaching it to their passwords before hashing, you have made the rainbow tables ineffective. For example, the password ‘qwerty123′ becomes ‘qwerty123AS@#$fgr=’ and is then hashed into ’8a7bb436d4849395072483f7715b7edb’.  Because the salt generates a random string and each user in your database has a different salt value, you have effectively removed the threat of rainbow tables.

If you want to read more about the inner workings of rainbow tables, take a look at this post: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Article source: http://robbiemadan.com/2012/04/26/password-storage-101/

Copyright 2018 by Quercus Solutions