Monday, January 20, 2014

Apple App Store Rejects Web-Based Login Applications

I'm a big believer in federated logins- when smaller apps delegate logins to a well-known & trusted third party (like Twitter, Facebook, etc). This is partly because I'm strategically lazy (and a good auth system is not easy), but primarily because I believe the "yet another password" or "password hell" issues that users face are very real. Every time you ask a user to remember another account and password, there's a couple of common reactions:

  1. The user will simply walk away (most common)
  2. They will create an account, but they will reuse a password they've used elsewhere
  3. They will create an account and a unique password, but will have difficulty remembering it and will:
    • Write it down somewhere (!)
    • Use a ridiculously simple password
    • Forget it and depend on password recovery later on
Sure- there are the power users that have mnemonics or other patterns to create memorable and secure passwords, but that's exceedingly rare. So with that said, I tend to favor asking a user to use a login that they're already likely to remember. This relationship is even better when the big guys, like Google, already offer a battle-tested platform complete with great add-ons like 2-factor authentication.

So imagine my surprise to see that Apple is rejecting apps that use federated authentication!

Saturday, December 19, 2009

New MyPay Bookmarklet

MyPay Virtual Keyboard Remover v 2.0:
Works with Firefox, Safari, and Chrome. Drag it to your bookmarks or your toolbar. You need to establish a username and change your password through the virtual keyboard first. Once you have done that, use the bookmarklet to disable the virtual keyboard on subsequent logins.
Before:
After:

Wow, a New Standard for User Interaction

MyPay recently overhauled their interface and made it more "secure." I have my doubts, but they certainly have changed how they interact with the user.


I was a bit speechless. Pleading with users is new, but maybe it'll work for them. Apparently it'll be the only thing working for them:
Although most users have established their new login credentials with no trouble, some users are calling the Central Customer Support Unit for assistance. As a result, customer support is experiencing high call volume, and many customers are waiting on hold longer than usual.

We apologize for any inconvenience this may cause. We are doing everything possible to remedy this situation.
I have a few doubts that "most users" had no trouble. Maybe, just maybe, it's because of your continued use of the ridiculous virtual keyboard. Yes, you've increased the password complexity requirements (which actually increased security), but slaughtered what little usability you had. I promise you that getting rid of it will "remedy this situation."

MyPay, I think it's time that you get rid of the SSO or Admiral/General that once had a keylogger placed on his system and has perpetuated this paranoia. There is a risk/cost analysis that obviously has not been done and is probably costing the taxpayer millions in unnecessary support desk costs. Perhaps using the same standards that the rest of the DoD uses, the DISA STIG, could provide you with a more rational approach for implementing security. I'll even be happy to help you understand all of the super-secret requirements that are available on their website.

I'm just sayin'...

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).