You’ve probably seen it before. Your bank website pushing you to use 2FA. Or Facebook “recommending” that you turn it on. Or Twitter… or any of a number of other websites.

First off, what is it? It stands for “Two Factor Authentication”. It’s a means of adding some additional security to your account. It uses something else like texting you, emailing you, or an app on a phone or computer to help increase your security.

So, normally, when you log in, a website wants a username and a password. Well, most people are notoriously bad at passwords and if a password is memorable, it can be guessed and if it can’t be guessed it almost certainly isn’t memorable. This is a problem, and a problem that computer criminals like to exploit.

So let’s walk down how a criminal can attack your account. There are three basic forms of attacks: replay, reset, and infrastructure. Replay is about recording information and then replaying it to break in. Reset is about tricking the system into changing your password. Infrastructure is breaking into one or more machines and telling them to allow the bad guys in.

A replay attack can take several forms, including (but by no means limited to) password breaches and “sniffing” on public WiFi. The end result is the same: the attacker can get a username and password pair for your account. If you use that same username and password pair on multiple websites, then one being compromised means that you now are looking any that use that same username/password pair being compromised. 2FA stops this since the new login will require additional information that the criminals won’t have.

A reset attack is basically the same thing: an attacker using the password reset feature on a website to set the password to something of their own choosing. Using weak or easily looked up information about you (where did you go to school, what are your sibling’s names, etc.) as reset questions compound this problem. 2FA again stops this since the new login will require additional information that the criminals won’t necessarily have.

An infrastructure attack means that the attacker uses other means to break into the system. This can include exploiting bugs in the webserver, bribing someone on staff, to literally inserting bad hardware when the server is manufactured! 2FA won’t stop the break-in to *this* site, but it’ll keep the attack from effecting your accounts on other sites.

So what can you do? Here are some things you can do to help protect yourself:

  1. Don’t re-use passwords across websites. Use completely different passwords.
  2. Use a password manager. There are some good free ones, and several excellent for-pay ones. I use 1Password myself; some friends of mine use LastPass. Using the password manager means you won’t need to remember the passwords and it will have a generator to create unguessable passwords.
  3. Use a strong, unique password* for your password manager. DON’T put that password into anything else electronic. DO write it down and lock it in your safe and/or safety deposit box.
  4. Use 2FA whenever possible.
  5. Contact your cell phone carrier and see if you can password protect the porting (transfer to a different carrier) of your cell number.

* See https://xkcd.com/936/ for a technique to create better passwords that are actually far easier to remember. Still, you should be using a password manager to minimize the number of passwords you have to keep in your head.

The Talk

It’s time for the talk. Not that talk. The other one. The one about computers. Not the birds and the bees, but rather the bits and the bytes. It’s time to talk about computer security and what you can do to keep yourself safe.

The most important things to do are:

  • Install updates!
  • Have an anti-virus program installed.
  • Use a password manager.
  • Don’t give out your passwords no matter what.
  • Don’t click links in email.
  • If it looks or feels “funny” or “strange” or “wrong” don’t do it!

Continue reading

The seven most important questions for any project

After some reflection, I realized that there are seven questions that need to be asked before you start on any project. While you may ask yourself a subset of these questions, it is critical to answer (or at least think) about all of them before writing a line of code.

Each of these questions has a direct impact on how the project can be engineered and what tools and techniques you use to engineer it.

1) “Problem?”

That is, the need are you trying to fill. Are you trying to save people a few minutes when typing of a document? Are you making a user interface easier to use? Are you providing control software for life support on Mars? Are you trying to give a bored person something to do for ten minutes?

Starting with a solution statement is almost always a recipe for disaster. Find out what the problem is that needs fixing first before committing to a solution. I have found that by asking what the problem is that actually needs solving, you can radically reduce the complexity of the answer.

2) “Target audience?”

Who are you trying to solve the problem for? Are you trying to solve the problem for your coworkers? For ten million people? For a surgeon in the middle of surgery?

Who your target audience is helps to determine how much polish you need to put on the product. A solution that is acceptable for your coworkers is going to require a lot less work than something to be used by a surgeon. (Unless, of course, you work in a hospital!)

3) “Time to market?”

Simply put, how long you have before the solution needs to be in place. Today? A week? Six months?

The solution to a problem that needs to be solved today is inherently more limited than one that can be solved by next week or next year. Sometimes a problem can’t be solved in its original form in the time frame required. In that case, you need to reduce the scope of the problem or increase the time frame.

4) “Headcount?”

The more people working on a problem, the larger the scope that you can handle. More people also means more communication, more up-front design, and more time needed to handle changes down the line.

5) “Budget?”

Budget can refer to both money as well as (existing) equipment and tools. If you have adequate equipment, you may not need a monetary budget over what is currently allocated. Sometimes, having a monetary budget means you can buy a solution off the shelf and reduce your overall time and effort to solve.

6) “Licensing?”

This means how are you going to sell — or not — the final solution. If you are solving a need for existing customers, is it part of a patch to the existing version or is it to be released in the next major version? Are you giving it away? Are you going to be using a pay-per-use model?

A solution for one licensing model may not work for another. It’s important to be clear up front what you’re going to do so that you don’t end up wasting everyone’s time.

7) “Return On Investment?”

This is perhaps the most open-ended of all of these questions. In a nutshell, how much value will this project give to you and your target audience — is it something that will save some infrequent annoyance, or is it something that will transform lives? The more impact it will have translates directly into how much more you can invest before hitting the break even point.


RSS and OS X Mountain Lion

I made the jump yesterday, and discovered to my (unhappy) surprise about how Mountain Lion now handles RSS.

Or, more precisely, how it *doesn’t*. RSS is no longer supported in either Mail.app or in Safari.

After reading a bit, I decided to try out Reeder. Nice program, but it has an unfortunate (fatal) flaw: It doesn’t import RSS from Mail.app.

Since I happen to be good with the command line, I shortly came up with a method to extract the RSS feeds. This is a 90% in that the results that it prints have some encoding (such as & for an ampersand.) I’ll post later a 100% solution.

This solution may or may not work with Safari RSS feeds. I’ll post if I see a solution for Safari.

To extract your RSS feeds:

  1. Run Terminal.app (or any other command line terminal). Terminal.app can be found under your dock at: Applications -> Utilities -> Terminal.app
  2. Make sure a terminal window is open. In Terminal.app, the following menu option will open a new terminal window for you: Shell -> New Window -> Basic
  3. Copy and past the following into a terminal window:
find ~/Library/Mail/V2/RSS -name "*.plist" -print0 | xargs -0 grep -hA 1 RSSFeedURLString | grep "<string>" | sed -e 's/.<string>//' -e 's/<\/string>$//'

You’ll now have a list of RSS feeds. Enjoy!


Edited to fix accidental change in the command line.