Posts Tagged ‘authentication’

On the importance of knowing how to pick secure passwords

Thursday, May 28th, 2009

We’ve already got solid advice on picking half decent passwords, but this advice from Zebra really takes the cake.

zebrasafepassword

Developers, you can stop your crap authentication schemes now. Please.

Friday, May 22nd, 2009

I really like cryptography and security. I was lucky enough to take it as a subject at UNSW before I graduated.

I found this earlier this evening; it’s a little old (~18 months), but that doesn’t make it any less relevant, so it’s a good read. There’s the odd inaccuracy here and there, but it’s solid stuff, and relevant to anyone writing webapp code to handle authentication.
http://www.matasano.com/log/958/enough-with-the-rainbow-tables-what-you-need-to-know-about-secure-password-schemes/

The article focuses heavily on one particular authentication methodology, because it’s something a lot of people do. After you read it, you’ll understand that it’s something a lot of people do poorly. It assumes a reasonable degree of knowledge about what you’re doing (ay, there’s the rub), but the best lesson to be learnt there is that you shouldn’t be writing that code! Just stop! Someone’s already done it better than you, and it’s been checked by a lot more people than you and your colleague, who reckons it “looks pretty secure”. If you’ve got time to read all the comments on the article you’ll find a rollercoaster of people saying, “wouldn’t it be secure if I just..?” Just don’t do it. Don’t write my security code, bro!

Just using a proper authentication mechanism means you can spend your valuable time on more important things.

  • Like not building SQL queries in a piecemeal manner, using unsanitised user-supplied data
  • Like not making your whole site world-writeable so you can handle file uploads (you don’t have to do this on our shared hosting servers)
  • Like fixing your newsletter signup process so it requires double opt-in, saving you from filling your database with spurious accounts and causing massive headaches when you do a campaign mailout
  • Like optimising your database schema for bitchin’ performance – do you retain a DBA on a six-figure salary to do this for you? Nah I didn’t think so, this is cheaper and much more fun
  • Like checking that your code doesn’t spew 14 PHP Warns/Errors to the apache logs for every page access, and fill the partition
  • Like trying to get nice round corners on your page elements :)

nsscache and LDAP reliability

Monday, February 2nd, 2009

Any company with multiple servers in their authentication domain will know of LDAP. Sadly on the Linux platform, OpenLDAP (although arguably the most widely used and well known of the few LDAP servers available) is still not particularly reliable, especially when it comes to replication. The overheads involved in querying even a local OpenLDAP server are much higher than, say, the plaintext files such as /etc/passwd.

Enter nsscache. Created by two boffins at Google (one of whom graduated from Anchor Systems), nsscache gives the reliability and speed of plaintext files (or BDB if you desire) and the scalability of OpenLDAP. Anchor recently started using it and we are confident it will dramatically boost the reliability and lookup speed of all of our LDAP systems.

In terms of performance, we are seeing update times of a second or so for a partial update (only changed or new entries), and around 10 seconds for a full update (replacing the entire on-disk files with a fresh copy of the entire source database) for a bit under 20000 records.

I’d definitely recommend taking a look at it. It currently only operates on Python 2.4 or later (although a patch is nearing release that allows it to work with Python 2.3).

Site links
Anchor
Wiki
Blog
Services
Domain names
Web hosting
VPS
Dedicated Servers
Co-location
Articles
Dedicated Server Purchasing Guide
Dedicated Server Tutorials
Developer Friendly Hosting
Useful Tools