So you have a million passwords, right?  Every site out there requires you to enter a username and password to buy a widget that plugs into your doohickey for whatever silly little hobby you have that is supposed to distract you from writing code in your free time so you don’t feel like a complete loser. 

Or better yet, you need a username and password to buy flowers for your wife.  Or you need a username and password if you’re buying a $3.75 Cozy Coupe Wheel With Capnut, plus $7.95 shipping, when all you really need is the damn capnut anyway because the first one got slightly bent during assembly so every now and then the wheel pops off and your horrified toddler is trapped in plastic car wreck.  Or something like that.

And of course, we all know that you shouldn’t be using the same password everywhere.  At the very least, you should be using a different password for everything important and sensitive, like email and banking and online gambling.

Some say Open ID may be the answer.  It certainly is gaining popularity with many sites in the development community.   But the real test will be if it ever catches on with people who have real lives, and really couldn’t care less about your cool new shared authentication mechanism, and don’t really know or care that they shouldn’t reuse their favorite celebrity’s nickname as their password everywhere.

But even then, even if the world were to become thusly enlightened, a large number of the sites our there start using Open ID as their core authentication, there will still be countless little sites out there written by internal IT departments who have never even heard of Open ID and certainly aren’t going to trust some new-fangled “Web 2.0” technology, when they’ve spent the last 10 years working their way up to “Enterprise Architect” of their little fiefdom, and they are certainly smart enough to build a completely secure authentication system from scratch that is going to be so much better than anything anyone has ever seen, thank you very much.

So, yeah, you’re probably still going to be stuck with a million passwords.  Or maybe just half a million, but it’s still the same problem.  If someone dumps a half-ton of manure on your front lawn, are you really relieved that it wasn’t a full ton?

Password Safe to the rescue

I’ve been using Password Safe for years, and I definitely recommend it.  It’s very easy to add new entries, to quickly generate secure passwords, and to attach additional notes (like the answers to the stupid security questions that don’t have clear and definitive answers). 

Of course, it doesn’t have to be Password Safe, there are plenty of other good and free products out there, but I’m not that familiar with them so I’m going to assume that they make your computer burst into flames.

Another benefit of Password Safe, besides the lack of flames, is that the database is very portable, so you can easily copy it to another computer.  However, what about keeping the databases synchronized across multiple computers you ask?

DropBox to the rescue of Password Safe’s … rescue, or something

Since the Password Safe database is just a file, it’s actually pretty easy to keep them synchronized across a few separate machines.  As a pathological-job-hopper-turned-consultant, I’ve usually had some new machine for some reason every six months or so, and I end up with a LOT of copies of my password database floating around.  But after a few years of headaches and manually copying/merging password databases, services like DropBox came along and solved the problem for me. 

Since DropBox treats a directly on your machine as a share and automatically syncs that directory across all of your machines through the DropBox cloud (+1 Google buzzword, yay), then all you have to do is to keep your working copy of the password database on your DropBox share, and voila, you always have your up-to-date passwords at your fingertips.

Well almost.  Of course, there is one gotcha.  When you have Password Safe open in read/write mode, it locks the file (more specifically, it locks the .plk file).  This will actually prevent block the DropBox sync process and prevent it from synchronizing not just the database file, but also anything else on the share.  If you’re like me, you very rarely make changes to your password list, so I just go into Password Safe and select the option to always open database files as read-only by default, and everyone is happy.

Good luck.

 

I was having this conversation with coworker last week, and it seemed like the 100th time I’ve said this.  Then it popped up on StackOverflow this morning, and that got me typing, so here’s yet another salty developer’s rant on the topic.

There is no question that NULLs should be avoided when possible, because of the problems they can introduce several problems with indexing and query syntax. 

Due to the problems that NULLs can introduce, there has been a push to stop using them.  However, like most such movements, it has gotten out of control, to the point that some people fanatically insist that NULLs should never be used in the database.  I was in this camp for a lot of years, before I found it to be a little overzealous.

The answer is somewhere in between.  NULLs should be avoided whenever possible, but there are indeed valid business reasons for storing them. 

Often times you need to store an optional numeric value, and many people will tell you to just store a zero to indicate "no value", but this is an even worse antipattern of storing a magical value that really means something else.  What if then you can’t use zero for one field, because zero is considered a meaningful value as well, or because this value is being used as the multiple of a divisor, so you need to use some other magical value (-1?) for that field in just this case, and now you have a worse problem, because all of your optional numeric fields are now behaving differently.  Oye.

Dates are an even more compelling candidate for nullable fields.  The standard "no value" that people use in .NET is the default unassigned DateTime value, which is DateTime.MinValue, or more specifically January 1, 0001.  However, you cannot write this magic value into SQL database because the default minimum value for a SQL Server DATETIME field is January 1, 1973.  You now have to have something that checks that you are translating those values properly as they are written to and read from the database, and you have to have defensive coding all over the place that checks for whether your date fields are less than SqlDateTime.MinValue, instead of just checking whether they are equal to DateTime.MinValue.  Double Oye.

My preference is to deal with the values as they truly are, and not to build a lot of artificial constructs to hide the true meaning and usage of the field.  If a field may very well not have a value, make it nullable, and make it nullable in your application objects as well (if you language supports such a thing).  Then, anytime you are using that field, you are required to consider what should be done in the case where it is NULL, but that is actually a good thing.  Generally I am opposed to making developers waste brain cycles on unnecessary code complexity, but that is because it steals focus away from the true business problem being solved; however, in this case, the lack of a value IS part of the true business problem and must be thought through.  If you are just defaulting these values, then the developer writing a formula or algorithm will be less likely to think through those edge conditions where the values are missing, and may not even realize at the time that it is a possibility that those values are missing.