Changing over to two factor hardware authentication.

Over the past two years I have become very concerned about security.

First of all a disclaimer. I know just enough about security to be worried. I am not a security expert but I do understand enough to understand some Bruce Schneier articles which is probably enough to qualify me to play a security expert on TV.

I was one of the people whose Dropbox accounts was hacked and attempts were made on several of my Gmail accounts as well as my bank account immediately afterwards. Luckily I do not use even vaguely similar passwords on the different systems.
 
In addition, I am seeing a huge increase in attempts on my home system through the firewall. My personal development server at home is accessible only through the SSH port and that port has shown a 173% increase in attempts in the last year alone.
 
On that server are several hundred gigabytes of scans of various documents and photographs on the family document management system. Of course all of this is backed up to the cloud but I would rather deal with disaster prevention than disaster recovery.
 
At work I am dealing with how to manage a large number (on the close order of 100) of uername/password/SSH Key/PGP combinations for various servers (development, testing, and production) in a way that allows me 24/7 access in case of emergencies without compromising security.

When it comes to security I have become as nervous as one of our forebears on the African savanna hearing a rustle in the tall grasses. I know that it may just be the breeze and it may mean nothing, but our ancestorss have already demonstrated the value of panicking early and often. The ones that did lived to contribute to the gene pool. In this area, false positives are a survival feature.
 
As a result I have settled upon setting up two factor authentication based on something known (a password) and something possessed (a hardware key).

Any convenient hardware key alone will typically be subject to man in the middle attacks so to make that more difficult I was looking for something time-based like a RSA SecurId or something that generated a one-time password or OTP.

LastPass 

The first part of my solution is LastPass. LastPass is a online service that stores user names and passwords (along with other secure data pieces of data). The data is stored in their servers as a single encrypted block and that block of data is kept in sync as a block with your local system. In other words it is never encrypted or decrypted except on your local machine. Your passwords don't pass over the wire. They don't have the password, you do.  All encryption and decryption is done locally (usually via a browser plugin) or a mobile application.
 
This is allowed me to change over to using automatically generated passwords that are very large and impossible for me to remember. By using LastPass I have drastically decreased the cognitive burden of keeping track of passwords. Though, of course I still have to enter them into LastPass but the browser plug-in makes that very doable. In addition, I don't have access to them when the Internet  is down.  Of course, if it is, most of the systems I need to connect with are inaccessible anyway.

On the plus side it has mobile apps for both the Android and iPad, and the cost for the premium package that is $12 a year.
  
The key downside to this is that it puts a premium on protecting the single password for LastPass. And it is still only one factor authentication (i.e. you only need the password).

Enter the Yubikey. 

It is sold by Yubico  and is a hardware key that provides two factor authentication. It is significantly slimmer (2mm) than a standard USB thumb drive and acts as a USB keyboard. Is used by inserting the key into a USB port and then pressing a button on the key that causes it to generate a one-time password (OTP)  that can then be validated against the Yubico security servers.
 
The standard keys are $25.00 apiece and can be purchased in larger numbers such as 10 for $200 or 50 for $750.
 
There are more advanced keys that do cooler things. More about the various "coolnesses" in a moment.
 
LastPass has built-in support for Yubikeys and you can register up to 5 Yubikeys with your LastPass account. In That means that if for some reason you lose one of the keys, you can simply deregister it from your LastPass account and use your backup. In addition you can configure what types of systems require the Yubikey (mobile and desktop and so on) versus those that you don't want to use it on.

I am currently using a Yubikey on my android phone and all desktop systems, but not my venerable original iPad.
 
Using it is simple. I log into the LastPass count on my system using the browser plug-in (Available for Chrome, Firefox, Safari, and IE).

After the browser plug-in has validated my local password it then asks me to enter the Yubikey one-time password.
 

I put the key into the USB port and press a button. And I am now authenticated until my LastPass  authentication expires normally ( I have it set differently on different systems).

For using it with my Android phone I use the NEO NFC (Near Field Communication) feature to simply hold the key to the back of my phone and it automatically brings up LastPass and asks me for my password and logs me in.

I have purchased 2 NEOs and a standard key and after two weeks I am very happy with the result. The biggest con to all of this is building the habit of always carrying my hardware key with you. But that is a small price to pay to drastically decrease my exposure to security breaches.

More on the Yubikey coolness 

The Yubikey comes in several different forms: Standard, NEO, Nano, VIP

A quick summary of what they're good for is below:

• Standard - One-time password support and an additional "slot" for multiple configurations such as OATH. 
• NEO - Same as the Standard with the addition of NFC to allow authentication to those mobile devices that support it. Also has other cool features that I don't yet understand.
• Nano - Same as the Standard but ultra-tiny with additional support for the newer iPad camera docking station (This appears to be the only way to use the key with the iPad)
• VIP - Same as Standard with additional features that allow it to be used with Symantec VIP and PayPal.

As far as software support is concerned there are login authentication solutions for Windows and Linux (I have done nothing to test the Apple based OSes). In addition they provide an API for writing clients that connect their services.

As a special treat for me, they publish notes on how to use the Linux PAM (Pluggable authentication module) with SSH so that the hardware key is required in order to SSH into servers.

I'm going to be trying to set that up next week.

General usability

The LastPass browser plug-ins and integration with Yubikeys is very usable.

The only place where I have bumped up against usability is really in the documentation for the additional Yubikey integrations ( such as the Linux PAM and SSH integration).  They do seem intent on making it easy for third-party application support Yubikey authentication so I expect that will shift over time.

Next comes the real challenge: enrolling my wife and boys into using hardware keys.

More about my incredible love-hate relationship with Scala.

I just finished a phenomenal course with Coursera on functional programming in Scala.

I found it excellently done, and generally very clear.  This does not mean it was easy.  Bringing a beginner's mind to my entire world of programming highlighted just how completely saturated my mind has become with the object-oriented paradigm.

But the video lectures were well done if algorithmically dense. It required me to wrap my mind about recursion as a typically good thing (as opposed to Java of where it is often a bad thing).

Each set of video lectures came with a set of unit tests, and some partially filled out code examples that you then completed and automatically submitted and they were auto magically graded.

But the main thing I wanted to blog about was not the course (though I would recommend the course), but rather the toolset that was provided as a bundled package.  Rather than using these scala-IDE plug-in within an existing Eclipse environment, they package the entire thing as one download.  The end result was a far more stable environment than what I had blogged about earlier.  This does not mean that I am ecstatically happy with the toolset. It is far more stable than it was, and it still has some serious lapses.

In addition, I have noticed that there is a great deal of activity around the toolset and my hope is that this activity is an indicator that there will be drastic improvements in the overall coding experience.

More hints that will help with the ABCs of Scala

Add the ability to pull down source with the dependencies with SBT 

If you add the EclipseKeys.withSource := true to the build.sbt file.


name := "canon"

version := "1.0"

scalaVersion := "2.9.2"

EclipseKeys.withSource := true

resolvers += "Typesafe Repository" at "http://repo.typesafe.com/typesafe/releases/"

resolvers += "Spray Repository" at "http://repo.spray.cc/"

Scala-IDE will automatically attach source to the dependency which will allow you to debug the cryptic error messages more easily

ABC's of Scala

ABC. Assume nothing. Believe nobody. Check everything.

- John Cockram - British Crime Scene Manager

I would love to say that I spent the last 2 months learning Scala . Instead, I have to say that it has been 2 months of wrestling with

• Academic documentation unrelated to day-to-day development or learning.
• Documentation that is unconnected to the current implementation and not marked with what version it is connected to.
• Tools that are a decent alpha quality (and therefore better than the majority of the documentation).
• A language that is not just a moving target, but a dodging, weaving, actively evading target
• A large series of half completed build tools, testing tools, libraries and frameworks all driven by the NIH principle, many of whom reimplement the same concepts over and over and over and over.
• A separate ecosystem of artifact repositories

Some things I have discovered along the way that may help others 

(WARNING: much of this information will be outdated in the next 5 minutes)

The best book for learning Scala

So far the best book I've found for learning Scala is O'Reilly and Associates' Programming Scala by Wampler and Payne. Simple explanations and definitions of the concepts combined with code examples that are related to the concepts being described.

General assumptions to save you time

Some of these may sound tongue-in-cheek or harsh.. They are intended to be neither. I consider these rules to be just a straightforward and logical as saying "don't stick your hand into dark crevices" in areas where there are black widow spiders.

1. Assume that the documentation is outdated. , You should not proceed until you have proven that the documentation is connected to the version of the language or the library that you are using. 
2. Assumed that the source for examples or tutorials does not build until you have confirmed that it can be built in a standalone manner unrelated to the project you're working on.
3. Assume that the libraries in the Maven central repositories is out of date.
4. Assume that the transitive dependencies will NOT be filled out. 
• If the library you are using needs another library, you will probably need to specify it in the build.sbt file and you should not trust the documentation to tell you what version of that library is needed by the version of the code you are using. Instead, you should look at the dependencies listed in the source code of the library that you are using.
• For example, even though the Spray libraries say that they are built on top of Akka 2.0 you will probably not have those libraries automatically pulled in. You will have to go to the appropriate repository that they got pulled from and walks through their dependency information OR change logs, so that you can figure out what version of these other libraries are needed.
5. Assume that whatever library you have pulled down is a partially implemented experiment. Until you have proven that others are using it in projects that are actually ongoingly developed by someone other than the author of the original library you pulled down, you should assume that the entire library is a false trail designed to deceive. 
• So my recommendation is to test it always in isolation before

Specific assumptions to save you time

Scala-IDE

You can use the Scala IDE with either Indigo of Juno with the following caveats. 

I would recommend using only the SBT based builder with ONLY a build.sbt file. Do not use IVYDE in combination with the Scala IDE or ivy.xml files. , I would not recommend mixed Java and Scala
projects unless you an extreme masochist.

1. Assume that the Scala IDE error messages are unrelated to the code until 
• You have closed and then reopened the source file
• Refreshed the project
• Executed a "Build Project" command.
2. Assume that the Scala-IDE error messages are going to make no sense.
• If you are not able to find the error message in Google, you are better off rewriting the section of code than attempting to figure out what the error is.
3. Make sure that the library versions that you are pulling down match the version of Scala listed in the build.sbt EXCEPT that even though the latest version of Scala IDE pulls down and uses 2.9.3 of Scala the version of scala used by SBT is 2.9.2. So you can have the following build.SBT file:

name := "canon"

version := "1.0"

scalaVersion := "2.9.2"


But not


name := "canon"

version := "1.0"

scalaVersion := "2.9.3"

SBT

1. Do not use any of the SBT tutorials or documentation EXCEPT those found on the GitHub site for xsbt. All others are out of date and incorrect. 
• Double check that the version of the XSBT documentation you are looking at is tagged for the same release that you are using. 
2. When attempting to find libraries look first at the Typesafe and Spray repositories before attempting to use any of the maven central repositories. They are more up to date in general.

Why am I still at it?

The functional programming paradigm and the Scala language offer a huge opportunity in productivity.

Unfortunately, it is necessary to wade through a phenomenal amount of un-workability in order to get there.

Still experimenting like crazy

The next Big Thing?

For a while now I have been very frustrated by the gyrations necessary to try and represent a complex, dynamic hierarchical model of relationships among domain objects using Java. I love what Java brings to the table compared to C and C++ for the kind of work that I do AND it is still insufficient for what I would like to get done.


In effect, I am up against the limits of Java's expressive power when dealing with complex, dynamic relationships. I am spending a great deal of time writing code to make tracking these relationships doable. Recently, I realized that I am writing more code to manage the dynamic relationships and properties of the domain model than any other code in the application. I have started getting many levels deep in indirection in order to try and model some complex relationships. Normally, when I am struggling to express the model in the language I am using, I would try and figure out how to simplify the model. But since the PIM (Personal Information Manager) I am working on is an attempt to express exactly those complex dynamic relationships I would be sacrificing the whole reason for the PIM to exist.


One of the new people at my current company is a Scala enthusiast (rhymes with addict). As a result, I have been looking at this language with some intensity. This is especially true since it appears that the language maps well to modeling the more complex relationships. In other words, it offers the hope of a programming model/paradigm that could drastically simplify what I am trying to do.


Scala combines brevity of expression with numerous and powerful new coding and programming constructs, all built on top of the JVM.


That is the good news.


The bad news is a mixture of a rapidly evolving language combined with old and new documentation intermixed along with a new paradigm (functional programming) to learn and a lack of well behaved, mature tools that costs productivity and time.


I will be writing more about the pros and cons and techniques I am learning in the next few weeks.


The biggest caveat I can give you is that almost all of the IDE integrations for Scala that I have worked with have been rudimentary at best. You should be prepared for a sometimes.
Frustrating user experience when using an IDE with Scala. The productivity gain is still worth the pain and I can't pretend that there isn't some pain involved.


The Eclipse IDE is installed as usual and then you want to install the Scala IDE. You will want to pick the specific plug-in you install very carefully. There are 2 different versions of Scala involved (2.9.2 or 2.10). 2.9.2 is the current stable release of the language and 2.10 is the current bleeding edge. You cannot install both plug-ins in the same eclipse installation. To pick which needs to be installed, go to this website:


Download the latest nightly builds


This page references the nightly builds for the latest version of the Eclipse plug-in (code-named Helium). Believe it or not this is much more stable than the previous versions of the IDE plugin., and the Helium version of the plug-in is available in several combinations:

• Eclipse 3.7 (Indigo) with Scala 2.9.2
• Eclipse 3.7 (Indigo) with Scala 2.10
• Eclipse 4.2 (Juno) with Scala 2.9.2

You will notice that the download page actually lists 4 possible update channels some of which are so messily documented and/or named it's unclear what they're referring to, so I have only listed the 3 that I can be sure of. This is actually a pretty typical situation when dealing with Scala and its tooling.



In order to start learning. I would recommend 1st reading the following to get an overview of how it all relates to Java (This is an invaluable starting point if you are already a Java programmer).


http://www.codecommit.com/blog/scala/roundup-scala-for-java-refugees


Then I would recommend the following books as a starting point:


Programming Scala: Tackle multi-core complexity on the Java Virtual Machine


Programming in Scala , 2nd edition

The Principle of Least Surprise as a survival trait

It has been a while my last post.

I have been on a bit of a roller coaster at my workplace and home dealing with the fact that my productivity has been insufficient for all the things that I have taking on.

Thank the Gods for tools.

I will be writing about a number of new tools I've discovered and some tools that I have retired in the past few months but specifically wanted to talk about something very interesting I discovered in the last month that reinforces some old-fashioned developer wisdom.

One of my favorite principles that you will hear bandied about is the principle of least surprise (POLS). You can go to Wikipedia for the definition if you want (POLS) but I will summarize a key portion of it here:

"..when two elements of an interface conflict, or are ambiguous, the behaviour should be that which will least surprise the user; in particular a programmer should try to think of the behavior that will least surprise someone who uses the program, rather than that behavior that is natural from knowing the inner workings of the program..."

A week and a half ago I was involved in a training course that dealt with the latest findings of neuroscience/cognitive science with regards to the impact it has on people learning new things and shifting their behavior in organizations. It was actually much broader than that, but that was my focus when I went there. The course itself was very focused and pragmatic, rather than theoretical.

The fields of neurophysiology and cognitive science have had a lot of significant shifts in their accepted worldviews. A lot of what's happening in these fields is the natural result of our being able to directly monitor brain/nerve activity in ways we couldn't 10 years ago. It is probably

inevitable that as we started to be able to directly measure things there would be some surprises.

One set of typical discussions are to be found in "Cognitive Science". This volume contains a fascinating back-and-forth on the fundamentals of perception and cognition located in two different articles: "Situated action: a Neurophysiological response to Vera and Simon." By WJ Clancey. That's in Cognitive Science volume 17 pages 87 to 116, which is immediately followed by "Situated Action: A reply to William Clancey" by Vera and Simon. You typically won't be able to find something like this except in your nearest technical library (That's where I had to go). The set of articles highlight the difficulty involved in analyzing cognition when the only tool you have for direct observation is the process you are studying, itself. The attempt to tease out reality from observation is fascinating in of its own right. Not to mention the fact that in the articles both parties successfully avoided all of the usual subtle and vicious underhanded usage of verbal stilettos that so characterizes many scholarly exchanges. But I expect only a few Neuro/Bio geeks will be willing to make the effort to read them. Nor should you have to.

Rather than spending a lot of time giving you all the results of all of the research in a semi-scholarly manner I will instead give you a summary of the key point and direct you to some more popular presentations of the material.

One of the key points that has pushed to the fore (while confounding many cognitive scientists along the way) is that the brain for the most part is not processing in sequence. Our mental model for the most part has been: We perceive something and then either consciously or unconsciously choose an action. You will see terms in the literature like "reaction/action cycle" or "perception action cascade". The measured reality is counter to this. The brain for the most part appears to act as a high-speed parallel pattern matching computer constantly working to predict in the now what's going to happen next. Its operation is such that by the time you have received the perception (i.e. the perception has fully bloomed in your consciousness), you are already in motion. In effect action and perception arise concurrently with perception lagging behind action. You are already in action by the time you consciously perceive.

At one level it's very logical. In terms of survival humans are not very fast, not very strong, nor very aware. Predicting the future is a great tool for staying alive in those circumstances. Thus comes the old saw "We only learn from our mistakes." Learning from mistakes in a way that has you be in action to avoid them without being slowed down by conscious thought is clearly the way to go to avoid predators. It explains how boxers can block punches at a speed faster than they can consciously perceive. Your brain is taking the middleman of conscious thought out of the equation.

At another level it feels very illogical. Notice I say, "it feels". It really is an emotional reaction rather than a logical analysis of data. It especially appears counter to our own experience of our own experience. One of the downsides of trying to use cognition to analyze cognition.

Leaving aside all of the implications this has for living life (Just thinking about what this means for romantic relationships could get you into trouble), the implications for user interfaces are, to me, significant.

The principle of least surprise appears to be much more critical than we expect because we are dealing with an agent (the brain of the users) that is designed to be in motion before it has seen our nice pretty screens. It certainly means that usability testing becomes even more important because it is our only real on the ground way to evaluate the "survivability" of our user interfaces.

I am sure that I don't have a solid beginning of an understanding of the implications of this new way of looking at things. I am pretty sure that if we stop relating to our user interfaces as a work of art and craft and start relating to it the way the human brain is relating to it: another thing to

survive, we will have some breakthroughs in the way we design and test user interfaces. Of course, it does give rise to some great possible names for testing measurements and regimens like "Survivable User Quotient" and "User Interface Survivability Evaluation". We should be able to get some really great innuendo somehow. Maybe even a reality TV show "I survived your UI". We can even have SDD aka Survivability Driven Development.

I will just leave you with an example of a situation I deal with every day that illustrates this. I work with a development and training organization that measures everything they can to track the effectiveness of the courses. Everything from the percentage of people that complete the course to homework completion and so on. We have a website that allows us to track many of the statistics and the website is specifically designed with the intention that you pay attention when you put the statistics in. What this means that the user interface level is that for each set of statistics there are save and cancel buttons next to each row. The cancel button does what you would expect, it cancels the changes that have been input and returns you back to the previous state. The save button acts the way a "commit" button would for a revision control system, it commits the changes for the row in such a way that they cannot be altered without explicitly sending an e-mail to the person who manages the statistics and having her change them at the database level.

Being a developer who has learned from over 20 years of mistakes I save everything as I'm editing them. That skill is critical to my survival as a developer and has saved me a great deal of embarrassment (which will do for motivation until a real predator comes along). As a result I have routinely had to deal with sending e-mails to correct the statistics that I had partially

entered and saved along the way. It is been that way for three years for me and it will probably continue to be that way simply because my day-to-day tasks as a developer constantly reinforces the "survival" value of saving my work. If this was a user interface that I had a choice in working with I would automatically avoid it simply because it's usage goes counter to one of my good "survival" practices.

The Principle of Least Surprise, it's not just a good idea, it's survival.

Java now has Objects

As far as I'm concerned, Java has always been a "Nearly Object Oriented" language. When translating a model into real code you end up specifying the properties of the object and the methods with the business logic and translating that into fields, methods with the business logic, and methods to make it possible to relate fields like properties.

Eclipse makes much of this easier with various code generation plug-ins and features yet, despite that, I have wasted hours writing, correcting, and and maintaining infrastructure methods such as equals(), getters/setters, hashValue(), toString() .

All that has shifted with the addition of Lombok.

http://projectlombok.org/

Project Lombok uses Java 5 annotations in combination with byte code generation to allow compile time generation of all of the infrastructure methods to have fields become properties.

For example:

You can use the @Data annotation on a class to automatically generate the toString, hashCode, equals, and getters for all fields and setters for all nonfinal fields. It will also generate a free constructor to initialize your final fields.

Voila ! Instant domain object.

If you want you can break these things down in a more à la carte manner by using annotations such as:

@Getter / @Setter

@ToString

@EqualsAndHashCode

It also has some annotations I have not yet played with or evaluated:

@Cleanup - Automatic resource management: Call your close() methods safely with no hassle.

@Synchronized - synchronized done right: Don't expose your locks.

@SneakyThrows - To boldly throw checked exceptions where no one has thrown them before!

To use it on an Ant based compile you simply include it in your class path. To use an eclipse you need to run the installer and point it at the eclipse installation in question. It will modify the eclipse.ini file so that the runtime compile of Eclipse will automatically process the annotations.

To sum up:

PROS:

• Radically simplifies my life when dealing with business domain objects
• Byte code generation is nicely hidden and transparent.
• Simple to use for command line builds.

CONS:

• Eclipse install requires additional work and documentation if you are documenting your build environment for someone else.

UNKNOWNS:

• How well it plays with tools like AspectJ.