Amadiere.com

Fourteen and a half crazy frog burpers

10th February 2011

C#.NET & Classic ASP Password Hashing

Filed under: ASP.NET,C#,Classic ASP — Tags: , , , , — Alex Holt @ 9:02 pm

One of the things I’ve recently been working on is a solution to allow both a .NET application and a legacy VBScript / Classic ASP to be able to validate a specific username / password combination, comparing two hashed passwords. In the process, I discovered (with the help of Google and StackOverflow) that accessing .NET objects from Classic ASP isn’t really all that hard! But to the issue at hand: Password Hashing! Sorting this out from the .NET side was relatively easy. For the purpose of this post, here is roughly what I have at the moment.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Security.Cryptography;
 
namespace Amadiere.Com.Utilities
{
    public static class Cryptography
    {
        /// <summary>
        /// Encrypts a password based on the passed in Encryption method (SHA512Managed is a good starting
        /// point if you don't know which to use).
        /// </summary>
        /// <remarks>
        /// The passwordSalt parameter is required to ensure that rainbow tables cannot be used to
        /// lookup all usernames if the salt is discovered. This salt is OK to store in the database,
        /// along with the hashedPassword generated by this function.
        /// </remarks>
        /// <param name="password">The password to be encrypted.</param>
        /// <param name="passwordSalt">The individual grain of salt for that password.</param>
        /// <param name="method">The method by which to encrypt.</param>
        /// <returns>An string representing the hashed password (88 characters long).</returns>
        public static string Hash(string password, string passwordSalt, HashMethods method)
        {
            string siteWideSalt = "THIS IS A SITE WIDE SALT, BUT COULD BE A GUID";
            string encryptedPassword;
            switch (method)
            {
                default:
                    encryptedPassword = HashSHA512Managed(siteWideSalt + password + passwordSalt);
                    break;
            }
            return encryptedPassword;
        }
 
        /// <summary>
        /// One-way encrypts the password into oblivion. If the same password and salt are provided, the
        /// same end string will be churned out the other end of this sausage machine.
        /// </summary>
        /// <see cref="http://msdn.microsoft.com/en-us/library/system.security.cryptography.sha512managed.aspx"/>
        /// <example>HashSHA512Managed("bobsYourUncle_SALT-GOES-HERE");</example>
        /// <param name="password">Unencoded pre-salted password.</param>
        /// <returns>An 88 character string, representing the originally encoded password.</returns>
        private static string HashSHA512Managed(string saltedPassword)
        {
            UnicodeEncoding uniEncode = new UnicodeEncoding();
            SHA512Managed sha = new SHA512Managed();
            byte[] bytePassword = uniEncode.GetBytes(saltedPassword);
            byte[] hash = sha.ComputeHash(bytePassword);
            return Convert.ToBase64String(hash);
        }
    }
 
    public enum HashMethods
    {
        SHA512
    }
}

The Classic ASP side of things wasn’t as easy. There are no built in libraries for SHA512 (or in fact, many other password hashing algorithms). So I had a few options on how I was to proceed:

  • Abandon my choice of SHA512 and go with MD5 where there seemed to be a bit more usage in the community. I was reluctant to do this because it isn’t as good as SHA512.
  • Copy some code sample that has been created by someone else, that I either have to accept is OK, or spend a good deal of time understanding it and breaking it down bit by bit.
  • Create a custom COM object in .NET, register it in the GAC and reference that via Classic ASP.
  • Access the .NET functions directly from Classic ASP.

The last option won – because it worked, and because it meant a lot less maintenance and praying for things to keep working. This is the code that pretty much does the same as the above .NET code, but in VBScript.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Function Hash(strPassword, strIndividualSalt)
 
  Const strSiteWideSalt = "THIS IS A SITE WIDE SALT, BUT COULD BE A GUID"
  Hash = HashSHA512Managed(strSiteWideSalt & strPassword & strIndividualSalt)
 
End Function
 
Function HashSHA512Managed(saltedPassword)
 
  Dim objMD5, objUTF8
  Dim arrByte
  Dim strHash
  Set objUnicode = CreateObject("System.Text.UnicodeEncoding")
  Set objSHA512 = Server.CreateObject("System.Security.Cryptography.SHA512Managed")
 
  arrByte = objUnicode.GetBytes_4(saltedPassword)
  strHash = objSHA512.ComputeHash_2((arrByte))
 
  HashSHA512Managed = ToBase64String(strHash)
 
End Function
 
Function ToBase64String(rabyt)
 
  'Ref: http://stackoverflow.com/questions/1118947/converting-binary-file-to-base64-string
  Dim xml: Set xml = CreateObject("MSXML2.DOMDocument.3.0")
  xml.LoadXml ""
  xml.documentElement.dataType = "bin.base64"
  xml.documentElement.nodeTypedValue = rabyt
  ToBase64String = Replace(xml.documentElement.Text,VbLf, "")
 
End Function

As you can see in the VBScript example, I can create the .NET objects as I would any other type of object in VBScript, the difference comes in how I use them. Normally, in C#, you’d simply use ComputeHash() and there would be a number of overloads for you to choose from. As VBScript doesn’t have the concept of overloading, you have to use a crazy-mad way of accessing the specific overload you want – using an underscore. I’ve not really come up with a full-proof way of working out which is which (though, if I’m honest, I didn’t try much). I did however find out that they started ComputeHash(), ComputeHash_1() and ComputeHash_2() – I assume the numbers resemble the order they appear in Visual Studio when using intellisense for C# – but trial and error is normally good enough.

Hope this is of use to someone else! If anything, I’m sure I’ll find a need to do this again someday and I’m sure it’ll be useful for then! All this hashing has made me hungry!

Hashing passwords is hard! Let's eat!

Hashing passwords is hard! Let's eat!

20th November 2010

OpenID is NOT an ex-parrot!

Filed under: Human Factors,Usability,Websites — Tags: , — Alex Holt @ 2:01 pm

I’ve read a few Tweets recently that OpenID might be dead. Poppycock! OpenID is alive and kicking and as strong, if not stronger, than ever before.

An ex-parrot

What is OpenID? OpenID is a means of identifying that someone who’s visiting your site is the same person as someone who’s already been here. The was traditionally with Usernames and Passwords. If you successfully signed in, we assumed you were the same person. OpenID provides that level of authentication. It basically sends back a little message from the provider (e.g. Google) saying “Yo dude, not spoken in a while, but this customer you asked me about? Well it’s <INSERTGUIDHERE>. Just go ahead and log them straight in or create them a new account”. I now don’t need to store passwords as a website – this is great news!

Rob Conory (of Tekpub) recently wrote a very excellent article “Open ID Is A Nightmare” in which he proceeds to outline his case for why OpenID is turning into a nightmare for him. It’s an entertainingly written article in Rob’s quirky style that outlines his viewpoints as both a developer and as a business owner. The latter point, as he goes on to say, is the key criteria in why he’s reached the point he’s at at the moment.

A friend of mine was offering a ton of solutions to my Open ID woes over Skype the other day – insisting that it’s worth “investing in for the long run – the kinks will get worked out”. I sort of agree as a dev – as a business owner I couldn’t give a rat’s ass.

He is smart guy and has a number of very relevant points that anyone considering using OpenID should be thinking about. He had a number of OpenID unrelated issues (RPXNow downtime), but they all contributed to the main gripe he had about things: customers were unable to get into his site, a site they’ve paid to get access to. This is a key point. People are PAYING to watch the content over at Tekpub and through no fault of his own, they were unable to get in. The problem is easily wafted away, waving your hands in the air and saying “this is a user problem!”. The user created an account and then forgot which provider they logged in with in the first place! What fools! Let us all gather around a camp fire, eat sausages and laugh at their pathetic attempts at life. Except – lets not forget Tekpub’s audience. It’s techies. It’s developers. It’s people like us. If WE are capable of getting confused and lost as to what is going on – then the anecdotal ”mum” is going to struggle a hell of a lot more.

The bonus and one of the driving forces behind OpenID is the supposed “reduced friction” when creating an account with a site. As Rob points out, there is the issue because we can effectively get so little back from the OpenID Provider, that we’d be unable to dig out the account from the mass of other accounts with no additional data. The users account is effectively orphaned until they remember the provider they signed up with. Locked out and angry.

This debate took a whole other level of LOL when Scott Hanselman tweeted:

Is OpenID dead? Poor usability to blame?

For some bizarre reason, the Twittersphere decided that that was neither a question, but an official announcement from Microsoft that OpenID was about to fail. When in reality, it was in relation to Rob’s above post. Humourous to those unaffected, but I can imagine quite irritating and stressful to Scott.

What is wrong with OpenID?

OpenID is fantastic at doing what it’s does, but there is definitely room for improvement. Maybe not in OpenID itself, but in the way it is implemented. Some of the key things that I personally think developers need to consider when designing a login system that uses OpenID are:

  • Each Account should be able to have more than one Login method attached to it.
    This is something I think people have inherited from years gone by. Traditionally, an account has a Username and a password, and nowadays maybe an OpenID field too. In reality, the user should have the ability to add whatever authentication methods your site allows, to their account. A one-to-many relationship from Accounts to Logins. E.g. I might sign up with my Google account, then decide later that I want to create a Username and Password for whatever reason. Then a bit later, I spot you have Facebook Connect as an option – cool, I’ll attach my Facebook account to this site too. Now where am I? I have 3 ways of getting into my account. That’s great news – that’s a lot easier for me as as long as I guess one of them randomly when I’m prompted – I’m sorted.
  • Upgraded accounts require more information.
    The low barrier to entry should be set for standard users, but the minute you decide you want to upgrade them (make them a moderator or take payment for a service from them), you should require more information to make sure you can trace things when issues arise. Requiring this would have given Rob the facility to offer a “forgotten your password?” function on his login page that would solve the issue that paying customers couldn’t get in.
  • The ability to merge accounts.
    Unfortunately, people have lots of different accounts around the internet. They will probably, as Rob did when trying to access StackOverflow, get into your site using the wrong one and in the process, create a brand new account. In theory, what they wanted to do was log in as the correct one and then maybe add this new provider to their list of available logins. This is a tricky problem to solve, but it’s doable. You want to offer the option for a user to merge their two accounts, copying whatever appropriate data to their primary account. If you can achieve this, then you’re giving the users the ability to solve their own problems – great! And even if they don’t, you have a nice UI for doing it on their behalf.
  • “WTF does OpenID mean?”
    Seriously. I’m have no ready solution for this problem – but people don’t know what OpenID is and that’s because it’s techie. We probably need to drop the OpenID words from headings to merely part of the description for clarification, when displaying our Authentication Options. People should just be offered the choice of which site they want to authenticate via: Google, Yahoo!, Facebook or whatever. The issue still remains that people don’t exactly understand still what it means that they are being “authenticated by Facebook”. Half of them won’t care that they don’t know, but for the other half, you probably want to re-assure them of what it is that they are allowing you to do. I don’t want some random site I’ve just stumbled upon telling everyone on Facebook that I’ve done XYZ on website ABC. I think the OpenID selector is good – but is it perfect? Not really – it works for me and is very simple to use – but it doesn’t answer any questions you might have as a customer. As a developer, you need to do that. You need to ease their fears.

If I was creating a site now, would I use OpenID? ABSO-FRICKIN’-LUTELY! It’s great and makes it so easy to actually log into to a site. If I can transfer that ease-of-access to the customer, while not freaking them out – then I’m onto a winner! Is OpenID an ex-parrot? Not at all – it’s here for the foreseeable future in my opinion. And that is a great thing!

4th November 2010

HTC HD7 (Windows Phone 7) vs Apple iPhone 4 (iOS 4)

Filed under: Reviews,Windows Phone 7 — Tags: , , — Alex Holt @ 10:08 pm

4.3inches of beautyI’ve been a fan of the iPhone since the 3G came out and it’s been the first phone that I’ve actually enjoyed using throughout its entire lifespan. Upgrading to the iPhone 4 was something of a massive upgrade at the time as well – the speed difference alone is outstanding when compared to the 2 year old 3G! However, the one thing that’s always bugged me was the fact I needed an MacBook to develop on it. I can’t afford one basically, so that means I can’t develop on their platform. Fair enough, it’s their call and I’m not overly worried about it for now. However, when Microsoft announced that they would be launching themselves into the mobile phone operating systems market (and Windows Mobile 6.5 doesn’t count as “being in the market – I’m sorry) and that I’d be able to write apps written in Silverlight and C# – I was sold. I had to get one of the devices. I whittled down the time to launch by drinking coffee and occasionally leaving the house. Eventually, I managed to get hold of a device and begin to use it. I thought I’d write my observations down for anyone interested to know how they both compare.

Why did I get the HTC HD7:

There were a number of reasons. Primarily because the 4.3inch screen is great (it still fits in my pocket just fine) and more importantly, it had 16Gb of space. With none of the WP7 devices offering SD Card readers at launch (in the same way iPhone’s do not), space was at a premium. Having been limited by the iPhone 3G 8Gb before, I wasn’t going to make the same mistake again quite so lightly. All the reviews I’d read had given the device good reviews and it seemed like one of the best devices that I could have got at launch time.

How did they compare?

Screen Quality: You know, I really can’t find any differences between the two devices. Maybe it’s my untrained eyes, but the WP7 is definitely in the league with the iPhone 4 and it’s retina display. Touch wise, they both behave remarkably well and are extremely responsive. I haven’t found myself pressing harder because my gestures weren’t detected correctly.

Sound Quality: I was surprised about this one and I never actually thought about it too much in the run up to buying it, but the quality of the audio produced by the HD7 far outstrips that of the iPhone 4. I listed to a bunch of my songs, including Bat Out Of Hell (which I’ve listed to on countless different formats) and the richness of the sound is amazing. Coupled with the good use of surround sound, the HD7 made for a great listening experience. I didn’t particularly like the earphones that came with it though, but then, the same can be said about the iPhone ones… so Meh.

Maps: I think unfortunately, this might something odd with my location, but the HD7 picks up my location as 12 miles from where I’m actually sat. A touch inconvenient for a “where’s my nearest” feature. The Windows Phone 7 devices all use Bing maps and the iPhone uses Google maps. For the most part, they behave exactly as you’d expect them too and they are good for what they do. The iPhone really begins to excel again with it’s built-in street view.

App Store: Unsurprising I guess that iPhone would win this battle – it’s had almost 2 years of a headstart on the Windows Phone 7 market and in that time has amassed a horde of really amazing apps. As for the Marketplace itself, I think neither really excels at helping users find the applications that they might like. Genius in the Apple AppStore has never really given me much luck, and while the Microsoft version is currently an easily navigated setup, I fear that once content begins to flood in, some of the ease-of-use will quickly wash away.

App Development: As an ASP.NET and C# developer I’m going to be bias on this one. But I do consider the platform to be a much more simplistic way to develop. The pain of Objective-C is that the developers must delve quite low to the OS, performing their own garbage collection and other similar tasks. Silverlight, which is used by Windows Phone 7, is a very different experience indeed and you can spend the time concentrating on your App. Visual Studio 2010 – it really is awesome and to be able to have a truly awesome free development environment cannot be under estimated. And while Microsoft is untested in this water, it’s Application Acceptance Guidelines appear to be a lot more black and white than Apple’s which are a notorious issue.

Camera: To be honest, I’ve not really exausted the tests on the camera yet, but from what I can tell – the iPhone wins this battle. It’s HDR function is actually pretty nifty and as a result, the pictures seem to be some of the best I’ve seen from camera phones. The HD7 isn’t quite as good. Sure the pictures are ok, but inside, I’ve found things are a little grainier than the iPhone which has been frustrating.

Web Browsing: The experience is quite similar between the two browsers. Certainly both are able to pinch and zoom and scroll and throw themselves around the pages without too much hassle. But I have found that currently, a lot of websites (including Google Reader for example) treat the HD7 as a primitive mobile browser and show it a very reduced and scaled down browser experience. This isn’t an issue with the phone and given time, I’m sure that Google will update their detection mechanisms and there will be fully fledged Smart Phone RSS reading. Other than that, I would say that I’m a little disappointed with the limitation of the favourites (there appears to be no way of organising the list) and more specifically at O2 for making Yahoo! the default search engine when typing into the browser address bar (an horrific pain in the posterior given that Yahoo! don’t detect that it’s a decent phone either!).

Other things I’ve noticed about the HTC7:

  • The Calendar is great. In additon to putting things in your diary with alerts to remind you when they are about to happen – your events in general appear on your home screen, showing you today and tomorrow’s events. Giving me a fighting chance of remembering the cat’s vet appointment more than 15 minutes beforehand!
  • The ringtone’s couldn’t be changed, or at least, not that I could spot.
  • No iTunes means no stupid updates pestering me to install Safari or Mobile Me or other Apple products which I have absolutely no desire to use. iTunes is like the modern day equivalent of Real Player from a few years ago. Zune is a nice enough experience. I found being about to sync my phone with the music I wanted was a lot easier and less hassle than iTunes. The same with my Podcasts and Videos – a great step forward from the alternatives.
  • Facebook integrated with my contacts is fantastic – it makes the whole experience seemless. While I don’t frequent Facebook overly often, I have a good number of friends and with all this merged into my phone book, I can on a whim simply write on their wall as easily as sending them a text. You can of course, take the alternative route and only import Facebook contact information for the people you already have Contacts for – which might tickle the fancy of more people.
  • The context search is useful. One of the three touch buttons at the foot of the phone (“Back” and “Home” being the other two) is for search and depending on what you are doing at the time, it searches different things. E.g. when in your People Hub (phone book) is searches for a contact, or when in the browser, it searches the web. Useful.

Summary:

The bottom line is that currently, I’m missing all the Apps that I had on my iPhone. Plain and simple. For that reason alone, the Windows Phone 7 is second favourite at the moment. But as this is something that I imagine will change in time, I do think that the phone will get better and better. And I for one, am really looking forward to seeing if Microsoft can whip Android into a real challenge to the iPhone and more importantly, challenge the iPhone itself! More competition in a marketplace is often a great thing – and I that’ll be true here.

« Newer PostsOlder Posts »

Theme designed & built for Amadiere.com by Alex Holt. Powered by WordPress