Security

SHA-1 has been broken...what's the big deal?

Blog Author — Thu, 17 Feb 2005 03:21:00 GMT

Slashdot recently reported on a post on Bruce Schneiers blog which reports that the SHA-1 hashing algorithm has been ‘broken’ by a team in China (wonder why they were working on it ) – this is a pretty big deal; SHA-1 is the NSA / NIST standard for hashing algorithms right now – though recently they announced that they’ll be recommending the stronger SHA-512 and SHA-256 variants (properly called SHA-2 variants) soo, – good timing! For most common applications though where there’s a possibility collision after 2^69 ( 590295810358705651712 ) hash operations compared to 2^80 (1208925819614629174706176) really isn’t that bad then if you’re currently using SHA-1 I wouldn’t do a panic change (though next time you might want to change over to SHA-256 / 512).
To try to clarify what this means, in order to generate the same hash code from two distinct inputs (so you’re comparing one hash against the other) would mean hashing 590295810358705651712 times rather than 1208925819614629174706176 times with what was previously thought to be the possibility of collision. If you’re betting your life on a hashing function (so for instance you have a document containing the nuclear key codes signed only with a SHA-1 hash) I’d seriously considering moving to a longer one (SHA-256) – if you’re just storing passwords for a Barney fanclub site…I wouldn’t worry especially. Of course if you’re really paranoid (ooh, the NSA developed SHA!) you’re probably using Whirlpool already!
UPDATE: If you really want to check out some amazing .NET implementations of pretty much every encryption / hashing function on the planet take a look at this , currently has MD2, MD4, MD5, RIPEMD128, RIPEMD160, RIPEMD256, RIPEMD320, SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, and Tiger hashes (well message digests which are a little different but still...lots!)!

Eric Rounds it off

Blog Author — Mon, 14 Feb 2005 22:03:00 GMT

Following on from Part 3 , Eric Lippert has posted Part 4 of his series of posts on Hashing and security he also discusses Keberos...If you're really into this sort of stuff but not from an overly mathematical background (like me) the best book I've found on Cryptography is Practical Cryptography by Niels Ferguson and Bruce Schnier this covers pretty much everything the non-NSA employee could need to know about this topic.

Eric Lippert posts part 3 of his series on password security

Blog Author — Thu, 03 Feb 2005 23:19:00 GMT

THis is a great series of articles - I posted on this previously - part 3 covers why you should use a salt (and I've mentioned how to generate them recently ) . These really are excellent articles!

Simple password hashing method...

Blog Author — Thu, 03 Feb 2005 18:47:00 GMT

Oh, thought I should mention, if you're just looking for a really simple way to generate an alphanumeric hash for a password (as opposed to a byte array), the ASP.NET framework has a handy (if extensively named) method for doing this: FormsAuthentication.HashPasswordForStoringInConfigFile

Gimme some Hash!

Blog Author — Tue, 01 Feb 2005 00:48:00 GMT

Just been reading what looks like the second part in a series on security from Eric Lippert on the use of hashes for protecting password information (first part is here) . I find this especially interesting since I've recently designed a system which uses salted-hash (as opposed to sticky-black hash which is a whole different thing ;-)) as a method to protect user passwords. As it turned out it wasn't all that easy to do this in .NET ; of course it might just be me...anyway here's the little function I came up with for hashing passwords (with a dash of salt...)

UPDATE: Simpler version is below with much of the duplication removed - in addition, the defaults are smaller and quicker (16 byte salt and SHA-1 hashing algorithm), you can change either of these - any length of salt and any of the HashAlgorithms (SHA256, MD5, etc...). Hope someone finds it useful...

using System;

using System.Security.Cryptography;

using System.Text;

namespace HashMaker

{

public sealed class PasswordHasher

{

private const int DEFAULTBYTECOUNT = 16;

public static string GetRandomString()

{

return Convert.ToBase64String(GetRandomBytes(DEFAULTBYTECOUNT));

}

private static HashAlgorithm GetAlgorithm()

{

return new SHA1Managed();

}

public static byte[] GetRandomBytes(int byteCount)

{

byte[] byteBuff = new byte[byteCount];

RNGCryptoServiceProvider rn = new RNGCryptoServiceProvider();

rn.GetNonZeroBytes(byteBuff);

return byteBuff;

}

public static byte[] GetHashedPasswordBytes(byte[] passwordBytes, out byte[] saltBytes)

{

saltBytes = GetRandomBytes(DEFAULTBYTECOUNT);

return GetHashedPasswordBytes(passwordBytes, saltBytes);

}

public static byte[] GetHashedPasswordBytes(byte[] passwordBytes, byte[] saltBytes)

{

byte[] combByt = new byte[passwordBytes.Length + saltBytes.Length];

passwordBytes.CopyTo(combByt,0);

saltBytes.CopyTo(combByt,passwordBytes.Length);

Array.Reverse(combByt);

HashAlgorithm sm = GetAlgorithm();

byte[] buffArr = sm.ComputeHash(combByt,0,combByt.Length);

return buffArr;

}

public static byte[] GetHashedPasswordBytes(string password, out byte[] saltBytes)

{

byte[] passByt = UnicodeEncoding.Unicode.GetBytes(password);

return GetHashedPasswordBytes(passByt, out saltBytes);

}

public static byte[] GetHashedPasswordBytes(string password, byte[] saltBytes)

{

byte[] passByt = UnicodeEncoding.Unicode.GetBytes(password);

return GetHashedPasswordBytes(passByt, saltBytes);

}

UPDATE...AGAIN: Umm...I'm going for the 'most updates to a single post' award OK? Anyway, just realised I forgot the little byte array comparison method after I updated this - in this context you'd need this script when comparing the stored array to freshly calculated one from the data entered by the user - you could convert to a Base64 string then just do string.Compare...but this is faster:

private bool CompareArrays(byte[] Arr1, byte[] Arr2)

{

if (Arr1.Length == Arr2.Length)

{

int i = 0;

while ((i < Arr1.Length) && (Arr1[i] == Arr2[i]))

i += 1;

if (i == Arr1.Length)

return true;

}

return false;

}

Right, that's it, not more updates...promise!

The ASP.NET vulnerability...not!

Blog Author — Fri, 08 Oct 2004 01:29:00 GMT

So, Slashdot got a hold of the story about the ASP.NET vulnerability (the backslash bug), as usual they're loving it over there. What I haven't seen much of though is mention of the fact that many sites were never affected by this - reason? URLScan for IIS 5 and IIS 6 (which incorporates much of URLScan already) have always blocked this type of attack - remember, URLScan was released in 2001 and it blocks a host of malformed URL type attacks (there've been a bunch before).
The current Microsoft advice is to add some code to each ASP.NET application, fine - but if you have a properly configured URLScan or IIS 6.0 - you've never been at risk of this attack. Whilst I'm pretty disgusted that such a simple error got through testing (and let's face it this will probably cost a few companies developing with ASP.NET a bit of business) it does reinforce the fact that you should never rely on a piece of code you can't inspect personally for your application's security.

UPDATE: The piece below has some new info - including an HttpModule which can patch all your apps...

Updated info on the reported ASP.NET vulnerability

Today we posted updated information to http://www.microsoft.com/security/incident/aspnet.mspx with additional information about the nature of the reported vulnerability and an additional mitigation best practice. Our additional guidance is an HTTP Module that you can install onto a server that will mitigate all ASP.NET applications on the box and protect them against canonicalization issues we knew about at the time of publication. This is easier then updating the global.asax for each application and if you are dealing with a whole lot of servers much easier to deploy. You can grab the MSI installer for the HTTP Module at http://www.microsoft.com/downloads/details.aspx?FamilyId=DA77B852-DFA0-4631-AAF9-8BCC6C743026. There is also a new KB posted at http://support.microsoft.com/?kbid=887289 that describes how to deploy the MSI and HTTP Module.

We will continue to update the landing page as new information or guidance becomes available, so keep checking back.

posted on Thursday, October 07, 2004 5:34 PM

DNS Problems now resolved - and on to some reflection stuff

Blog Author — Fri, 20 Aug 2004 22:22:00 GMT

Well, seems my DNS provider uses some kind of procedure which can be prone to failure. Anyway, my DNS stuff is now functional again- yay! My plan for today is now to move on to playing a bit more with reflection and attributes...this could get interesting! Oh, in case you're wondering, I'm playing with the Provider Pattern for a project I'm working on, also looking at doing some sort of low-maintainance security model for 'operational' security on method calls; so I can define that a particular method requires that my system provides the 'Edit' permission for that user / object before allowing the method call...probably going to involve extending the Provider Pattern to allow for permission attribute introspection as part of the provider...may be interesting

Eliminating SQL Injection...

Blog Author — Sun, 11 Jul 2004 03:06:00 GMT

Read on Stefan Demetz's blog about a movement afoot to lobby Microsoft to change how textboxes allow passed in data. See here for the comment. Sorry but I think this is a plain awful idea and is very reminiscent of the horrible RequestValidation nonsense introduced in .NET 1.1. I am in favour of a simple method of encrypting and validating QueryString input such as presented here (apart from the fact that it used 3DES - DO NOT DO THIS! 3DES is MUCH slower and not as secure as AES). So what's my problem with changing the default behaviour of input controls? Simple, three things:

1. If it happens, this will likely be implemented in such a way that it breaks exisitng applications (this also happened with 1.1 and as a result there's still a few apps still running 1.0 out there).
2. If it is done it would have to be totally bulletproof, otherwise every app would rely on a single security mechanism - which is so NOT a good idea!
3. Abdication of responsibility by developers, if this were done so it had to be explicitly enabled either at web.config or in page level, I would be much happier. Put simply I prefer developers know what's happening in their code and therefore are more likely to be aware of any issues surrounding it.

Oh, and Microsoft, if you do do this, don't do it like Viewstate where you hardcode 3DES encryption with no way of replacing your implementation, at least make it a Provider!

For future reference...pronouncable password generator

Blog Author — Fri, 02 Apr 2004 22:46:00 GMT

From Gareth Brown, a very handle little tool which I can think of a dozen uses for right now - a pronouncable password generator.

Security through Diversity - why I don't like ValidateRequest

Blog Author — Tue, 02 Mar 2004 23:10:00 GMT

I'm aware this is a fairly controversial viewpoint, I should explain some of my own background as a precursor to my dislike of this. In the bad old days, I was a penetration tester; I ran my own little company which provided this service to a number of customers, my job was to essentially crack / in other ways break web sites and 'other' networks. In my time as a pen tester, one of the most annoying things was flaws which could effect a huge number of sites / installations at the same time, classics were Cisco password flaws, Perl and PHP security flaws and, worst of all, backdoors in Web Applications. So, as time has progressed and I moved more into actually writing applications rather than breaking them I've always been aware that application security systems should not be inherently trusted, while less likely to be flawed than some ad-hoc implementation, that flaw can be potentially more serious since is is almost certain to become widely know and exploited within a very short space of time.
That's part of the problem I have with ValidateRequest, it provides a crutch, a shortcut for the lazy developer. OK, it is useful, it blocks any incoming 'html' like request information - and will therefore block many XSS (Cross Site Scripting) attacks which can be pretty serious. Problem is, flaws have already been found in this and the patch is not obvious / easy to find (had you heard of it before?) - so not there's an issue which will effect ALL ASP.NET 1.1 sites which rely on this feature to protect them from XSS attacks. Even worse, how many sites do you think will take additional precautions over and above this to protect their input - do you know if it protects you from SQL Injection attacks, Buffer Overflow attacks and various others (including such gems as simple backdoors, Cookie Hijacking and the like).

My point is, in my view, responsibility for application security should lie with the developer - they should understand and plan for the consequences of choices they make in application design. Read a book like Michael Howard's Writing Secure Code [US] - get to know where the vulnerabilities in your application may lie and compensate for them.
In short, don't rely on things like ValidateRequest as your only line of defence - use it by all means, it will stop many things getting through which you may not want - but learn what it actually does and what it doesn't.

For instance, what will you do when you only want certain tags to get through and not others? You may need to look at something like this (I wrote this a while ago - I'm not claiming it's entirely or even partially foolproof - just proof of a concept).

Anyway, views always welcome - how much application security should you delegate to the framework - has anyone else come up with their own little 'security' toys which they use to validate user input?

UPDATE: Forgot to mention, if you're still on IIS 5.0 be sure to check out IISLockdown - you MUST have this installed, it will help you avoid a huge number of security holes, known / future...if you have IIS 6.0 , it's already there but be sure to check out this to avoid any development problems...