In an article I had published in infoTech Spotlight discussing security and the Gawker database hack, I argued that it’s relatively easy to protect your user’s personal data against a database breach. The idea isn’t new – as a matter of fact this particular implementation dates back to 2005, and you can be sure it was known well before then.

Faced with a similar breach, Mt. Gox appears to have performed a little better. Although they originally depended on md5() hashing to secure their passwords (warning: do not do that), they came to their senses and started salting individual passwords much the same way as this article recommends.

Good for them. This is a great case study on how an organization who borked it was able to retrofit their code to protect their users. I applaud them for that effort. It may not have been perfect, but it was likely good enough for users who were smart enough to protect an account on a financial exchange with a half-way decent password.

As an aside, it’s a little disturbing how many of the nerds on the Hacker News don’t understand that not only is it ok to store the salt alongside the encrypted passwords in your database, it’s actually a good idea. Ugh. Another reason why developers should never be trusted to roll their own authentication schemes.

Unfortunately, Mt. Gox’s security lapse has come at a crucial point for Bitcoin. Bitcoin is an interesting economic experiment. I encourage you to read up about it as the official docs can explain it much better than I can here.

While it’s strictly true that Mt. Gox != Bitcoin, at this point in the evolution of the movement few people have the sophistication to understand the difference. So it might not be fair, but it’s still entirely possible that this incident could torpedo the movement. That’s unfortunate for many reasons, but it’s a reality of the world we live in. An upstart economy can’t prevail without trust.

It seems that 8 lines of code may not be enough.

For anyone other than my mother still reading this blog, I’ll be blogging to support R/GA’s new techblog. I’ll point to any posts I author there when I get around to it. Since this blog is all about me, it’s pretty much just a complicated way to bookmark my R/GA posts.

To get it started, here’s a repost of an article R/GA helped me publish through infoTech

This article was originally posted here.

Enjoy!

For the past month I’ve been involved in the Founder’s Institute NYC Winter 2009 program. The program’s aim is to train founders in the art of building a business so they can avoid common missteps and give them a better shot at being successful. There are about 40 founders in the NY session, representing a good cross section of industries and skill sets.

I haven’t written much about it yet because I wasn’t sure what to say. The process of applying and getting accepted was incredibly condensed and emotional (read: delusions of grandeur). As those hopes and dreams slowly adjust back to reality I’m seeing both the good and the bad. It’s mostly good, but not entirely. One thing I struggled with going in was what I expected to get out of it. I spoke to other founders informally about that question and the answers varied widely. My initial impression was that no one really new what to expect. That can be both a challenge and and opportunity.

I’m reserving final word for later – there’s a long time to go and many things could change – but so far I think the experience has been helpful in a number of ways, both intended and unintended. One of the first things Adeo Ressi said was that Founder’s Institute is not going to make or break my business. It will give me some tools that will help, but it’s still up to me. I think that’s very valuable advice and something I have to keep in mind as I go through process.

Ugh, another tech blog. Well, in my defense:

1. I really don’t expect many people to read this anyway
2. I hope to cover something that I’ve had a hard time finding coverage of in the blogosphere – database design for application programmers

Databases are important. Really important. Maybe not the most important thing, but up there with showering and changing your oil every 3K miles. Problem is, at most of the jobs I’ve had I’m the developer who knows the most about how to effectively use the database (my apologies to anyone I’ve worked with who’s reading this). As much as I’d like to keep that the case for selfish reasons, it doesn’t seem right.

There are opposing forces at work in the development community. At the same time that modern technologies such as Hibernate give developers the mistaken impression that they can get away with knowing less about database design or database application programming our collective reliance on storing and searching large datasets has exploded. Application developers can no longer afford to assume the DBA will make it all better. And we are nearing the end of the era where poor database design can be shielded by raw processing power. The best applications, and the best application developers, must optimize data access at every point in the system.

It’s not always fun. Any modern DBMS has the ability to reduce a man to a heap of slobbering refuse. But….it’s important. Hopefully the experience I share will make it less painful.

From a technical standpoint, expect to get a lot of Oracle and MySQL as those are the DBMSes I’ve worked on. I love me some PL/SQL for business logic. My middle tier languages are Java and PHP, and I’ve done a lot of Perl in the no-so-distant past. I find C to be interesting if you must, but I choose to forget that I ever learned C++. I have a modest coder-crush on JavaScript but I don’t get to spend much time with it, and I find CSS fun in modest portions. So all of that is fair game.

So here’s my plan. As of this writing, I have loosely 30 database-related topics that I hope to cover (see the Future Posts page). Additionally, the initial concept for this blog was to analyze and critique the database schemas for well-known open-source projects like phpbb or MediaWiki, and I still plan on doing that if I find it interesting. Beyond that, I have vague plans on a recurring series to develop a fantasy sports database schema for educational purposes. And although I reserve the right to intermittently post about anything else that remotely interests me, from development practices to my sons to politics, the focus of this blog will be databases and will be targeted at application programmers. So since my goal is a post a week, I expect to have about a year of posts before I need to decide if this blog has any value to anyone besides me 🙂

All that said, thanks for reading!

P.S. For the doubters out there, please check out the Tech Cred section to the left to find out more about my technical background.