I don't get NFT

I only recently learned about the existence of NFTs as a "thing".  If you are also unfamiliar, NFT stands for "Non-Fungible Token".  CNN has an explanation here, but t's essentially a unique digital token, stored on a blockchain, that represents some digital asset.  Apparently NFTs have recently become the latest hot trend, with some of them selling for hundreds of thousands of dollars.  

However, this Slashdot post points out that there are some potential issues with NFTs.  Basically, NFTs don't actually store the asset you're purchasing.  So if you buy an NFT for an image, the image doesn't actually live on the blockchain.  You've only bought a reference to the image, which is actually hosted someplace else.  So if whatever server or service is hosting that image goes away, you will no longer be able to access it, regardless of owning the NFT.

So I guess what I'm confused about is: what's the point?  I mean, what are you really getting when you buy an NFT?  In a theoretical sense, I can see how an NFT is better than "conventional" digital assets in that it's not tied to a particular service.  Your ownership of that item is recorded in you crypto wallet which is independent of any particular service an can be used with multiple NFT marketplaces.  And that's a good thing. 

But when you look at it functionally, there's not really much difference.  The actual asset still exists completely independent of the blockchain, so it's not like a physical asset - there might only be one token, but you can still infinitely duplicate the asset.  And as far as I can tell, buying an NFT doesn't actually mean you're purchasing the copyright for the asset.  So you're just buying a copy and there's nothing to stop anyone from making other copies.  And because the asset isn't stored on the blockchain, if you want to ensure you always have access then you need to download a copy of it.  So...how is this different from buying a service-specific digital asset?

It seems like the point is less the actual asset and more that NFT is the same thing as Bitcoin - that it's just a different way to speculate on blockchain stuff.  Especially when you're talking about something like spending $2.5 million for jack Dorsey's first tweet, it's hard to see any other rational explanation.  But even for less absurd cases, it's not clear to me what the practical benefit is.  The main reason that blockchain "works" for cryptocurrency is because the thing on the blockchain is the thing you're transferring.  As soon as you introduce a disconnect between the thing being traded and the thing on the blockchain, it seems like you lose a lot of the benefit of the blockchain.  

Thinking about DNS over HTTPS

I read an interesting article on the drawbacks of DNS over HTTPS (DoH) the other day.  This comes on the heels of the news that Mozilla is rolling out DoH to all Firefox users by default

I'd never really thought too much about DoH.  In general, more encryption is usually better, so my initial thought was "it's probably a good thing", but that's about as deep as it went.  After reading a little more about the down sides, I'm less convinced.  I still think it's a probably good thing that DoH exists, but I'm note so sure that it's a good idea to push everyone toward it.

My main reservation at this point is that DoH seems architecturally wrong.  It introduces a way to do DNS queries that's not really compatible with the old way and it's not clear to me that it offers any really big wins.

Of course, I'm not saying that DoH has no benefits or use-cases.  There are definitely cases where it can be useful and add another layer of privacy.  But it kind of reminds me of PHP "security" features like safe_mode in the sense that it does solve a legitimate problem, and does so in a way that "works" (for certain definitions of "works"), but solves it at the wrong layer and in a way that can interfere with other legitimate things.

As this blog from the PowerDNS team discusses, DoH is not a panacea in terms of privacy.  Yes, it adds a layer of encryption, and that is definitely useful in some cases.  But it doesn't do anything to address the myriad other ways in which your online activity can be tracked.

Of course, that depends very much on whom you want to stop from tracking you.  Obviously it does zero to stop advertisers or website operators from tracking you - they do their tracking at a much higher level.  It also doesn't stop your ISP from tracking you - even if everything else is encrypted, you can't stop your ISP from knowing the IP addresses you visit.  I mean, that's just how the web works.  And from an IP address, you can usually determine the website pretty easily.  And, of course, your DoH provider still has access to all your DNS requests, so you better make sure you trust them.

For me, personally, the bottom line is that DoH doesn't give you anything that you don't already get with a half-way decent VPN provider.  Granted, the VPN provider is then your single point of privacy failure, so you better make sure you pick a reputable on (I like and recommend Private Internet Access).  But a VPN covers pretty much everything you can do at the network level, not just DNS for web requests.  Of course, you still need browser privacy plugins to block tracking at higher levels in the stack, but sadly that's necessary either way.

New browser plugins for KeePass

Almost three years ago I wrote a post about setting up a browser plugin for KeePass.  That plugin was chromeIPass and it worked pretty darn well.

Now fast-forward to a few months ago.  My wife's laptop broke down and I had to re-install Windows on it.  In the process, I tried to set up chromeIPass and discovered that it's dead!  Well, mostly dead, anyway.  It's open-source, and the source is still available, but it's no longer available in the Chrome app store.  So it's effectively dead.

So I started looking for alternatives.  The good news is that there's a fork of chromeIPass called KeePassHTTP-Connector. That still exists in the Chrome store.  However, it's also been discontinued!  Apparently it's deprecated in favor of KeePassXC-Browser which is a similar plugin for KeePassXC.  Apparently KeePassXC is a cross-platform re-implementation of KeePass.  I'm not sure why that's needed, since KeePass is written in C# and runs under Mono, and .NET core is now cross-platform anyway, but whatever.  The one nice thing about that browser plugin is that it uses a KeePassNatMsg plugin to communicate with KeePass.  Apparently that's more secure because it doesn't involve talking over HTTP.  But apparently it doesn't work correctly with "real" KeePass.  At least, it didn't for me - the plugin segfaulted when I tried to configure it.

Luckily, I did find a currently supported plugin that actually seems fairly good - Kee.  This is actually intended for a separate password manager, also called Kee, which I gather is some kind of paid service based on KeePass.  (Or something.  To be honest, I didn't really look into it - I only cared about the browser plugin.)  The Kee plugin is based on the old KeeFox plugin for Firefox, but this one also runs in Chrome.  It uses the KeePassRPC plugin for communication with KeePass.

If you used KeeFox in the past, this plugin is equally painless to use and configure.  Just install the KeePassRPC plugin, fire up KeePass, and install the browser plugin.  Kee will automatically attempt to connect to the RPC server and KeePass will prompt you to authorize the connection by bringing up a window with an authorization code.  Just enter that code into the window that Kee opens and click "connect".  Done!  Now when you visit a site that's in your KeePass database, Kee will put icons you can click in the login boxes and auto-populate the login form.  (The auto-population can be turned off - the convenience of that functionality is fantastic, but the security is iffy.)

So at least there's still a good, supported KeePass browser plugin out there.  I suppose this is one of the pitfalls of "roll your own" systems based on open-source software.  Since KeePass doesn't bundle a browser plugin, like many of the proprietary password managers do, we're forced to rely on the community, which can be both good and bad.  The bad comes when the "community" is basically one guy who eventually loses interest.  And while it's great that the source is there for anyone to pick up, it's important to recognize that adopting a new software project requires a substantial time commitment.  Free software is free as in "free puppy", not "free beer".

A different take on password managers

I've posted several entries in the past about the benefits of password managers.  Well, I just read a very interesting article that also detailed some of the risks of password managers.

The article is by a security professional who offers a very good take on some of the aspects of password management that I've rarely considered.  For instance, using a password manager can very much entail putting all your eggs in one basket.  For instance, what if you get malware that steals your master password?  What if you forget the password?  That might seem far-fetched, but you never know - you could hit your head, have a stroke, or any number of things.  So in addition to security, there are things like recovery strategy to consider.

While I've been guilty of making blanket statements that "everybody should use a password manager," I now see that that's a mistake.  I still believe password managers are a very good for many, if not most people, but it needs a more nuanced assessment.  Depending on your risk profile and tolerance, you might want to avoid putting all your eggs.  You might want to avoid password managers altogether, or use them only for low-value, or perhaps use multiple password vaults to partition things by importance.

The point is that security is not a one-size-fits-all thing.  There are lots of use-cases and it's important not to get stuck in thinking that yours is the only one or even the most common or important one.  Consider the situation and the trade-offs involved before making a decision or recommending a course of action to others.

Yup, password expiration is dumb

I posted an entry a while back about passwords.  Well, turns out that Microsoft is no longer recommending rotating your passwords and is removing the password expiration policies from Windows.

So yup, I was right.

But really, what was the point of always changing your passwords anyway?  Well, I guess it does mitigate against the possibility that a re-used password has been compromised somewhere else.  But what's the cost?  Users can never remember their passwords.  And since coming up with a good, memorable password is hard, they're not going to put in the effort. Instead, they'll come up with some pattern that meets the minimum complexity requirements and just cycle through it. 

Is this better?  I'm no expert, but it's not clear to me that it is.If you want extra protection, there are better ways to get it.  For example, setting up two-factor authentication.  That's also a bit of a pain for users, but at least it provides more real protection.

And on a semi-related side-note, I'd like to point out KeepassAndroid now integrates with Firefox Mobile.  I've mentioned this app in some previous posts about KeePass.  I do a lot of my non-work web browsing on my phone these days, so this app is really a necessity for me.  This new integration is really nice because it means I can now get the same user experience on both my laptop and my phone.  I just tap on the login box and get promoted to auto-fill the form.  Perfect!

Security, passwords, and end users

Note: I started this entry two years ago and it's been sitting in my drafts folder ever since.  However, while the links might not be news anymore, the underlying issue is the same.  So I cleaned it up for another From The Archives entry.

A while back, there was a story going around about how the guy who invented the password strength rules that you see all over the web now regrets it.  That made me think about how we approach these kinds of issues and the advice we give to non-technical users.

Security is one of those areas of computing where there are a lot of cargo cults.  Relatively few people, even among IT professionals, seem to have a good handle on how to secure their systems.  So they rely on guidelines like these from the "experts", often following them blindly without any real understanding of the rationale.

And you can't really blame them - security is hard.  Even knowing what you need to defend against can be a tall order.  And with some of the biggest companies in the world being compromised left and right (for example, the Equifax hack, which should scare the heck out of you if it doesn't already), it's clear that this is not a resource problem that you can just buy your way out of.  Not even big tech companies are immune, so what chance does the average user have?

Well, unfortunately, for things like the Equifax breach, the average user doesn't have much to say about it.  Once a third-party has your personal information, you really have no choice but to rely on them to secure it.  And if they don't do a good job, well...you're sorta just out of luck.  I mean, you can always sue them, but let's be realistic: for private individuals, the amount of time and money required to do that is prohibitive.  It's cheaper and less painful to just absorb the loss and get on with your life.

Passwords are a different story, though.  Those are one of the few pieces of security that are (mostly) under the control of the user.  So we as professionals can offer some guidance there.  And if the top passwords revealed from various database breaches are any indication, we should offer some.

These days, there's really only one piece of advice that matters: get a password manager and use it for everything.  I like KeePass, but 1Password, LastPass, and a number of other good programs are available.  These days we all have more website logins than we can realistically remember, so it's impossible to follow the old advice of using strong passwords AND not reusing them AND not writing them down.  By using a password manager, we compromise on the "not writing it down" part and write down our passwords securely so that we can keep them strong and unique without making our lives difficult.

Of course, there will always be a few passwords that you just need to remember.  For instance, the master password for your password manager.  For these, the standard advice is to use long passwords containing number, letters, and special characters.  Probably the easiest way to do this and still keep the password memorable is to use a passphrase.  So rather than one word, use a short phrase containing several words and insert some punctuation or other special characters.  For example, the password Bob has _17_ "Cats"! isn't that hard to remember, but it's 20 characters long and  contains letters, numbers, capital and lower-case letters, punctuation, and spaces.  Yeah, it's harder to type and remember than "12345", but it's way easier than something like "UD09BhbjH7" and it fulfills the complexity requirements.

For more important accounts, you can also do things like enabling two-factor authentication, which adds another layer of security.  Typically this involves sending a code to your phone via text message or an app like Google Authenticator and entering that when you log in.  Even this isn't fool-proof (see SIM swapping scams), but it's one more hoop that someone trying to access your account has to jump through.

So forget the annoying rules about changing passwords every month and things like that.  Pick a handful of good passwords for the stuff you really need to type out and just use a password manager for everything else.  There's no reason to remember a bajillion obscure bits of information if you don't need to.  After all, that's why we have computers in the first place.

Electronic voting

This XKCD comic pretty much sums up my reaction every time someone mentions electronic voting.  I usually explain it with an analogy involving Scotch tape and bubble gum, but same idea.

As a side-note, there's an interesting response to this here.  The criticism, essentially, is that the comic is comparing apples to oranges.  For aircraft and elevators we're mostly concerned about accidental failures, whereas for voting machines the issue is protecting against intentional attacks.  So planes and elevators are only considered "safe" because we're not counting "being blown up" as a valid scenario that they need to defend against.

That's a fair criticism, but that's not really the point. When I hear regular, non-techie people talking about "computerize voting", they're not interested in the electronic replacements for old mechanical voting machines.  They're interested in voting online, like you'd vote in poll on Facebook.  That's a very different problem than securing a computerized voting machine, and much harder to solve.

KeePass browser plugins

In my last post about KeePass, I mentioned that you can integrate your KeePass password database with your web browser.  In this post, I'll tell you more about how to do that and why it's an extremely handy thing.

Why bother?

So why would you want to bother with integrating your browser with KeePass?  I mean, most browsers have a feature to remember your passwords anyway, so why not just use that?  Or if you want to use KeePass, why not just use that auto-type feature I talked about in the last post?

It's true, you could just use the password manager that's built into your browser.  Pretty much all of them have one, these days.  Most of them will even secure your data with a master password.  They may even synchronize your passwords to the cloud, so you can access them on more than one device.  Granted, that's pretty handy.

However, browser password managers generally just do passwords - they don't allow you to enter extra information or attach files like KeePass does.  They also don't work for things outside the web browser, like for security software such as VPN clients.  So they don't provide you with a single, secure location for all your important account information.  But more importantly, they're generally tied to a single browser.  Sure, Google Chrome can store and synchronize all my passwords, but what if I decide I don't like Chrome anymore?  Maybe I just bought a Mac and decided I really like Safari.  Is there an easy way to get my passwords out of one browser and into another?  I don't know.  

By using KeePass with a plugin for your browser, you can get the best of both worlds.  KeePass itself gives you more power and features than browser password managers and allows keeps you from being tied to a single browser.  Using a browser integration plugin adds on the ability to have the browser automatically fill in your username and password when you visit a website.  It's not quite as convenient as the browser-integrated password managers, but it still pretty good.  And it's definitely a lot easier than trying to use auto-type or copy-and-paste to fill in password forms.

What are my options?

In general, there are a lot of plugins available for KeePass.  Just look at the list.  Or maybe don't - you probably don't care about 90% of those plugins.  The main thing you need to know about is which browsers have plugins available. 

Short answer: Chrome, Firefox, and Safari.

Long answer: Chrome, Firefox, and Safari have proper browser plugins available.  The Chrome plugin also works in Vivaldi and possibly other browsers that are based on Chrome.  There are also form-filling plugins that work with Internet Explorer.  To my knowledge, there is no plugin support available for Microsoft Edge.

For this entry, I'll just talk about setting up a plugin with Chrome.  We're going to use a Chrome extension called ChromeIPass.  It adds a KeePass button to the toolbar in Chrome and can automatically detect login forms on webpages you visit.  It works with a KeePass plugin called KeePassHttp.

First, you need to install the KeePassHttp plugin.  Start by going to the KeePassHttp website and clicking the "download" link, or just download it directly here.  Sadly, KeePass doesn't have a nice way to install plugins - you just have to copy the plugin file to the KeePass plugins folder on your system.  Inconvenient, but fortunately not something you need to do very often.  On most computers, this will be C:\Program Files (x86)\KeePass Password Safe 2\Plugins.  So just copy the KeePassHttp.plgx file that you downloaded and paste it into that location.  Since this is a system directory, you will probably be prompted to grant access.  Click "continue" to copy the file.  Note that if KeePass is running, you will need to close and restart it for it to detect the plugin.

Click "continue" when prompted to allow access to copy the plugin.

Now that the KeePassHttp plugin is installed, KeePass will be able to communicate with Chrome.  You just need to install the ChromeIPass extension.  You can do that by going to the Chrome web store page here and clicking the "Add to Chrome" button.  

So...now what?

OK, now that ChromeIPass is installed, what do you do with it?  Well, not really much until it's time to log into a site.  So pick a site that's in your KeePass database and go there - I'll use sourceforge.net for this example because it's a pretty standard login form.

The first time you try to log into a site using ChromeIPass, you'll need to connect it to your KeePass database.  You should notice a KeePass icon is now in your toolbar.  Make sure KeePass is running and click that button.

You should see a "Connect" button.  Click that and KeePass will prompt you to add a new encryption key for the KeePassHttp plugin.  This is a security mechanism - the KeePassHttp plugin encrypts its communication with your KeePass database and this is just the initial step where it sets that up.  Don't worry about the details right now - just type in a unique name for the key, maybe based on your browser and computer, e.g. "Laptop - Chrome".  You only have to do this the first time you connect a browser to your database - after that, the encryption is automatic.

Now that ChromeIPass is connected to your KeePass database, you can click the ChromeIPass button in your toolbar and click the "Redetect Credetials Fields" to fill in your username and password.  Alternatively, you can just refresh the webpage and they should be auto-filled.  You won't see anything in the browser yet, but KeePass itself ill prompt you to allow access to the password for this site.  You can check the "Remember this decision" box to not be prompted to allow access the next time you visit this site.

(I should probably stop to acknowledge that this thing of having to grant a site access to your KeePass database before you can log in is kind of a drag.  I agree, it is somewhat annoying.  This is actually a security feature of KeePassHttp - that's the portion of this that runs inside KeePass itself and allows the ChromeIPass extension to talk to it.  It actually has a lot of security-related settings.  This is actually a good thing, though, because it essentially provides a way for other programs to read your KeePass database, and you want to make sure that malware or dodgy websites aren't able to do that.  However, if you want to disable some of these settings, like prompting to allow access, you can do that by going into KeePass and selecting the "Tools > KeePassHttp Options" menu item.  The KeePassHttp documentation has some more information on the available settings.)

The good news is that now you're done!  After you allow access to KeePass, ChromeIPass will automatically fill in your username and password.  If you selected the "remember" option when allowing access to the site, ChromeIPass will automatically fill in your login info the next time you visit the site, no action required.  You will only have to allow access the first time you visit a new site of if you elect not to have KeePass remember the approval.

If you're so inclined, ChromeIPass has a number of other features, as detailed in the documentation.  For instance, it can save or update entries automatically when you enter a password into a webpage; it has a built-in password generator that lets you create strong passwords right in the browser; it can customize the login fields for non-standard login forms; and it provides a handy right-click menu to fill in passwords and access other functionality.  

Hopefully this will help get you started.  Using a password manager is a must for keeping your accounts secure these days, and integrated browser support makes using one that much easier, which means you're more likely to keep using it.

Using KeePass

You should be using a password manager.  If you're a technical person, this is probably not news to you - you're very likely already using one.  

This article is for the non-technical people.  People like my wife (hi, honey!) and my mom.  People who access a lot of websites and have a lot of passwords to remember.

Security 101

So why is using a password manager a good idea?

Well, you may have seen guidelines for cyber security that tell you things like:

  1. Don't write down your passwords.
  2. Don't reuse passwords on different sites.
  3. Don't use short, easy to guess passwords.
  4. Don't use passwords that are easy to figure out from public data (like a birthday that anyone can get from your Facebook profile).

Such guidance raises the question: if I have to use long passwords that aren't related to anything in my life, and I can't reuse them or write them down, how the hell am I supposed to remember them?!?

This is a totally reasonable question.  Yes, ideally we would all memorize a hundred different 32-character-long, randomly generated passwords.  But in real life, nobody can actually do that.  So a password manager is a good compromise.

What is a Password Manager

My mother has a little paper "password book" that she keeps in a drawer next to her computer.  When she has to create a new account for some website, she writes down all the login information in that book so that she can look it up later.

A password manager is the digital equivalent of that password book.  It's an application that lets you record your login information and them look it up later.  Most password managers have lots of other handy-dandy features as well, but that's the core of what they do.

So how is this different from, say, writing down all your passwords in a Word document on your desktop?  Well, a password manager encrypts all your data.  It requires a "master password" to decrypt your information, so if some nasty hacker steals that file, they won't be able to actually read it.  

Is this as secure as just memorizing all your passwords?  No.  But as we said, nobody can do that anyway, and this is one heck of a lot more secure than the alternatives, i.e. reused or weak passwords.  With a password manager, you can still have strong, unique passwords for all your sites, but you're relieved of the burden of having to remember them all.

About KeePass

There are a number of password managers out there, but the one I'm going to talk about is KeePass.  It's a free, open-source password management application that will run on Windows, Linux, and Mac, and has compatible apps available for iOS and Android.  KeePass works offline (i.e. it requires no internet connection and doesn't depend on any online services), but it's possible to sync your KeePass passwords between devices using file sync tools like DropBox or OneDrive.  So it provides you some flexibility, but you aren't beholden to a single company that can get hacked or go out of business.

KeePass creates files password files that end with ".kdbx".  You can open those files from within KeePass or double-click on them in Window Explorer.  When you try to open one, KeePass will prompt you for the master password to that file.  Every KDBX file has its own master password.  This allows you to do things like create a password file to share with the rest of your family, and have a different one for the accounts that are just yours.  (That's a topic for a different post.)

One of the handy extra functions of KeePass is that each entry in your password save can have a bunch of extra data associated with it.  For example, you can add custom fields and attach files to each entry, which are handy for things like account validation questions and activation files for software licenses.  Basically, you can keep all the important information in one place.  And since KeePass encrypts your entire password file, it will all be kept secure.

Using KeePass

So how do you use KeePass?  Let's walk through it.

Step 1 - Download

The first thing you need to do is to get yourself a copy of KeePass.  You can go to this page and click the download link for the "professional edition".  (There's not really anything "professional" about it - it's just a newer version with more features.)  When that's done, you can double-click the file to install it like any other program.

You can also install KeePass through Ninite.  If you're not familiar with Ninite, I strongly recommend you check it out.  It's a great tool that makes it brain-dead simple to install and update a collection of programs with just a few clicks.  You basically just select a bunch of applications you'd like to install from a list, click a button, and you get an installer program you can run to put everything you selected on your computer.  And if you run that program again later, it will actually update any of those programs that have a newer version.  It's very slick and a real time-saver.

Step 2 - Create a password safe

 Next, open up KeePass and click "File > New".  You will be prompted to choose where you want to save your new password database.  Choose a name and folder that work for you.  Remember - your password database is just a regular file, so you can always move or rename it later if you want.

After that, you should get a dialog that looks like this:

This shows several options for securing your password safe.  But don't worry about that - the one you really want is the first one, "master password".  So choose a password and type it in.  If you click the three dots on the right, KeePass will display the password as you type, so that you don't have to re-enter it.

There are two important things to note when choosing a master password.  First, since it's going to protect all your other passwords, you want to make it good.  KeePass provides a password strength meter to help you judge, but the main things to bear in mind are that you want a range of different characters and you want it to be long.  And no, ten letters does not qualify as "long" - it should be more of a passphrase than a password.  One common technique is to use a full sentence, complete with capitalization and punctuation (an maybe some numbers, if you can work them in).  That will generally give you a pretty strong password, but it will still be easy to remember.

The other important thing to remember is that the password to a KDBX file is your encription key for that file.  That means that the only way to decrypt the file is with that password.  If you forget your master password, your data is gone forever.  So write down your master password and keep it in a safe place until you're certain you've committed it to memory.  And if you want to change your master password later, make sure to make a backup copy of your KDBX file first.

After you've chosen a master password, you should see a screen that allows you to configure some of the settings for your password file.  However, you don't really need to worry about this - those are all optional.  You can safely click the "OK" button to just continue on.

Step 3 - Organize your passwords

Alright!  You now have a password database set up.  You should see a list of groups on the left and a list of password entries on the right, like in the image below.  These are the sample groups and entries that KeePass creates by default.  They're just to give you an idea of how to use your password database - you can safely delete them at any time.

You can click on each group at the left to see what entries it contains.  The groups are basically like folders in Windows.  There's a top-level folder, and it contains a bunch of sub-folders and each of those sub-folders can contain other folders.  So in the screenshot, you can see that "NewDatabase" is highlighted in the group list.  That's the top-level folder for my example database.  You can see on the right that it contains two entries.  You can move an entry into another folders by dragging it from the entry list on the right onto one of the folders on the left.

Step 4 - Create passwords

To add a password entry to your database, select "Edit > Add Entry" from the menu.  That will bring up the entry edit screen.  This is the same screen you'll see when you double-click on the title of an existing entry, except that it is mostly blank.

There are a lot of tabs and options on this screen, but you don't really need to worry about those.  The main things are right in front of you: the entry title, user name, and password.  You'll probably also want to fill in the URL field with the web address of the site this information is for.  This will come in handy if you want to use a KeePass plugin for your web browser (which we'll cover in another post).  When you're done entering your info, click the OK button to create the entry.  You should then select "File > Save" from the menu or push the "save" button on the toolbar to save the changes to your password database.

You'll probably notice that there's already a password filled in.  KeePass will generate a random password for new entries.  You are free to change this yourself or use the button to the right of the "repeat" box to generate other random passwords using different rules.  KeePass has a password generator that lets you specify the allowed characters and length for a random password, which is handy for those sites that insist on specific password length or complexity rules.

Step 5 - Getting your passwords out

Now let's back up and say you've just started up your computer, are logging in to some website, and want to get a password out of KeePass.  The first thing you need to do is open up your password database.  You can do this by double-clicking on it in Windows Explorer or by opening up KeePass then selecting your database from the "File > Open" menu.  When you open the database, you'll be greeted by a screen asking you to enter your master password - you know, the one you came up with in step 2.  (Hint: remember that you can click the button with the three dots to display the password as you type it.)  After you enter your master password, the database will be decrypted and you'll find yourself and the entry browsing screen from step 3.

There are several ways to get your passwords out of KeePass.  Here's the list in order of preference:

  1. Use a browser plugin to automatically fill in login forms.  Since most of the passwords you end up creating are for websites, setting up your browser to fill in the forms from your KeePass database makes life much easier.  I'll talk about how to do that in the next post.  But don't worry - it's not all that hard.
  2. Use auto-type.  This is a feature of KeePass where you to click a button in the KeePass window and it will automatically send the keystrokes for your username and password to the last window you used.  So, for example, you would navigate to the login page of a site in your web browser, click in the username box, and then switch over to the KeePass window and click the auto-type button on the toolbar (the one that looks kind of like some keyboard keys - hover your cursor over the buttons to see the descriptions).  By default, the auto-type feature will type your username, the "tab" key, your password, and then the "enter" key.  This will work for probably 90% or more of login pages, but it's not universal, so be aware of that.
  3. Copy them to the clipboard.  If all else fails, you can always just copy your passwords to the clipboard so that you can paste them into another window.  KeePass makes this fairly easy.  In the main password list that you saw in step 3, when you double-click on the actual username or password for an entry in the list, it will copy that to the clipboard.  This saves you having to open up the entry edit screen and copy things there.  You can then switch to another window and paste the data into a login screen.
  4. Just read it.  Last, but not least, you can always go low-tech and just read the passwords out of the window.  Just double-click the name of your entry, then click the "three dots" button to make the password visible.  Clearly this is not great, but sometimes it's necessary.  For example, you will need to do this when entering a password on a system that doesn't have KeePass installed, such as to login into your Amazon or Netflix account when setting up a Roku or other streaming media system.

Conclusion

With any luck, I've made this "password manager" thing sound good enough for you to try it out.  You really should look into it.  Password reuse has become increasingly dangerous, with hackers trying the usernames and passwords they harvested from one hack on other sites just to see if they work.  Password cracking tools have also advanced a lot in recent years, including information gleaned from previous attacks, so relying on things like "133t 5p34k" passwords is no longer good enough.  A decent password manager, if used consistently with randomly generated passwords, will provide you with a good trade-off between convenience and security.

Getting a password manager

After shamelessly reusing passwords for far too long, I finally decided to get myself a decent password manager. After a few false starts, I ended up going with KeePass. In retrospect, I probably should have started with that, but my thought process didn't work out that way.

Originally, my thought was that I wanted to use a web-based password manager. I figured that would work best as I'd be able to access it from any device. But I didn't want to use a third-party service, as I wasn't sure how much I wanted to trust them. So I was looking for something self-hosted.

PPMA

I started off with PPMA, a little Yii-based application. It had the virtue of being pretty easy to use and install. There were a few down sides, though. The main one was that it wasn't especially mobile-friendly, so there were parts of the app that actually didn't work on my phone, which defeats the whole "works on any device" plan. Also, it really only supported a single user, so it's not something I could easily set my wife up on as well. (To be fair, the multi-user support was sort of there, but it was only half-implemented. I was able to get it basically working on my own, but still.)

More importantly, I wasn't entirely confident in the overall security of PPMA. For starters, the only data it actually encrypted was the password. Granted, that's the most important piece, that's sort of a minimalist approach to account security. And even worse, I wasn't 100% convinced that that was secure - it's not clear to me that it doesn't store a password or key in session data that could be snooped on a shared server. Of course, I haven't done an extensive analysis, so I don't know if it has any problems, but the possibility was enough to make me wary and I didn't really want to do an extensive audit of the code (there was no documentation to speak of, and certainly nothing on the crypto scheme).

The next package I tried was Clipperz. This is actually a service, but their code is open-source, so you could conceivably self-host it. I had a bit more confidence in this one because they actually had some documentation with a decent discussion of how their security worked.

Clipperz - beta UI

The only problem I had with Clipperz was that I couldn't actually get it to work. Their build script had some weird dependencies and was a pain to deal with (it looked like it was trying to check their source control repository for changes before running, for some reason). And once I got it installed, it just flat-out didn't work. I was able to create a new account, but after that every request just returned an error out. And to make things worse, it turns out their PHP backend is ancient and not recommended - it's still using the old-school MySQL database extension. The only other option was the AppEngine Python backend, which wasn't gonna work on my hosting provider. So that was a bust.

It was at that point that I started to think using a web-based solution might not be the best idea. Part of this is simply the nature of the web - you're working over a stateless protocol and probably using an RDBMS for persistence. So if you want to encrypt all the user's data and avoid storing their password, then you're already fighting with the medium. A desktop app doesn't have that problem, though - you can encrypt the entire data file and just hold the data in memory when you decrypt it.

It also occurred to me that accessing my passwords from any computer might not be as valuable as I'd originally thought. For one thing, I probably can't trust other people's computers. God alone knows what kind of malware or keyloggers might be installed on a random PC I would use to access my passwords. Besides, there's no need to trust a random system when I always have a trusted one with me - namely, my phone.

Great! So all I really need is a password manager than runs on Android.

Well...no, that won't do it. I don't really want to have to look up passwords on my phone and manually type them into a window on my desktop. So I need something that produces password databases that I can use on both Android and Windows.

Luckily, KeePass 2 fits the bill. It has a good feature set, seems to have a good reputation, and the documentation had enough info on how it works to inspire some confidence. The official application is only Windows-based, but there are a number of unofficial ports, including several to iOS and Android. It's even supported by the Ninite installer, so I can easily work it into my standard installation.

KeePass2

For me, the key feature that made KeePass viable was that it supports synchronization with a URL. There are extensions that add support for SSH and cloud services, if you're into that sort of thing, but synchronizing via standard FTP or WebDAV is built right in. KeePass also supports triggers that allow you to automatically synchronize your local database with the remote URL on certain events, e.g. opening or saving the database.

For the mobile side, I decided to go with Keepass2Android. There are several options out there, but I chose this one because it supports reading and writing the KeePass 2.x database format (which not all of them do) and can directly read and write files to FTP and WebDAV. It's also available as an APK download from the developer's site, as opposed to being available exclusively through the Google Play store, which means I can easily install it on my Kindle Fire.

Keepass2Android also has a handy little feature called "QuickUnlock", which allows you one chance to unlock your database by typing just the last few characters of your passphrase. If you get it wrong the database is locked and you need to enter the full passphrase. This addresses one of my main complaints about smart phones - the virtual keyboards work to actively discourage good passwords because they're so damned hard to type. I chose a long passphrase which takes several seconds to type on a full keyboard - on a virtual keyboard, it's absolutely excruciating. This way, I don't have to massively compromise security for usability.

So, in the end, my setup ended up being fairly straight-forward.

  1. I install KeePass on all my computers.
  2. I copy my KeePass database to the WebDAV server I have set up on my web hosting.
  3. I set up all my computers with a trigger to sync with the remote URL.
  4. I install Keepass2Android on my phone and tablet.
  5. I configure them to open the database directly from the URL. Keepass2Android caches remote databases, so this is effectively the same as the desktop sync setup.
  6. Profit! I now get my password database synchronized among all my computers and devices.

I've been using this setup for close to a month now, and it works pretty darn well. Good encryption, good usability, plenty of backups, and I didn't even have to involve a third-party service.

Apparently we were "hacked"

You know that weird jump in auto-incremented IDs we saw in our database at work the other day? Well, we discovered the cause: apparently we were "hacked".

I use the work "hacked" in the loosest sense of the word. The culprit contacted us the next day, making a number of demands and issuing veiled threats. I may get into the details in another post (it's a long story), but the point is that he appeared to have, at best, a script kiddie level understanding of security. He pointed out a number of flaws in the site, but the ID incrementing was the only one that could actually have caused us any real trouble - and he didn't even mention it! We assume that he actually did that by accident and didn't realize the potential implications if we ran out of ID numbers.

The flaw allowed the ID incrementing was actually quite simple. No SQL injection or cross-site scripting. It was a simple case of passing too much data into a function.

Here's how it works. Our site, which runs on PHP and MySQL, is built on a custom MVC framework. It uses a custom Active Record-style ORM, which is where the flaw lies. The ORM performs database updates and inserts by validating the object's fields against the database schema. Basically, it reads the schema from the database, compares that with the data to be updated, and constructs the SQL accordingly. So when you execute the save() method on an object, it will save the values for the fields that appear in the table schema, but ignore any other fields in the object. The ORM also has static update() and insert() methods that take an associative array, mapping the indexes to field names and performing this same validation. So if you have an array of data, only some of which maps to actual columns in the underlying table, you can just pass the whole thing and not have to go through and separate out the fields you need to save.

That last point is where we got in trouble. We have a method that adds items to our media table. It takes an array of data, does some sanitizing and validation, calls the insert() method to add it to the media table, and adds appropriate records to other tables. The problem was that, in the place where this was called most frequently, we were passing in $_POST as the data array. And while this method did sanitize the fields that we wanted to add to the database, it didn't check for extra fields that just happen to be valid fields in the media table. So, to make a long story short, if you were to put an "id" field in the POST and assign it an integer value, our ORM would happily add that field and value to the INSERT statement it sent to the database.

Of course, this was easily fixed. In fact, it wasn't even hard to find. I did a fair amount of work on our ORM at the beginning of the year, so once I made the connection between the "hacker" and the ID number jump, the source of the bug was immediately obvious. It's just one of those things that nobody ever thought to check until it became a problem.

So the moral of the story is: security is all about attention to detail. Following the "rules" is all well and good, but it's not enough. In our case, we were sanitizing data to protect against XSS attacks and using PDO prepared statements to protect against SQL injection attacks, but it wasn't enough. By forgetting to check for unexpected additional input, we left ourselves open to a completely different type of attack. Of course, it's a significantly less serious class of attack - maxing out our auto-incrementing IDs is recoverable, if annoying - but it's still an issue.

With any luck some good will come out of this. I think we've all learned to be a little more mindful of such issues. And perhaps this will act as a cue to management that maybe - just maybe - it would be better to do some actual testing and review of new code before it's released, rather than just pushing things into production and hoping they work.

Sympathy for the devil

I know there are those in the Linux community who will regard this as equivalent to spitting on the cross while blaspheming the holy spirit, but sometimes I feel sorry for the people at Microsoft. They have a tough job and they are frequently blamed for things that aren't their fault.

What made me think of this was Jeff Atwood's follow-up to his Windows spyware post.

I understand the pressure to be backwards compatible. There's no end of Vista blowback based on minor driver compatibility issues. The "if it doesn't work, it's automatically Microsoft's fault, even if the software or hardware vendor is clearly to blame" mentality is sadly all too common. But given the massive ongoing Windows security epidemic, was defaulting regular users to Administrator accounts-- exactly like Windows XP, Windows 2000, and Windows NT before it-- really the right decision to make?

In many ways, Microsoft is in a perpetual no-win situation. On the security front, for example, they are besieged by the evil forces of malware. However, every time they try to improve the situation, end users scream blood murder. For example, was the weird "quasi-administrator with prompting" a good idea? Probably not, but it's better for the average user than silently allowing the installation of spyware, and yet everyone seems to hate it. But what's the alternative? To make accounts regular users by default? How would the average Windows user would feel about that? I don't know, but I have read a many comments by recent converts to Linux who seem to think that entering a password just to install some software is completely stupid and unreasonable, so I can't imagine it would be universally hailed as a great improvement.

And, of course, there's always the breakage that accompanies any OS upgrade. For example, remember Windows XP Service Pack 2? I seem to recall widespread complaints about things breaking when that was rolled out. And we're seeing the same thing now with Vista. And who do people blame? Is it the ISV who are still coding with Windows 98 in mind? No - they blamed Microsoft.

What really kills me about this situation is when I read Raymond Chen's accounts of the efforts of the Windows App Compatibility team. For example, consider this sample chapter from his book. From the cases he mentions there, it is completely obvious that Microsoft takes backward-compatibility seriously. Very seriously. In fact, you might even say they take it too seriously.

Think of it this way. On Linux you're lucky if you can get source compatibility for an application that's more than 5 years old. Microsoft has binary compatibility with a large range of programs that are 10 or 15 years old. They're working with third-party binaries, diagnosing obscure bugs, and implementing fixes to keep the applications working, even though it's by sheer luck that they ever worked in the first place. As a programmer, it's hard to overstate how impressive this is. And yet all anyone ever focuses on is the problems they didn't fix.

Then there's the political angle. There are lots of people out there who seem to think that Microsoft can do no good. Everything they do is viewed with suspicion. Anyone who works for Microsoft has to contend with accusations that he is either in on the conspiracy or is bowing down to "the man" every time he says something they MS-haters don't like. That's got to be at least a little demoralizing. And while a certain degree of animosity is certainly warranted (as it is with practically any large business), it's not like Microsoft has been running child sweatshops or dumping toxic waste in the local drinking water. It just seems way out of proportion.

So no matter what the people in Redmond do, it seems like there's always somebody pissed off at them. And it's a shame, because they really do do some good work. The .NET world has lots of neat technologies and is a very cool place for developers. Even though OpenOffice may be good enough for many, MS Office is by far the best office suite available. And, last but not least, Windows, despite it's flaws (and they are legion) is a very impressive feat of software engineering. Not to mention that Microsoft employs a number of very bright people.

So, to the Linux community, I say, let's give Microsoft a chance. I'm not asking you to like MS, or to start using any of their products. Let's just be honest and realistic. Most people in the community aren't shy about placing the blame on them, but give credit where credit is due. We rightly object when people blame free software for not being a panacea, what with hardware incompatibilities and the lack of certain software. We should at least hold MS to the same standard and not judge them for failing to satisfy everyone.

Obscurity or nothing?

Eugenia at OSNews ran an editorial today regarding password storage in the popular Pidgin IM client (formerly known as Gaim). Her complaint was that Pidgin stores the user's passwords as plain text, which is obviously insecure. However, the developers strenuously object to her proposed solution: obfuscation.

Basically the situation is that Pidgen does not have an encryption scheme for IM account passwords. Some people have submitted patches, e.g. to use gnome-keyring, but the developers don't want to tie themselve to any particular keyring implementation. So, in the absence of any real security, some users have suggested adding fake security, such as ROT13 encoding the passwords. Their argument is essentially that such obfuscation is better than nothing. The Pidgin devs, on the other hand, argue that this does nothing but provide a false sense of security, which is actually worse than being insecure.

I think the Pidgin developers have a good point here. For one thing, the use-case for obfuscation seems to be a little shakey. The general idea is that obfuscation would keep your passwords safe from nontechnical users who would have local access to your machine, such as a parent or co-worker. Presumably they would be able to find the accounts file, but not figure out the obfuscated password. The problem with this is that tools and methods to "recover" IM passwords are all over the net. All you have to do is Google it. Obfuscation would only stop people who are too stupid to use a search engine and those who are too unmotivated to use one. And for those types of attackers, proper file permissions and locking your terminal when you get up from the desk would be sufficient anyway.

To me, this sounds like a "shut up" feature, i.e. the kind of feature a developer implements not because it is actually good or useful, but because the customer thinks it is good and useful. "Fine, I'll do it if it'll shut you up!" This doesn't add any real security and it's not clear that it would stop even non-technical users who actually want your password, but it would make users feel better. That's the kind of thing you do in the commercial world for a whiney customer. I don't think it has any place in the open-source world.

Mac and UNIX security

You often hear Mac and Linux people going on about how their operating system doesn't suffer from viruses and malware. They claim it's because their OS is inherently more secure. The Windows people then retort that the real reason is that hardly anybody uses MacOS or Linux, so the hackers just don't put much effort into it. A huge flamewar then ensues, in which very few of the participants actually know what they're talking about.

I read an InfoWorld blog on this very topic today. While I found it largely unremarkable, I did take issue with one passage.


The difference isn't market share, it's the foundation of the operating systems. Given that most virus authors and hackers are in it for the ego, don't you think that there would be a huge incentive to be the first one to write a widespread OS X, Linux, or FreeBSD virus?

There are two problems with this passage. First, there's the claim that "most virus authors and hackers are in it for the ego." That may have been true 10 years ago, but not anymore. These days, many hackers and malware writers are in it for the money. Some of them are even in bed with organized crime. It's not about learning how systems work anymore. Now it's big business.

In light of this, it's just absurd to dismiss the possibility that market share is not an issue. Just look at the numbers. On desktop PCs, Windows has well over 80% market share - probably more like 90%. So if you're trying to build a big botnet, what are you going to target? Windows is generally less secure by default, has more non-technical users, and if you get just 10% of them, that's more systems than if you got every Mac out there. With numbers like that, targeting anything other than Windows is just a waste of time.

Of course, the underlying operating system may have something to do with why Mac and Linux users have fewer security worries. However, it's certainly not the only reason. The default configuration of each system is another big reason - the out-of-the-box Windows configuration has historically been wide-open, while MacOS X and Linux are fairly secure by default. But if we're going to be honest, we can't ignore market share. It may or may not be the primary reason, but to claim it's not an issue is just wishful thinking.

On e-mail encryption

You know what pisses me off? Bad arguments. As a philosophy major, I read lots fo bad arguments. As a "philosophy hobbyist," I still do. And nothing makes me madder than those arguments that are so hideously wrong you don't even know where to begin explaining the problem.

I ran into one of those at work today.  Because of HIPAA and other such laws, we're looking into encryption products (laptop drives, database, e-mail, etc.), and I was stupid enough to volunteer for the assignment. Of course, it proably doesn't matter, because the whole effort is doomed from the start. There is absolutely zero buy-in from our IT staff on the idea of deploying encryption products. The only person who is even remotely pleased with the idea is the boss, and I'm the only one of the staff who isn't dead-set against it. The network administrator is particularly against the idea, and without his support, it just isn't going to happen.

Anyway, the particular comment that pissed me off was concerning anti-virus filtering in our mail system. Basically, one of our network people was concerned that we might get encrypted viruses, and because they're encrypted, the anti-virus filters wouldn't be able to catch them. As support, this person cited a virus report from earlier this week about a "new" virus that works by enclosing the executable in a password-protected ZIP archive with the password in the message body. This "encryption" stops the virus filter from catching it, but if we just blocked all encrypted files, we wouldn't have to worry about it.

Now, to me, this entire argument sounds like complete bull. Of course, I'm not an expert on e-mail, network security, or encryption, so I could be wrong. If that's the case, somebody please correct me.  But the more I think about it, the more I feel like this is one of those arguments that's just barely true enough that you can make it with a straight face, and yet still have it be completely misleading.

First, I certainly never suggested that we allow any old encrypted file through the mail filters. Just because a file is encrypted doesn't automatically make it trustworthy. An attacker could certainly find a freeware symetric encryption utility from FooBaz Questionable Software, LLC, use it to encrypt a virus, and send it to everyone in the world along with the decryption key and instructions on how to get the naked pictures of Pamela Anderson out of the encrypted file. That would just be a variation on the password-protected ZIP file trick.

My choice would be to use a standard public-key system, like PGP or GnuPG. If you stick to allowing just encrypted messages in that format, then the "virus problem" goes away.  After all, the whole point of public-key cryptosystems is that the recipient of the encrypted file already has the decryption key before the file is even encrypted. Hell, the recipient is the one who generates both of the keys. To send public-key encrypted mass-mail, you'd have to encrypt the malicious attachment separately for each recipient. And since many recipients won't have a key pair, or the attacker won't the recipient's public key, the target audience is dramatically cut at the outset.

Plus you can have accountability in public-key cryptosystems.  After all, that's what digital signatures are for - so you can know who sent a message. If you're really paranoid, you could only accept encrypted attachments from messages signed by someone you trust.

Of course, nothing about public-key cryptography can prevent a someone with your public key from intentionally sending you a virus. And that's where the "just true enough" part comes in. Yes, an encrypted virus sent by a malicious attacker trusted by user won't be detected by the mail filters. Is this a problem? Well, if you have to do business with people you can't trust, then I guess so. But if you don't publish your public keys and don't do business with 13 year old script-kiddies, I don't see it as a big concern.  Besides, this is negated by the other anti-encryption argument this person has been pushing: that the data we're dealing with isn't really important enough to bother with.

So let me get this straight: we can't do e-mail encryption because we're swapping unimportant data with untrustworthy people. My question is: then why are we even bothering? We ought to just lock the doors and start browsing the want ads!

Sigh.... I'm done blowing off steam now. Time to start working on my CV.