Standing on the shoulders of giants. RSS 2.0
Page 1 of 1 in the Security category
# Tuesday, February 24, 2009

In November last year Kim Cameron wrote a series of posts about Project Geneva. It’s a little late, but still very interesting.

  1. Project Geneva - Part 1
  2. Project Geneva - Part 2
  3. Project Geneva - Part 3
  4. Project Geneva - Part 4
  5. Project Geneva - Part 5

And the PDF with the Identity Software + Services Roadmap.

Tuesday, February 24, 2009 11:09:28 AM (W. Europe Standard Time, UTC+01:00)  #    Comments [0] - Trackback
Security | Services
# Wednesday, February 18, 2009

Shawn Wildermuth wrote about his experience using ASP.NET MVC for a new site he developed.

  1. Part 1: Why ASP.NET MVC
  2. Part 2: MVC in action
  3. Part 3: Datavalidation

One of the things he does is sending "complex" models to the view to render, I'm not sure that's something you should do. I believe that you should stick so simple strings and have the controller do all the heavy lifting. It's a slippery slope you're stepping on, before you know, you're sending 'models' straight from the Entity Model to the view.

Not sure if that's really feasible (or the simplest/easiest) in all situations, but it ensure a clean separation between business logic in the controller and the model and the UI in the view.

More info:Enforcing Strict Model-View Separation in Template Engines (pdf)

Wednesday, February 18, 2009 5:56:48 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [1] - Trackback
ASP.NET | Security
# Monday, September 29, 2008

As Dare Obasanjo writes, there are a number of things you have to give thought when implementing OpenID on your website.

The real question you’ll have to answer is: how easy do I make it for users to participate on my website and how hard do I make it for spammers to flood my website.

But by delegating authentication to an OpenID provider, your implicitly trusting that provider to do the right thing when authenticating a user. Since, as Tim Bray speculated, there is nothing stopping a provider from “succesfully authenticating” any user URL, you can’t blindly trust any OpenID provider. So depending on the requirements you have for the authentication of your users, you can white-list providers you trust (like HealthVault), or if you’re only worried about bots, you can ask them to solve a Captcha. So the consequence is: since you can’t really trust all OpenID providers, so you force your user to register for a specific one (making their OpenID no longer their single online id) or make them to jump through hoops (by proving they are human).

Does OpenID really make it easier for a user to use your site? Or does it make it easier for you (the developer), since you can drop in a control and think you don’t have worry about authentication.

See also: OpenID is too hard & The problem(s) with OpenID

 

 

Monday, September 29, 2008 4:14:58 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0] - Trackback
Development | Security
# Thursday, July 17, 2008

Understanding Windows Cardspace This book (Understanding Windows CardSpace by Vittorio Bertocci, Garrett Serack and Caleb Baker) is not a guide how to implement Windows CardSpace in your website or webservice, but this book helps you understand the reasoning behind Windows CardSpace and how it fits in the Identity Metasystem. As such it is a much better book, than a book which just explains how to add a widget to your website to authenticate users, could ever be.

The parts of the book follow a logical structure. Part 1 discusses the problems we face on the Internet: identity theft, phishing and others and a technology independent solution is proposed. Finally in part 2 CardSpace is introduced and the implementation of CardSpace (both managed and self-issued) in websites and webservices is discussed. Part 3 shows the practical and business considerations when working with the Identity Metasystem and Windows CardSpace.

Even if you're a regular reader of Vittorio's blog, and are familiar with the Seven Laws of Identity, this book still has value. If you're not familiar with one or the other, you really should read this book, since it's the first book which really made me understand the problems we face on the Internet today with respect to identity and why and how Windows CardSpace provides a solution.

With the release of Zermatt this book really has proven it's value: Zermatt makes it much easier to implement a Security Token Service and a Relying Party, but it won't help you understand the concepts behind them or why you need to implement them (or not).

Thursday, July 17, 2008 9:29:21 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [0] - Trackback
Development | Reading | Security
# Tuesday, June 10, 2008

When hashing a password, you usually use a salt to to make it harder for an attacker to attack the password (see [0]), since the salt is needed to calculate the hash, the same salt is needed to verify a password.

The submitted Hash( Salt + Password ) must be equal to the stored Hash( Salt + Password ).

The common place to store the salt is in a separate field alongside the hash, but this may cause either one to get out-of-sync with the other. A better solution is to concatenate the salt and the hash and store both in one byte array.

static void Main(string[] args)
{
    RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();

    byte[] salt = new byte[0x10];
    rng.GetBytes(salt);

    Rfc2898DeriveBytes deriveBytes = new Rfc2898DeriveBytes("the password", salt, /*iterations*/ 5);

    byte[] passHash = deriveBytes.GetBytes(0x100);

    byte[] result = Merge(passHash, salt);
}

private static byte[] Merge(byte[] first, byte[] second)
{
    byte[] result = new byte[first.Length + second.Length];
    Buffer.BlockCopy(first, 0, result, 0, first.Length);

    Buffer.BlockCopy(second, 0, result, first.Length, second.Length);

    return result;
}

Extracting the salt from the hash is relatively simple:

private static byte[] ExtractSalt(byte[] hash, int length)
{
    byte[] salt = new byte[length];

    Buffer.BlockCopy(hash, hash.Length - length, salt, 0, length);

    return salt;
}

You use this salt to generate the hash for the password you want to check and after adding the salt to the end both byte arrays must be equal.

[0] See p.350-352 in Practical Cryptography by Niels Ferguson and Bruce Schneier why salting a password is a good idea.

Sample: HashSample.cs.txt (1.78 KB)

Tuesday, June 10, 2008 1:39:06 PM (W. Europe Daylight Time, UTC+02:00)  #    Comments [4] - Trackback
Codesnippet | Security
# Monday, March 03, 2008

This class is an addition to the html- and url-encoding in the HttpServerUtility class. Where the methods in the base framework, only encode a limited number of characters. The classes in the AntiXss class encode everything, that is not explicitly allowed. These means that everything but the following characters are encoded in most cases: a-z, A-Z, 0-9, (comma), (period), (dash), (underscore) and (space). 

[download: Microsoft Anti-Cross Site Scripting Library V1.5]

Monday, March 03, 2008 5:55:07 PM (W. Europe Standard Time, UTC+01:00)  #    Comments [0] - Trackback
C# | Security
Ads
About
© Copyright 2010
Paul van Brenk
Sign In
newtelligence dasBlog 2.3.9074.18820
All Content © 2010, Paul van Brenk
DasBlog theme 'Business' created by Christoph De Baene (delarou)