It’s kind of frightening to see how quickly a skilled lock-picker can jimmy a lock and get in. But new technology makes it even simpler — apparently all you need is a good telephoto lens to break in to someone’s house — just wait till they leave their keys out on a table, snap a picture, and take it to an unethical key maker, and wha-la, a perfect replica:

“We built our key duplication software system to show people that their keys are not inherently secret,” said Stefan Savage, the computer science professor from UC San Diego’s Jacobs School of Engineering who led the student-run project. “Perhaps this was once a reasonable assumption, but advances in digital imaging and optics have made it easy to duplicate someone’s keys from a distance without them even noticing.”

Professor Savage presents this work on October 30 at ACM’s Conference on Communications and Computer Security (CCS) 2008, one of the premier academic computer security conferences.

Read the full article here.

Actually someone once told me the same thing about women and I am sure women say the same thing about men. But Tim Greene has an epiphany in a recent article about bad news for NAC vendors who rely on agents.

I think we all know that the last thing most enterprises want is another agent on their machines.  Heck, not just enterprises either, no one wants yet another agent.  The reasons for this are many and Tim lays them all out.  For me personally the biggest reason is that too many of these agents (and not NAC agents necessarily) are pigs.  They slow down your machine more than some of the widgets I used to use slowed down my blog page loading.

But Tim offers agentless NAC as a panacea. That it is not. In some cases agentless NAC works great, in others it severely limits what you can test for when and how fast.  Personal firewalls and other such technologies can wreak  havoc on agentless NAC.  You may still need credentials to get any useful information.  Over the years here at StillSecure, we have come to realize that in most real life situations, you need both agent, agentless and even web delivered methods of NAC testing, if you are going to be able to perform NAC against the entire spectrum of devices logging on to the network.  There is no one perfect way to do NAC. If there was, everyone would do it that way.  A good NAC solution should be flexible enough to offer multiple methods of testing.

One other thing I noticed was in the comments to Tim's article Dan Clark from over at Lockdown tried to make a comment and refer back to the Lockdown blog for his further commentary on this. The next comment though from Robert B I thought was priceless. It isn't that long, so let me just paste it in here:

Does anyone else find vendor blogs like nactalk.lockdownnetworks.com a little troubling? They appear as a neutral blog discussing a topic, except they only contain the vendor's point of view.

While they seem to allow comments, the one time I registered and tried to comment, it was never approved. I'm assuming that since none of their other "vendor patting themselves on the back" articles have comments, I am not the only one.

Hey Robert I agree with you. The Lockdown Blog is a pretty thinly veiled attempt at a cheap marketing outlet. A review shows they put up an article a month and never have any comments as Robert points out. That is not a blog, the same way many vendors who claim to offer NAC don't really have a NAC solution. However, I would hope that not all vendors who blog are painted with that same brush.  Besides myself, there are several excellent blogs authored by people who are also working for vendors. Not to say we are not biased, but I think there is a clear distinction there.

Actually someone once told me the same thing about women and I am sure women say the same thing about men. But Tim Greene has an epiphany in a recent article about bad news for NAC vendors who rely on agents.

I think we all know that the last thing most enterprises want is another agent on their machines.  Heck, not just enterprises either, no one wants yet another agent.  The reasons for this are many and Tim lays them all out.  For me personally the biggest reason is that too many of these agents (and not NAC agents necessarily) are pigs.  They slow down your machine more than some of the widgets I used to use slowed down my blog page loading.

But Tim offers agentless NAC as a panacea. That it is not. In some cases agentless NAC works great, in others it severely limits what you can test for when and how fast.  Personal firewalls and other such technologies can wreak  havoc on agentless NAC.  You may still need credentials to get any useful information.  Over the years here at StillSecure, we have come to realize that in most real life situations, you need both agent, agentless and even web delivered methods of NAC testing, if you are going to be able to perform NAC against the entire spectrum of devices logging on to the network.  There is no one perfect way to do NAC. If there was, everyone would do it that way.  A good NAC solution should be flexible enough to offer multiple methods of testing.

One other thing I noticed was in the comments to Tim's article Dan Clark from over at Lockdown tried to make a comment and refer back to the Lockdown blog for his further commentary on this. The next comment though from Robert B I thought was priceless. It isn't that long, so let me just paste it in here:

Does anyone else find vendor blogs like nactalk.lockdownnetworks.com a little troubling? They appear as a neutral blog discussing a topic, except they only contain the vendor's point of view.

While they seem to allow comments, the one time I registered and tried to comment, it was never approved. I'm assuming that since none of their other "vendor patting themselves on the back" articles have comments, I am not the only one.

Hey Robert I agree with you. The Lockdown Blog is a pretty thinly veiled attempt at a cheap marketing outlet. A review shows they put up an article a month and never have any comments as Robert points out. That is not a blog, the same way many vendors who claim to offer NAC don't really have a NAC solution. However, I would hope that not all vendors who blog are painted with that same brush.  Besides myself, there are several excellent blogs authored by people who are also working for vendors. Not to say we are not biased, but I think there is a clear distinction there.

Advertising: banner ads are almost always pulled from a third party. That third party gets things like referrers and, what else, IP addresses! Sorry, say goodbye to third party ad revenue! Yes, that means you, Adsense and Overture! People can no longer leak that information to you as it’s PII!

Tracking Pixels: tracking pixels are used by companies all over the world because it’s often easier than dealing with their own logs and buying and configuring their own log analysis software (especially if they get a lot of traffic). So Omniture and Google’s Urchin could be hard hit here.

Embedded content: There are tons of bulletin boards, message boards, blogs, etc… out there that allow images to be posted off host. People like it because it doesn’t force them to have to build upload scripts, and maintain them. Sorry, no more embedded content, and that includes things like Youtube because that would leak the people’s IP addresses to third parties. Also, things like Gmodules which often pull in content from other domains would be a big no no without some changes. Same with Google cache, translation services, etc… etc…!

There’s dozens of issues out there, but you’ll notice that this particular issue would wreak havoc on Google’s business model if it’s ever fully enforced. It’ll be interesting to see how this plays out and if there is any other tricky way people can use to get around this (like hashing the IP or stripping off the last bits - which is mentioned in the last part of the article but probably isn’t much actual protection since that only makes it 255 times harder to guess at best). This is one to watch folks!

When the result of my efforts looked like stretched silly putty, I figured that I must have taken the wrong approach, so I hooked up with the author of our WPF short course, Ian Griffiths. Ian reminded me about constraints in layout, and I was able to fix my problem pretty quickly.

Unless you use absolute positioning (such as the Canvas layout control does), WPF uses a pretty sophisticated negotiation model to figure out how each control will be laid out. WrapPanel, for example, asks each child element how much space it wants, and lays those children out in a wrapped fashion. Here's a simple example with two buttons:

<WrapPanel>   <Button>One</Button>   <Button>Two</Button> </WrapPanel>

In the above case, the WrapPanel asks its children how much space they want. The buttons size themselves according to their content (in the example above, the text in each button determines its size). So there's no problem. But try dropping a simple Image into the same panel and things start to get weird:

<WrapPanel>   <Button>One</Button>   <Image Source="..."/> </WrapPanel>

You see, by default, Image stretches to fill the available space in the container. But the WrapPanel isn't constraining the child's space, and so things get strange. Either the parent or the child in this case needs to step up and figure out how much space should be allotted for the child. One easy way to fix this is to turn off stretching in the Image element:

<WrapPanel>   <Button>One</Button>   <Image Source="..." Stretch="None"/> </WrapPanel>

Now I've got something more reasonable - the little XML image is the size I expected it to be. Image is an example of a control that can wreak havoc with the layout engine if you're not aware of this. ScrollViewer is an example of a container that can do the same thing, as it essentially tells its children they have infinite space. So if you run into weirdness like this, take some time to adjust various constraints until you find a solution you like!