Graham's profileReality RefactoredBlogLists Tools Help

Reality Refactored

Graham Murray

May 11

TwoFactor WHS addin published

I've published the first release of my Windows Home Server addin, which allows for two factor authentication for the WHS remote access website via the Yubikey hardware token. The plan is, in the future, to also support some software based tokens. Maybe I'll even whip up an implementation of OATH HOTP for a few devices if I can't find suitable open source solutions.
 
Let me know what you think of the addin, and please submit any bugs or feature suggestions. I'm interested in the community auditing the code for security flaws, as I'd like this to be as sound as possible.
April 28

YubiKeys arrived!

My yubikeys have arrived. I've got the authentication working against yubico's validator, and have done some POC tests. Now I just have to iron out the configuration steps in the add-in and then I should hopefully have a solution ready.
April 26

Initial version for WHS add in almost done

Mostly just waiting on those yubikeys to arrive. Also need to snazz up the graphics a bit. My plan is to finally turn on the remote access on my home server for RDP once I get this working. Hopefully the WHS community at large finds this useful too. Will host the code on codeplex, but may also just make the secondary auth pluginnable so that others can extend the authorization schemes it supports.
April 21

A road to two-factor auth for WHS

I love Windows Home Server very much, and recommend it constantly. I did a lot of research before settling on a backup solution and I can confidently say that WHS meets and exceeds all my requirements. What I wanted was centralized storage and backup, and what I ended up with was that in spades, plus a whole lot more besides.
 
One of my favorite features that I didn't even know I needed is the remote access support in WHS. I can log on to my server remotely, download and upload files, view photo albums, and even make proxied remote desktop connections into my home pcs/mediacenter. BUT, this brings me to my main complaint about WHS. There is no built-in support for strong authentication. If I'm exposing all my data and machines to the internet at large, I want a lot more than a keyloggable password standing in the way.
 
So, I'm working on an add-in that will enable some two-factor auth models, and I will be recording my efforts here. My solution will revolve around introducing a model to enable requiring a one time password in addition to the remote access acount password, and initially I will be suppporting OTPs furnished by the yubikey token. The yubikey is a cheap hardware OTP token that uses all open source software in the backend.
 
I already have most of the prep-work done for this project, and am just waiting for my yubikeys to arrive. I'll be detailing more of my solution as I go along, and I'll be publishing this project on codeplex once I can do some concrete testing and stabilization, and I hope it will help the community improve authentication on the WhS platform.
January 10

Adventures in Universal Remoting or How I Made the PS3 Do My Bidding

So I recently have become an owner of a Logitech Harmony remote, and it is my new favorite thing ever! I happen to have a good memory for how my AV catastrophe is set up, but my wife gets frustrated with its complexity. And, to be honest, although I remember how to arrange things for every activity, its not easy or fun to switch between them. So, as a result I've been looking forward to see what the oft praised Harmony line of remotes could do for my system.

I am very impressed. Remote came out of box. Remote led me through wizards my grandmother wouldn't have balked at (probably). Remote has since saved my life twice (maybe). Very, very, cool. One button press completely sets up an activity or switches between them. I will never need another remote! Well, at least until we learn to ditch IR for some better mechanisms of communication between all of our electronics... which, coincidentally, brings me to the problem.

The Problem

Sony did something that I actually find rather forward thinking when they put together the PS3. They eschewed any and all IR based control mechanisms and instead settled on Bluetooth based control. This is, probably, the future. These devices would cooperate much better if they could all communicate with each other using some standard communication mechanism and protocols.

So what's the problem??

Well, the PS3s lack of IR would be all well and good if all of my devices could talk Bluetooth, could communicate with each other, and I could direct them through some centralized control to coordinate an activity for me. But as it stands, most of my other AV equipment do not support any kind of Bluetooth control. And furthermore, although I've seen evidence online that the Sony PS3 BD Remote uses Bluetooth HID standards to communicate, I've seen no-one claim to have been able to pair any other Bluetooth device to control the PS3. There are a few exceptions to that statement (further down the page), but as we shall see, they are not really exceptions.

The Proposed Solutions

USB Dongle

So the first solution that I found people experimenting with on the Internet is that many 3rd party manufacturers sell IR receivers for the ps3 that emulate a controller connecting through USB. In such a way, a universal remote can be trained to control the PS3, and all problems are solved (...ehh).

Cost: $10 - $15

Problem: NO PWR ON!!!

So apparently none of these USB solutions are able to power on the PS3. (Actually, one could, but only via a copper sticker you adhere to the PS3 start button). There seem to be a lot of theories floating around here. Many are claiming that Sony blocks non approved vendors from being able to send power-on commands over USB. For that matter it doesn't really appear that the USB bus is necessarily powered when the system is in standby (this seems to go back and forth). So although this gets past a major stumbling block, it doesn't really fix the problem, at least to my satisfaction.

IR to BT Adapters

There seem to be quite a few products floating around that claim to be able to take IR commands and translate them into Bluetooth commands that the PS3 will respect. Many of these seem, from what I can tell, to incorporate the actual BD remote circuit board. This leads me to believe that maybe Sony has done something heinous here too to prevent non Sony Bluetooth remotes from pairing with the PS3.

Cost: Seems to be $70 - $150!!!!!

Problem: Way too expensive!!!!

The IR to Bluetooth solutions are just way to rich for my blood. Especially since Sony may release a firmware update tomorrow (for all we know) that allows for the creation of IR dongles that can power up and down the PS3, and then where would I be??

I also have so many devices sitting around that I should be able to leverage that I can't bring myself to accept that the only option is to buy a $100 product. Lets make this happen! Which brings me to...

My Solution

Now, before anyone gets too excited. My solution is cheaper for me because of what I have lying around. The bonus is though, that it didn't cost me much. Also, the kind of person that owns a PS3 and is bothered by not being able to integrate it into their universal remote control system, may well likely have some of the other required pieces here.

Also of note, is I just finished with this solution earlier this evening, and I'm still working things out, and have no idea how robust it will be over time. Anyway, though, lets begin:

1) I bought the Nyko BluWave IR receiver. ($14). As I said these don't solve the power on issue. But I figured if it worked for all the normal control of the system then my problem is reduced to how to turn the system on and off. The Nyko seems to work fine for what it does, but there many be better products in its class out there.

2) I remembered that if you put the PS3 into 'remote start from the Internet' mode it exhibits a Wake-On-LAN like behavior. Now this could be good! First I enabled 'remote start from the Internet' on my PS3. This is a feature that the PS3 has specifically so that you can start it from away from your network, using the PSP, and then remote into the PS3 using the PSP's screen. Its very neat tech, and I had a PSP so I was able to turn this on. I think you may NEED a PSP to enable this feature (borrow one if you have to).

3) I experimented with waking the PS3. If I logged into my router I could send a manual WOL command and the PS3 would wake up. Good News!! It could have turned out that this was some completely proprietary and hard to decode technology. But its actually really straightforward (or so I thought).

4) I tried to write a program to send a broadcast WOL magic packet to wake the PS3 from another client on the network. PS3 ignored me. Double checked implementation. Still ignored.

5) Here is where my memory started to kick around a bit. I remembered that when this feature first came to the PS3 people were complaining (including me) that the PS3 would turn itself on at random times (like a ghost). And that Sony later fixed something to make this go away. If you think about it a client shouldn't ever think they've received a WOL magic packet when they actually haven't as its a pretty specific looking dude. So my conclusion was that the PS3 wasn't really doing real WOL, just something that is triggered by WOL (if its sent by the router or the PSP, but, apparently, not by the other clients on my network).

6) So, something about what the router sends to the PS3 works to wake it up, but not what I send from the other clients, even though the packet is the same except for the source MAC address and source IP address. This leads me to believe that the PS3 may be filtering out any communications that don't come from the the router or the PSP. So why don't I spoof the packet so as to make it indistinguishable from the one made by the router?

7) I battled with raw sockets with windows trying to send a spoofed WOL packet, until I realized that MS has made this thing harder in recent years to try seal up some network vulnerabilities.

8) I remember that WinPCap has some facilities for sending raw Ethernet packets, so I grab that write a little code, and there you go! I can essentially replay the packet that my router sends to wake up the PS3, and it wakes!

9) OK, so now I have a program that can "Turn On" the PS3. How do I integrate it with my Harmony?

10) So, I have a Media Center PC, also sitting near my TV. I figure I can throw the program on it, and then somehow get a certain IR code sent to the Media Center PCs IR Receiver to trigger the program. There are a bunch of commercial programs out there to help do this, and a few free ones, but I couldn't really determine whether they would interfere with the normal operation of the media center PC. But then I stumbled across something more elegant.

11) http://www.mediacenterguides.com/advancedremotes. (Warning: Advanced users only! Maybe I can write a guide to help with this bit). Turns out all you need to do is some registry tweaking to map an unused media center remote to something like Windows Key + 1 to start a program shortcut.

12) So I mapped an unused button to run the program that I wrote to start the PS3.

13) In harmony I was then able to say that it had to include the media center PC in the PS3 activity, and that when starting the PS3 Activity it should send that button press to the media center PC.

14) Meanwhile when the activity actually starts up, harmony is talking to the BluWave IR receiver, for all the normal functions.

 

And so I was able to make my universal remote start the PS3 without buying any additional equipment.

 

Next on my list:

1) I need to figure out how to turn off the PS3. I think people have made macros for this with the Harmony remote before.

2) When the PS3 starts up from WOL, you need to dismiss a dialog before a certain amount of time, or the PS3 will shut down again, this should be macro-able too.

3) I'm remembering that sometimes the PS3 wouldn't want to wake from LAN about half a year ago when I used this with my PSP. Don't know if Sony has made it more resilient since.

 

I'll try to elaborate more on how other people can implement this soon. I'm just providing the technical sketch-up up front.

September 26

Windows Mobile, and secrets.....

How exactly are you supposed to keep a secret on a mobile device anyway? Most of us are too annoyed at having to enter a password to use a device every time you take it out of your pocket, but how does this interact with if you need to keep a secret on a mobile device? Take, for example, my Imap Pusher Service. If the user wants to save the password that will be used to log onto the destination IMAP server so that he doesn't have to re-enter this each time, how can this be kept secret? Any encryption I put on the password is easily reverse engineerable (app is open source), so all I would be achieving is security via obfuscation, which has always unsettled me. The only way around this that I know of, it to have the OS guard the encryption key, or base the encryption key on a key that the user provides to establish a session with the device. And in both cases, this would require the user to enter some kind of password to establish a session with their device, hence rendering it less useful again. Can we just have fingerprint scanners on our phones already???
September 25

ImapPusherService Release 0.6

Release 0.6 of ImapPusherService adds the ability to save your settings.
September 05

WCF Compression: a solution.

Regarding my last post, I sent an email to Nicholas Allen asking for his advice, and his latest blog post confirms my belief that it would be a dumb idea to do encoder level compression if we are doing message level security. What I have tried, and it seems to work pretty well, is to use message inspectors to do the compression/decompression as, from the documentation, it seems these execute just as the message is generated (before they are secured or encoded), and then last on the receiving side (after the decoding and decryption take place). This seems to work well. My only concern, though, is that there doesn't appear to be any kind of standard as to how to represent compressed data in SOAP. So, if our application requires compression in order to function efficiently over the WAN, we must necessarily decrease the level of interoperability. It would, presumably, not be too difficult to re-implement this compressor/de-compressor on other SOAP stacks, but I'm not too aware of how extensible these are, on a whole. One would presume, that because SOAP is, by its very nature, very extensible, that any SOAP stack would have to also be very extensible, but I've been burned by this type of wishful thinking before.
August 29

WCF Compression- best practices?

I work on a pretty large enterprise WCF application and even with the binary encoding the messages that we end up sending back and forth seem to creep up to sizes that are dangerously large for slow internet links. This is becoming quite a problem.
 
One suggestion I am seeing to reduce data size involves setting EmitDefaultValue to false for data members that will often contain their default value. However, the MSDN seems to caution against the overuse of this setting (maybe for performance reasons, or versioning?), and to my mind, its letting the vagaries of the transport bleed too far into the application.
 
So, short of re-engineering the data that these services are expecting and returning, it seems we should be considering encryption options. My question is what is the best practice route here? Apparently the SDK contains some sort of gzip encoder example, which seemed compelling until we realized that, most of the time, our clients want to apply security at the message level. With the amount of randomness injected by doing this encryption, I doubt what's left of the message will compress well, or at least won't give us the wonderful savings of compressing human readable text, or some binary encoding thereof.
 
So it would seem what we need is a transform to the message body that applies before security and encoding? I have just begun to investigate WS-Compression and the various WCF implementations for it that exist, and I wonder if these hold the answer. Even more lovely, to my mind, than being able to add compression to a binding, would be to be able to add conditional compression to a binding, whereby we could make some decision about a message to see whether we would benefit from compression, or whether we would just be adding to the overhead.
 
But I wonder if I am barking up the wrong tree? What is the best practice method for dealing with the inflated data spewed forth from the data contract serializer?
 
Update:
On further research it is seeming WS-Compression isnt a real standard, but merely some wishful thinking of some sample writers. Seems like there should be some allowances for compression in the WS-* realm though, as all of this stuff is very verbose.
August 05

Exception Assistant, what is your malfunction.

Sara Ford writes on how to disable to exception assistant, but what I really want to know is how to conditionally disable the assistant. I haven't looked too hard to uncover this because it only seems to crop up under certain conditions. I think the problem is when you are handling the exception, but you are not handling it in a portion of the stack that is being debugged by studio. So what happens is you end up being notified about the exception even though it will subsequently be handled. This may be the desired result sometimes, but other times, it most certainly is not.
 
A good example of this is if you are using nunit's ExpectedException attribute. Even though this causes the nunit framework to handle the exception and turn it into an assertion failure, you still get the assistant popping up at the time the exception is raised, trying to be helpful. It would be nice if there was an attribute we could use to disable the assistant for a call, but hey, maybe there already is! Or alternatively, it would be useful if it's possible to disable the assitant at a project level.