Tuesday, November 10, 2009

myPay Simple Log In

To finish my rant started in my previous post, I've put together a simple proof of concept bookmarklet to remove the myPay virtual keyboard security facade. To use it, drag the below link to your bookmark bar (works on Firefox, Chrome, and Safari).
Go to https://mypay.dfas.mil and click the new bookmarklet. Your login dialog should remove the virtual keyboard and allow for a simple log in.
Just to be clear, this doesn't allow you to do anything that you couldn't already do- myPay allows you to do a simple login if your virtual keyboard login fails.

Monday, November 9, 2009

myFail Web Site

Logging into the DFAS myPay site is frustrating. This is the gateway where DoD employees can view and change their financial data and records.

In an attempt secure the interface (namely to prevent key loggers), they have implemented a javascript-based keyboard where the user must enter their PIN using their mouse (or using the keyboard pressing tab LOTS of times). A randomization function is used to change the position of the buttons, presumably to prevent a simple click-tracking virus from simply replaying the click sequence. Numbers always appear on the upper row and the letters will appear in a random position on the same row where they exist on the keyboard (e.g. QWERTY letters will always appear on the top row, just in a random order).
At first glance, I assumed that there would be some server-side state that identified the position of the buttons (as to not allow the user's browser to arbitrarily choose the positions). Looking at how the button layout is generated, however, makes it clear that the position is indeed generated by the client-side alone. Javascript functions are called to randomize the locations, and the locations of these buttons are included as part of the POST parameters upon authentication. A visOrder variable is included with a simple substitution cipher to identify button locations: 0 is represented by position 0, 1 by position 1, etc. Thus:
VisOrder =3601827594
Substitution =0123456789
Example PIN =325476
Encoded =102867
Thus any virus/program can easily mount an online guessing attack (since it defines the substitution pattern), and can quickly decipher the PIN if it has access to the POST parameters.
The web site's security implementation is painfully trivial, so we can conclude that the Javascript keyboard is only to prevent keyloggers. But it has a number of side effects, especially with respect to the security of the password. Given the tedious nature of PIN entry, users choose extremely simplistic passwords. MyPay actually encourages this as it does not enforce complexity requirements and limits the length of the password between 4 and 8 characters. There is no support for upper/lower case or special characters. 36 possible values over an 4-character search space is not terribly secure.
I think that myPay has allowed their paranoia about keyloggers to overtake reasonable design and security decisions about the rest of their system. A system infected with such a device or software has been critically compromised anyway, and will have access to at least system-level passwords and the SSN of the user logging into myPay (the SSN/LoginID field is not protected by the virtual keyboard function). It is an insight to the simplistic view of security that too many hold, and also has the unfortunate manifestation in a terribly unusable user interface.

Red Hat gets it right...

Couldn't say it better myself, so I'll simply call out their argument (citations removed):

It is, however, practically impossible to know with reasonable certainty whether a new software product could be said to infringe some prior software patent. Patents are conventionally referred to as intellectual property. However, as James Bessen and Michael Meurer have explained in detail, patents differ substantially from tangible property in that their boundaries are often fuzzy and unpredictable. If patents do not give clear notice of their limits, they create a risk of inadvertent infringement. Vague patents also enable opportunistic behavior. For example, a patentee may, based on vague language, claim ownership of a technology unknown to the inventor, but instead first conceived by someone else.
This problem of uncertain patent boundaries is particularly acute with software patents. Software is an abstract technology. Software algorithms can be represented in numerous different ways, and even computer scientists sometimes disagree over whether two software technologies are equivalent. Thus it is not surprising that software patents are typically framed in abstract language with uncertain boundaries. As a result, a software developer, when shown a software patent, often cannot be sure whether the patent reads on newly developed code.
This difficulty is multiplied hundreds or thousands of times with regard to a complex software product combining hundreds or thousands of discrete components. A separate but related problem faces all software developers—that of the impossibility of patent clearance, or determining whether there are existing patents that may be said to read on a new product. There is no reliable, economical method for searching the hundreds of thousands of existing software patents. The clearance problem is made even worse by the existence of tens of thousands of applications that for eighteen months after filing are unpublished.
Thus, simply by virtue of producing and marketing an innovative software product, a software developer assumes the risk of a costly patent infringement lawsuit. In the U.S., software patents are more than twice as likely to be the subject of a lawsuit than other patents and account for one quarter of all patent lawsuits. The cost of defending a patent lawsuit frequently amounts to several million dollars. Such lawsuits involve technical issues that are difficult for judges and juries to understand, and so even with a strong defense the outcome is usually far from certain. If there is a judgment of infringement, the penalty may be an injunction ending further production and enormous monetary damages. Defense costs and litigation risks are so large that in most cases defendants agree to some payment to settle such cases. Even when claims appear to have no valid basis, targets frequently agree to pay for licenses based on the mere threat of litigation.

Software Patents (Bilski v. Kappos)

I just learned about this case while listening to CNBC, but the implications to the entirety of the software world are huge. I should preface this post with the fact that I AM NOT A LAWYER and this is simply a statement of my opinion.

Bilski v. Kappos is a case currently before the Supreme Court of the United States (SCOTUS) regarding the patentability of an idea without a tangible implementation. Scotus wiki summarizes:
"In seeking a patent, Bilski and Warsaw told the Patent Office in 1997 that their idea was a highly useful one: using complex mathematical formulas, they could tell a business how to hedge against risk due to the rising and falling of prices of raw materials that were used to produce something — say, to generate electricity. Commodities prices often fluctuate quite widely, because of market forces or even changes in the weather, so these two inventors figured out ways to manage what they called “consumption risk.” It is, they claimed, of benefit both to businesses and to their customers."
This hedging strategy was rejected by the patent reviewer because it was not a concrete implementation of an idea, simply a concept. Courts have long held that mathematical axioms or algorithms are not patentable, as they are part of natural law. The most recent affirmation of this by the appeals court identified that an idea must be tied to a particular machine or apparatus or be involved in the transformation of an article to a different state to be patentable. This is now referred to as the "machine-or-transformation" test when considering patentability of an idea. The appeal before the Court aims to overturn this decision.
This has huge implications on the software industry as a whole. In an age where companies patent the most simplistic and abstract of ideas in hopes of future infringement, often the creation of new standards and technology is painfully inhibited by attempts to avoid such Intellectual Property (IP) traps. Companies rush to artificially build an IP war chest to hedge their inevitable infringement on others' IP. The number of trivial and otherwise trite patents that exist in this realm is simply staggering, and it is nearly impossible to develop without a devil-may-care attitude regarding infringement. It is a nightmare for any software development effort and for the engineers associated with them.
Similar, Donald E. Knuth, Professor Emeritus at Stanford University and one of the world’s most respected computer scientists, wrote in 1994, “When I think of the computer programs I require daily to get my own work done, I cannot help but realize that none of them would exist today if software patents had been prevalent in the 1960s and 1970s.” ... Dr. Knuth also stated, “I strongly believe that the recent trend to patenting algorithms is of benefit only to a very small number of attorneys and inventors, while it is seriously harmful to the vast majority of people who want to do useful things with computers.”
This quote, offered by the RedHat's amicus brief in support of affirming the decision, captures the essence of the problem. RedHat's argument is well-reasoned and is worth a read if you can ignore the painfully verbose, legalese nature of the document. Be sure to read the various arguments on the Scotus Wiki and keep track of the eventual decision from the Court. Also note who filed amicus briefs in support of the petitioner (i.e. Overturning the decision) vs. supporting the respondent (Affirming the decision).

Monday, November 2, 2009

Trouble with Windows 7/Internet Explorer and CAC?

Just a quick note about something I discovered- After upgrading my Windows XP virtual machine to Windows 7 x64 Professional, I was no longer able to access sites which required a DoD Common Access Card (CAC). Tinkering with Wireshark and Google Chrome finally appeared to reveal an answer: Windows 7 x64 (and possibly other versions, I don't know for sure) doesn't want to present a client certificate over anything but SSLv3.0.

So if you're having problems, be sure to go to Internet Options -> Advanced -> Security (Bottom of the list) and uncheck everything but SSLv3 as supported. That should reenable CAC authentication to DoD PKI websites.