I know this is primarily a software development blog, but sometimes the physical/hardware side catches my interest. Well, that’s what happened with lock-picking… I stumbled upon some old talks by Deviant Ollam about the subject and decided to give it a try.

My first attempt was with a warded lock. The longest part of that was just finding/making the pick for it. It was fun learning about the history of that style and the pro’s and con’s of it.

After that, I’ve just been working my way up the difficulty rating scale, using locks from Home Depot. It’s getting a bit expensive to do that, however, so I’ll probably move to just picking some up at garage sales or whatever if I see one I like.

No one ever told me how addicting lock-picking would be. I sometimes catch myself sizing-up the locks I see throughout the day… Office buildings, especially, have plenty of interesting opportunities.

Many businesses have RFID badges and whatnot for securing their doors and logging access, but the doors still have ‘legacy’ support for traditional keys (in case of power outages, for instance). If someone picks that lock open on one of those doors, how would your business know that someone was in their server room, HR department, or other sensitive area?

This line of thinking eventually led me down the path of learning all about how master keys work and ways you can use legitimate access to one lock to eventually come up with your own master key for the other locks. That assumes the locks in your building even have a master key, but I imagine most do. That’s something I’d love to get a chance (and permission, obviously) to mess with sometime.

Google has been in the news recently, for their public shaming of Microsoft.

Ninety-days after a disclosed release from Google, the vulnerability is made public. This is meant to provide a bit extra motivation for vendors to fix reported issues. And, for most companies, it’s probably more than enough time to resolve the issue.

Since it doesn’t necessarily align with Microsoft’s current “Patch Tuesday” approach, I can understand why MS is not a big fan of it, though. Maybe this will lead to a more frequent release of patches, which could be good or bad, really…

All in all, I think responsibly disclosing of issues is important. Nothing (ethically) is gained by publicizing an exploit prior to it being fixed by the vendor, so full-disclosures probably aren’t often needed. But I do think putting some external pressure on vendors is sometimes necessary. Especially if the vendor isn’t all that communicative or open with the people who discover the issues.

It seems like the more I’ve been working in C#, the less I notice the differences between it and VB.NET

The case-sensitivity and needing to put semi-colons pretty much everywhere is a bit annoying, but other than that, I can’t really recall what my big gripe was with it the last time I started messing with it.

I think part of the issue for me is I don’t get enough day-to-day exposure to it. It’s like taking a course in a secondary language, but you only get to actually hear or speak that language once a month…

Until that changes, I suppose I’ll just need to work on more side projects written in C# to keep up my fluency.

USPS has been in the news recently. Roughly 750,000 employees, both former and current, had their private data stolen.

Hopefully this will be a bit of a wake-up call for companies, so they’ll put just as much effort into securing their employee data as they do for their customer data… It seems like everyone is getting breached these days…

I’m a bit more paranoid about this sort of thing than most, though. Whenever filling out paperwork or online forms, I tend to wonder a bit (and sometimes ask) how they are keeping my information secure.

[UPDATE 11/24/2014 — Sony Pictures was apparently breached. Not only did their internal files and emails get leaked, but I guess their information is being held for ransom. Ouch!]

A friend of mine was doing some web development for a company in a fairly tightly regulated industry and wanted me to do some testing of it, to see if I could spot anything he had missed.

I did the usual stuff — changing URL parameters, putting letters and negative numbers into amount fields, etc. Everything seemed to check out.

At one point, though, I decided to check the site’s robot.txt file to see if there was anything interesting. Most of it was pretty mundane CMS-related stuff. I had almost given up on finding anything interesting when I went to the last directory mentioned in the robots.txt file that I hadn’t been to yet — the Images directory.

Though there were a few folders that seemed admin-related, they were either empty or I didn’t have permissions. Dang.

I did, however, find a subdirectory called “Orders” (or something similar)…

The folder contained a massive amount of PDFs and images, with full order details and customer data. It had name, address, DOB, SSN, and other sensitive of information. There weren’t any payment details, from what I saw, but it was still more than enough for identity theft.

Apparently, no one at the company thought to secure that folder because it wasn’t referenced anywhere directly by the website or app. It had been forgotten about. But, hey, who’s going to manually browse through a site’s directories, right…?

It was good that the robots.txt was there to make sure (or at least politely request) that search engines do not included that directory in their indexes, anyone who spent a few minutes poking around the site like I did could’ve found the same information.

Shortly after this was discovered and reported, the company revamped the way they handle storage of order information and made it completely unavailable to the webserver. They also apparently took my suggestion to no longer allow directory listings.