Feeds:
Posts
Comments

Glad to see it moving along, hopefully the browser support for it will continue to solidify. These standards were a key part of delivering some json web services and making them securely available in the cloud. Very diligent of them to mention me for a meager contribution to the specification.

http://www.w3.org/TR/cors/ (W3C Candidate Recommendation 29 January 2013)

Your password managers are all good products, but suffer from one key flaw, if my PC is compromised, I’m better off without them.

In some cases I’d be lucky, and the thieves would only manage to capture a “master password” as I enter it to access one of my passwords. In the worst case the thieves make off with my entire password database and destroy my digital life.

There is potentially a simple solution to this problem though. Simply put I can trust my phone more than I can trust any of my PCs. When I need a password on my PC, my phone is normally sitting next to me. I would like my password manager (on my PC) not to actually have access to the passwords, unless I authorise that access on my phone, and even then it would only have access to one particular password for a short period of time.

It may sound clumsy, but sliding a push notification on my iPhone home screen and entering my phone PIN would be a whole lot easier than typing in a 30 character master password!

Yours in anticipation ;-/

Useful if your application needs to limit access based on IP address.

The key to solving the problem is the BigInteger class (System.Numerics.BigInteger), an integer of unbounded size. Once you convert your IP addresses (IPv6 or IPv4) to BigIntegers they can be quickly compared (don’t forget about endianess). The .net class IPAddress (System.Net.IPAddress) does the heavy lifting of parsing the addresses from a string for you. One thing to make note of is that you should compare like for like, don’t test an IPv4 address against an IPv6 address range.

There is a growing trend in applications being built in HTML5 where the screens are built in HTML5/CSS3 and hooked up to data via services with JavaScript. From Bing to Amazon Kindle Cloud Reader and Angry Birds, the big boys are moving steadily in this direction for more than just their websites. Let’s not forget the much hypothesised pending PDC announcement regarding Windows8 and HTML5 (see buildwindows.com).

For a small inkling of what HTML5 can mean, I strongly recommend you check-out slides.html5rocks.com (in google chrome or safari).

The days of screens in HTML applications being pages generated by servers containing screen layout mark-up and data are nearly over, whether it’s your google/bing search results or social networking news feed, all this is happening over JSON web services.

While the UI control industry is still some way away from having polished products to support building these applications cheaply, there have been some interesting recent developments.

The move to HTML5 based UI brings with it some great new opportunities, and of course, just as many risks and challenges.

SOA UI Controls from ComponentArt and Telerik

Recently two of the biggest control vendors for asp.net web app controls have added some interesting client side service/data-binding. While neither of these quite gets to the full vision or potential of HTML5 UI, they certainly make some very positive steps in the right direction.

1) ComponentArt have released a suite of Silverlight and ASP.net “AJAX” (JSON) controls that data bind on the client side. You build and publish your service interfaces once, then connect Silverlight and HTML based controls to them. The ComponentArt implementation is somewhat limited in the services it can bind to, services need to be defined in specific ways for them to be useable without some custom client side code.

DEMO: http://soaui.componentart.com/ajax/datagridmessagebrowser/

2) Telerik have added declarative client side data binding support for JSONP / ODATA (http://odata.org), you simply point your controls at ODATA data sources and configure the data-binding. The resulting HTML and javascript produced by Telerik takes care of the rest, pagination, filtering etc. etc. all happen client side.

DEMO: http://demos.telerik.com/aspnet-ajax/grid/examples/clientbinding/defaultcs.aspx

One of the main shortcomings of this service based approach over HTTP is that there is inherently a two connection per client limit. For simply paging through a grid of data, per the examples above, this will not pose a problem, but as your interface becomes more advanced this two connection limit will really start to bite (as many developing in Silverlight have found).

WebSockets

Why should we care about WebSockets? Put simply, it’s all about throughput! Web-sockets authenticate once at the start, are full duplex and support message based communications; this means a significant increase in throughput is possible.

HTML5 SOA MVVM MVP

* Q – Query / Request, P – Processing / Latency, R – Response

Message based services over WebSockets truly have transformational potential for HTML5 UI web application development. The key of this transformational possibility, is that message based transport of client-server communication will support modern UI software design patterns such as MVP and MVVM directly in the browser.

Web sockets do come with hidden dangers for application developers though; there is a risk of turning back the clock, moving away from stateless web services, and bringing in a new era of unnecessarily long running client-server connections. With the right patterns and practices these pitfalls can be avoided of course. Web sockets could be kept open only for short bursts of communication, meaning services can still be stateless, web farms can still manage load on a per connection basis and users wouldn’t be tied to specific hosts for long periods. Hopefully as UI control vendors leverage this technology we will see patterns, practices and frameworks for the architecturally sound use of web sockets.

WebSockets are still somewhat a way off for most desktop targeted browser based applications (due to lack of IE support). Applications targeted at apple/android tablets/phones can certainly make use of this technology today.

Adapting Existing Services

Don’t panic! This does not mean throwing away your current web services, the ramifications of WebSockets on existing JSON web services are not as drastic as you might expect. In fact, the SOA design principles on current services should be maintained and continue to be used for new services.

All your existing services can easily be re-published via simple message bus endpoints. Silverlight and JSON web services are already inherently asynchronous so it is not a big change for your existing client or server side code. The message bus is just another type of transport for calling your existing services.

Your client would simply send its “request” messages to a message bus endpoint with a wrapper containing service destination information. In SOAP, the SOAP headers already contain all the information needed to achieve this. For JSON services, a simple wrapper object containing an endpoint URI and the request message body is all that is needed.

JSON Message Bus – Under the Covers

Looking at the specifics of this in JSON it is easy to see this is not a big leap (this sample is simplified to show a single http connection instead of two which would sometimes be possible, please note protocol details have also been simplified).

Regular JSON Web Service – Standard HTTP Request / Response Web Services

Request Response
POST /app/service1/json/method1

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

{“parameter”:3.45}

HTTP 1.1 200 OK

Response-Headers: Various-values

{“result”:6.78}

POST /app/service1/json/method1

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

{“parameter”:3.45}

HTTP 1.1 200 OK

Response-Headers: Various-values

{“result”:6.78}

POST /app/service1/json/method1

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

{“parameter”:3.45}

HTTP 1.1 200 OK

Response-Headers: Various-values

{“result”:6.78}

JSON Message Bus Service – Full Duplex Two Way Stream of Messages

Request / Client-to-Server Stream Response / Server-to-Client Stream
CONNECT /app/MessageBus/json

Host: hostname.example.com

Authentication-Headers: Values

Request-Headers: Various-values

HTTP 1.1 200 OK

Response-Headers: Various-values

{“service”:”service1/json/method1″,

“body”:{“parameter”:3.45}
}

{“service”:”service1/json/method1″,
“body”: {“parameter”:3.45}
}

{“service”:”service1/json/method1″,

“body”: {“parameter”:3.45}

}

{“service”:”service1/json/method1″,
“body”: {“result”:6.78}
}

{“service”:”service1/json/method1″,

“body”: {“result”:6.78}

}

{“service”:”service1/json/method1″,

“body”: {“result”:6.78}

}

I’ve written some nice flexible standards based implementations of various Base32 and Base64 encoding/decoding methods. These are designed to encode binary data to plain text, and decode the resulting text back to the original binary. Useful when you need to transfer binary data through technologies that only support text (such as including binary security tokens in URLs).

The code is available up on codeproject.com

Base32Url encodes with only the characters A to Z and 2 to 7. No hyphens, underscores, pluses, slashes or equals are used, making it usable as a URL token in almost all circumstances. Base32Url also supports custom alphabets. A custom case sensitive alphabet with only consonant (non vowel) characters can be used to ensure your tokens do not contain accidental profanities. The following is an example that avoids vowels, the letter L and has no numeric characters: BCDFGHKMNPQRSTVWXYZbcdfghkmnpqrs.

Base64Url is more compact than Base32Url and it is almost always usable as a URL token or file-name. The only non alpha-numeric characters Base64Url contains are the hyphen (-) and underscore (_) characters, neither of these need further encoding for use in URLs or file-names.

Base32Url (Encoder / Decoder)

The default mode for the Base32 encoder/decoder is Base32Url. This uses the standard Base32 alphabet encoding but omits padding characters and is case insensitive.
Supports standard Base32 with padding characters (=) per Base32 from RFC 4648.
Supports the Base32 extension / alternate alphabet z-base-32

Base64Url (Encoder / Decoder)

Based on the standard .net Base64 encoder
Uses the URL-Safe alternative Base64 alphabet from RFC 4648
This is not the same as Microsoft’s HttpServerUtility.UrlTokenEncode.

Further Information and Usage

There are other implementations of base32 encoding out there but I feel the code of this base32 implementation is much simpler (far less code involved in the bit shifting calculations).

The base64 implementation I have here is a little hackish, but a far better option than the one you get from Microsoft.

The result you get from HttpServerUtility.UrlTokenEncode is essentially base64url, but instead of truncating the padding, they append a digit (of 0, 1 or 2) indicating the number of padding characters removed.

Usage:

Base32Url.ToBase32String(Encoding.ASCII.GetBytes("Hello World!"));

JBSWY3DPEBLW64TMMQQQ

var b32 = new Base32Url(true); // Base32Url(bool usePadding)
b32.Encode(Encoding.ASCII.GetBytes("Hello World!"));

JBSWY3DPEBLW64TMMQQQ====

For more information about the standards involved please see rfc 4648 http://tools.ietf.org/html/rfc4648

Wikipedia also has good information. Please see http://en.wikipedia.org/wiki/Base32 and or http://en.wikipedia.org/wiki/Base64

// Get a double between 0.0 and 1.0 using a secure random number generator and the maximum fidelity of a double

var rndBytes = new byte[8];
using(var rng = RandomNumberGenerator.Create()) { rng.GetBytes(rndBytes) };
ulong uIntResult = BitConverter.ToUInt64(rndBytes, 0);
double doubleResult = (double)(uIntResult / (decimal)UInt64.MaxValue);

// Get a value between minValue and maxValue exlusive of max (like System.Random.Next(int minValue, int maxValue)

int minValue = x, maxValue = y;
int intresult = (int)Math.Min(Math.Max(Math.Round(minValue + (doubleResult * (maxValue – minValue)) – 0.5, 0, MidpointRounding.AwayFromZero), minValue), maxValue);


// Get a value between minValue and maxValue INCLUSIVE (UNLIKE like System.Random.Next)

int minValue = x, maxValue = y;
int intresult = (int)Math.Min(Math.Max(Math.Round(minValue + (doubleResult * ((maxValue+1) - minValue)) – 0.5, 0, MidpointRounding.AwayFromZero), minValue), maxValue);

There’re a number of attacks around modifying the EFTPOS smart card terminals. This is especially a problem when the same PIN can be used for the CHIP n PIN entry as is used for the magnetic strip. I.e. take a copy of the magnetic strip, and even if the user then uses CHIP n PIN you can send those details (magnetic strip + pin) overseas and make withdrawals from ATMs that don’t use a CHIP reader.

See a detailed story on the issue here, “Criminals hijack terminals to swipe Chip-and-PIN data”

Most of the problems come down to the one simple problem; the user does not have the technical skills to determine whether they should trust a particular ATM or EFTPOS machine.

One simple answer to all this problem of trusted hardware may be to have smart cards with PIN pads built in and a small display. 

  1. You would insert your card in the ATM/EFTPOS machine.
  2. Choose the transaction (I.e. withdrawal $100, or pay $12.34 for some goods).
  3. Remove the card from the ATM/EFTPOS terminal.
  4. The card would then have a small display showing how much you were authorising and potentially who you were paying as well.
  5. You would then enter your PIN on keys / touch sensor built into the smart card.
  6. Re-insert your card in the ATM/EFTPOS terminal to complete the transaction.

I don’t think the technology is too much of a problem. Building a display and pin-pad into a card that remains as thin as current ones may be a challenge, though not an insurmountable one I suspect.

But then again, why not just use a trusted computing device with short range communications to authorise payments. i.e. Swipe your phone past the eftpos machine, transactions under $100 automatically authorised, up to $300 user clicks OK on phone to authorise, phone requires a pin number to authorise anything more.

Follow

Get every new post delivered to your Inbox.