Wednesday, July 25, 2012

Registering users with django_facebook

Hoping to save you some sanity with this one.

Thierry Schellenback's django_facebook module promises to make life easy for Django developers to instantly hook into facebook for their registration and login needs. This is kind of true. Unfortunately the documentation is way too sparse and it's missing a critical explanation: how to redirect the user after registration.

The default code redirects to Thierry's demo page after registration. It took me forever to figure out how to override this. It turned out to take only one extra parameter in the registration POST:


His examples use the "next" hidden param and it works as expected during the login flow. But registration requires the "register_next" hidden param. That's it.

Hope this saves you some time.

Friday, June 8, 2012

eHarmony's response: Really weak

Just like LinkedIn, eHarmony found themselves victim to hackers this week. But unfortunately (and again, just like LinkedIn), the hack revealed that eHarmony had failed to take even basic precautions to secure users' passwords.

Read all about the security gaffe in my blog post here.

And here comes eHarmony's not-so-mea culpa. It's even less inspiring than LinkedIn's official comment on the matter.

eHarmony says that "a small fraction of our user base has been affected" which is probably half-true since it seems that only 1.5 million of their passwords were leaked (presumably eHarmony has a much larger user base than this). Though they are probably also deluding themselves (or their users); the hackers only released the passwords that they needed help cracking. And, indeed, help did arrive.
Less than two and a half hours later, someone with the username zyx4cba posted a list that included almost 1.2 million of them, or more than 76 percent of the overall list. [...] As of Tuesday, following the contributions of several other users, just 98,013 uncracked hashes remained. (ArsTechnica)

eHarmony, liked LinkedIn, has to scramble to save face here. They can't just come out and say, "we were incompetent, sorry." But their actual comment, "Please be assured that eHarmony uses robust security measures, including password hashing and data encryption", is just a blatant falsehood. Password hashing on its own is not "robust security"; password hashing, salting, and iterating is robust. Had actual "robust security" been in place, the hacker community would not have been able to crack those 1.5 million passwords as quickly as it did.

But it gets worse: "We also protect our networks with state-of-the-art firewalls, load balancers, SSL and other sophisticated security approaches." Oh, yes, let's throw every techie-sounding term out there to impress our users! The one that really irks is "load balancers". Come on, eHarmony, you have got to be kidding with that one. Your load balancers are part of your "sophisticated security" measures? Load balancers do what it sounds like they do - they evenly distribute website traffic so no one server is overburdened. And what role do load balancers play in securing user passwords? None. None whatsoever. Lame. So, so lame, eHarmony.


Not "sophisticated," cut the BS
For all their claims of "sophisticated security" they failed to make use of the most basic password security best practices out there. And these aren't new, cutting edge techniques; the kind of encryption best practices we're talking about are almost ancient by tech standards. But somehow eHarmony and LinkedIn's developers missed that memo.

It's clear that their PR department is intent on painting them as the helpless victim here. The magically powerful hackers broke through their "robust" and "sophisticated" security and had their way with poor eHarmony. But the reality is that while, yes, anyone can get hacked, this is why you take all reasonable measures to properly encrypt your user passwords. They did not take all reasonable measures. They followed only one of the three best practices for securing passwords and now have a black eye because of it.

The hackers broke in, shame on them, but they should have found nothing more than a collection of millions of additional locks. They didn't. Shame on eHarmony. Now own up to it.

LinkedIn's response: Weak

After LinkedIn's password hacking fiasco this week, they released a blog post describing the incident and the steps they're taking to recover from it.

It's not very impressive.

The Real Lesson of the LinkedIn Password Hack, pt1

Technology is confusing but encryption and the mysterious world of hacking exist on a whole other level. It’s Matrix-like tech voodoo. 

Hackers are a 21st-century boogeyman. They possess incomprehensible powers, ninja-like access to any digital domain they choose. They can outsmart your cleverest developer. If a hacker wants your company’s data, you are powerless to stop it. Right?

Probably, yes (sorry, this post isn’t about reassurances). But that’s not the lesson of the LinkedIn debacle.

LinkedIn was hacked. It happens. But the encoded passwords that the hackers posted revealed something much more disconcerting: LinkedIn’s password encryption was awful. Borderline criminally negligent, in fact.

The Real Lesson of the LinkedIn Password Hack, pt2


In part 1 I explained the logic behind the first password best practice that LinkedIn was just barely smart enough to use. Now we explore the simple - yet shockingly effective - ways to further enhance password security.


Password Best Practice #2: Use a random salt to produce unique hashes.
A “salt” (no clue why it’s called this) is simply extra random text that is added to your password. Instead of encoding “mypassword” the site will encode “mypassword/2dsdjkl23r”. Notice the different result:

91dfd9ddb4198affc5c194cd8ce6d338fde470e2 = “mypassword”
eb8b3a04fb5bb65ecc02f40e83fa4d8065b26af6 = “mypassword/2dsdjkl23r

And every user gets her own random salt. So all of the fools who used the weak “mypassword” will end up with different encodings:

6097a22f84896b07dcd240f18b2a79ff84bec499 = “mypassword/8sadfljk23j2d08
85673bdb67447ca772199344de3fbb9ddb360368 = “mypassword/jkl34rjsdf89kl

So even if one “mypassword” account is compromised, the other “mypassword” fools are still safe, for now. Better.

But even this isn’t perfect. 

Thursday, May 31, 2012

Save Money: Professional Email on the Cheap, pt1

Part of the µ-Dev philosophy is to do everything as cheaply and as hassle-free as possible, but while still projecting a completely professional appearance to the outside world.

With the tools available today your corporate email should be free or nearly free. In this post I'll show you how to make that happen.
(I'm assuming that if you're reading this blog, you're interested in µ-Dev and not in building a corporation with hundreds of employees. A µ-Dev company should have very modest email needs)


Save Money: Professional Email on the Cheap, pt2


In Part One I explained how to route corporate emails from your domain to a free Gmail account. Now that we can receive emails, we need to complete the process so we can send emails from our corporate email addresses.


Step 3: Configure Gmail to send email through your domain name
You can tell Gmail to send email on behalf of another account. Your Gmail account might be first.last.biz@gmail.com, but your outgoing mail can be your company's support@mybusiness.com email address. This is how you make your business look professional and legit.

Wednesday, May 30, 2012

Techie Stuff: Django on Google App Engine vs Amazon EC2

I am not a sys admin and I really hate sys admin-y things. I'm a coder. I just want an environment that works and that can run my code. Period.

That makes Google App Engine extremely appealing. You have zero sys admin responsibilities in the App Engine world. This is a godsend to me. My first business, EssayTagger.com, is happily running on App Engine. But as with all things in life, there are tradeoffs.


Tuesday, May 29, 2012

µ-Dev Tenet #1: Zero Maintenance

I was consulting on a project in Athens, living in a furnished apartment. I found a french press in the cupboard. Desperately missing my Tassimo back home, I figured the french press would be my savior. But I had to know how to use it first - how much coffee to put in and for how long?

A quick Google search turned up www.frenchpressinstructions.com as the first search result.

The info there was actually useful. But it boggled my mind that someone had actually registered that domain name to put up that site! I mean, come on, that's just totally absurd!

It's a single-purpose site that visitors will use once and never return. Sure there are banner ads generating some paltry revenue, but this is about as far from high-engagement content as you can get!

But something else occurred to me: It requires zero maintenance from its creator.

Zero maintenance.

Whoa.

That's a big deal.


What is µ-Dev?

Welcome to the µ-Dev Blog!

"µ-Dev" or "micro-Dev" is the term I've adopted for my new approach to high-tech startups and entrepreneurship in general.

In a nutshell: The µ-Dev philosophy focuses on building and launching companies extremely quickly one after the other after the other... and so on ad infinitum.

In the next couple of posts I'll lay out the inspiration for the µ-Dev approach and throughout this blog I'll share my own attempts to see this through while posting helpful business or tech/code tips along the way.