Sick Of Acronyms

New MyPay Bookmarklet

2009-12-19T17:19:00.008-05:00

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

2009-12-19T09:21:00.003-05:00

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

myPay Simple Log In

2009-11-10T00:25:00.007-05:00

[Update: New Bookmarklet Available]

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

MyPay Simple

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.

myFail Web Site

2009-11-09T23:56:00.013-05:00

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

2009-11-09T15:41:00.003-05:00

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)

2009-11-09T14:58:00.008-05:00

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

Trouble with Windows 7/Internet Explorer and CAC?

2009-11-02T09:33:00.003-05:00

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.

Protocol Handling in Mobile OS's

2009-09-09T20:55:00.002-05:00

I'm rather interested in the possibility of writing an application for a popular mobile OS (i.e. Apple iPhone, Palm WebOS, Google Android) which can capture and handle links of a particular protocol within the web browser. This isn't that uncommon- this occurs every time you hit a custom protocol link, such as mailto:// or vnc:// which launch an email or VNC client, respectively. This is an important concept for inter-process communication, especially as the line between native application and web application become increasingly blurred (WebOS!).

iPhone: Interaction between applications and mobile Safari is possible, as demonstrated by Alocola. Applications register to handle links, and can also issue GET requests through the browser.

Android: It's possible to register an intent-handler within your application, though it it appears to only be relevant for non-webkit based interactions. For whatever reason, clicking custom protocol links fall flat.

WebOS: It doesn't appear to be possible. There's a resource file that maps internal applications to protocols, but it appears to be a reference and not modifiable.

The other thing I noted about WebOS was that while the javascript capability exists for novel application development, it is absolutely no replacement for a true application development framework. Why? There's no graphics abstraction API, persistent storage capability is extremely limited, and there's no networking except AJAX calls.

Lots of explanation...

2009-08-17T23:00:00.002-05:00

But no useful information. GPush FAQ:

Should I be concerned about providing my password to GPush?
When we created the app, we committed first and foremost to security. We are using multiple levels of encryption including SSL, obfuscation, and cipher-based encryption. SSL ensures that your credentials can be transported securely. Your login credentials are encrypted using an encryption scheme that has never been cryptographically broken, with a different 'secret key' for each user. To test these security measures, penetration tests were ran on the server with no information accessed.

So what's the problem with this explanation? Nearly everything- the use of SSL is the only really useful piece of information, since we know what ciphers GMail supports. On the other points:

Obfuscation: This could mean anything, even that they named sensitive files as grandmasGroceryList.txt to throw off hackers.
Encryption scheme never been broken: This, again, means nothing. It is some custom scheme that has never been analyzed? I don't want someone's ROT-13 encoder protecting my personal information.
Different secret key for each user: How are these keys generated and stored? How is this key repository stored to prevent unauthorized access? Is it done in such a way that this is this better (security) than having a single key for each user? Probably not. More than likely, it is just another level of indirection.
Penetration tests: Professional? Script kiddy? State-sponsored? Automated tools? What level of access was given, and what testing procedures were followed?

If we are expected to believe that the due diligence was performed in the creation of this utility (especially the server-side components), this information shouldn't be hard to provide. Identify the ciphers. Detail the encryption process and the defense measures put in place. Provide some context regarding the testing procedures.

Or don't provide that data at all. It may prove less troublesome in the end. Because with good encryption or not, allowing someone to have your credentials (impersonation) is potentially dangerous. You just have to weigh the benefits of the solution against the cost of having to change your GMail credentials and the relatively low possibility that someone gets access to your account.

iPhone Hate

2009-08-03T13:17:00.003-05:00

Let the pain begin.

http://www.fastcompany.com/blog/chris-dannen/techwatch/seven-more-reasons-ditch-your-iphone

The last two points are a bit weak, but it does call out that there are *much* better options at this point.

And yes, I have an iPhone. Hopefully not for much longer.

Compromised CA

2009-07-14T13:39:00.003-05:00

A lot of people don't realize how sensitive and delicate PKI is in practice- this is the technology behind much of internet security (e.g. SSL). Though we can theorize that it would take 100's of thousands of years to brute-force an security system, that's never the attack vector (or point of vulnerability) on such a system. This does actually happen; the German healthcare system suffered such a problem when it's CA (certificate authority) lost it's keys after a power outage. Now, they must start from scratch, reissuing over 80 million smart cards. While it may seem overzealous to reissue that many cards- after all, the CA key was lost, not stolen- it's important to realize that without the CA's key that is impossible to issue new Certificate Revocation Lists (CRLs), create new Registration Authorities (RAs), etc. The PKI system instantly become useless. You have to start over.

That's why my identity got stolen!

2009-05-04T10:05:00.002-05:00

Slashdot points at a recent research paper regarding an infiltration of the Torpig botnet. The sheer amount of data that the botnet collects from the infected nodes is staggering- Roughly 180 thousand infected nodes and enough financial information to steal up to $8.3 million. Running a secure system may not even be enough to protect you, unfortunately:

While 86% of the victims contributed only a single card number, others offered a few more. Of particular interest is the case of a single victim from whom 30 credit card numbers were extracted. Upon manual examination, we discovered that the victim was an agent for an at-home, distributed call center. It seems that the card numbers were those of customers of the company that the agent was working for, and they were being entered into the call center’s central database for order processing.

Check your SSH logs...

2009-04-20T12:22:00.003-05:00

Cause everyone's trying to get in. From my home router logs...

Apr 19 07:47:30 unknown authpriv.warn dropbear[6815]: login attempt for nonexistent user from 202.96.50.240:41238

Apr 19 07:47:31 unknown authpriv.info dropbear[6815]: exit before auth: Disconnect received

Apr 19 07:47:31 unknown authpriv.info dropbear[6816]: Child connection from 202.96.50.240:42789

Apr 19 07:47:35 unknown authpriv.info dropbear[6816]: exit before auth (user 'root', 1 fails): Disconnect received

Apr 19 07:47:35 unknown authpriv.info dropbear[6817]: Child connection from 202.96.50.240:44292

Apr 19 07:47:38 unknown authpriv.info dropbear[6817]: exit before auth (user 'root', 1 fails): Disconnect received

Apr 19 07:47:39 unknown authpriv.info dropbear[6818]: Child connection from 202.96.50.240:45872

Apr 19 07:47:42 unknown authpriv.warn dropbear[6818]: login attempt for nonexistent user from 202.96.50.240:45872

Apr 19 07:47:43 unknown authpriv.info dropbear[6818]: exit before auth: Disconnect received

Apr 19 07:47:44 unknown authpriv.info dropbear[6819]: Child connection from 202.96.50.240:47601

Apr 19 07:47:47 unknown authpriv.warn dropbear[6819]: login attempt for nonexistent user from 202.96.50.240:47601

Apr 19 07:47:48 unknown authpriv.info dropbear[6819]: exit before auth: Disconnect received

Apr 19 07:47:51 unknown authpriv.info dropbear[6820]: Child connection from 202.96.50.240:49411

Apr 19 07:47:54 unknown authpriv.warn dropbear[6820]: login attempt for nonexistent user from 202.96.50.240:49411

Apr 19 07:47:55 unknown authpriv.info dropbear[6820]: exit before auth: Disconnect received

And this goes on for about 10 minutes.

Yet another reason not to use ATM cards...

2009-04-15T07:04:00.007-05:00

As if you needed more reason not to use ATMs, now it's revealed even using a perfectly secure machine is still dangerous due to poor security practices on bank networks:

According to the payment-card industry, or PCI, standards for credit card transaction security, PIN numbers are supposed to be encrypted in transit, which should theoretically protect them if someone intercepts the data. The problem, however, is that a PIN must pass through multiple [Hardware Security Modules, HSMs] across multiple bank networks en route to the customer's bank. These HSMs are configured and managed differently, some by contractors not directly related to the bank. At every switching point, the PIN must be decrypted, then re-encrypted with the proper key for the next leg in its journey, which is itself encrypted under a master key that is generally stored in the module or in the module's application programming interface, or API.
"Essentially, the thief tricks the HSM into providing the encryption key," says Sartin. "This is possible due to poor configuration of the HSM or vulnerabilities created from having bloated functions on the device."
Sartin says HSMs need to be able to serve many types of customers in many countries where processing standards may be different from the U.S. As a result, the devices come with enabled functions that aren't needed and can be exploited by an intruder into working to defeat the device's security measures. Once a thief captures and decrypts one PIN block, it becomes trivial to decrypt others on a network.

To be fair, the article title is unnecessarily inflammatory since this doesn't involve cracking the actual PIN, but simply exploiting flaws in the design (no one is cracking crypto in this case). There is no legitimate cause for this type of problem nor a need to decrypt at various points in the network- it's kowtowing to backward compatibility concerns that is causing a problem like this.

Either way, though, it's time to think twice before putting my ATM card into the that sketchy gas station ATM. And use the credit card feature of your check-card if you have them. Refuting an ATM transaction is so much more difficult than a fraudulent credit card transaction.

TSP and Up(?)time

2009-04-10T05:54:00.000-05:00

Okay, the TSP site is something that is reminiscent of the late 90's with regard to site design, but it's something that has been sufficiently functional for my needs. Apparently, however, their UI isn't the only thing that is a relic:

Three days of downtime for "system maintenance?" What would the reaction be if a commercial financial site (e.g. Scottrade, BoA, etc) were down for three days?

Viscosity, OpenVPN and DNS Priority

2009-04-09T14:53:00.006-05:00

I wanted to change my DNS settings when connecting to an OpenVPN server using Viscosity. Using the resolv.conf and other methods didn't seem to have any effect, so I put together a solution that seems to work.

First, put these scutil commands into a file (we'll call it /usr/local/bin/changeDns.pref):

get State:/Network/Service/0/DNS
d.add ServerAddresses * 192.168.1.1 10.0.0.1
set State:/Network/Service/0/DNS

Notice that the ServerAddresses line has my DNS servers in order of priority. Change this to match your desired DNS resolution configuration. This settings will be automatically undone once the connection has been severed.

(Edit: The /Network/Service/0/DNS line is from my configuration, but it apparently varies between computers. You may need to run the scutil command list State:/Network/Service/[^/]+/DNS to find the name of your DNS service. Citation here.)

Now, we need to edit the /Applications/Viscosity.app/Contents/Resources/dnsupalt.py file (the script which is run when Viscosity connects). Put this after the nameservers and search_domains line:

#!/usr/bin/env python
# Viscosity DNS Support Script
# http://www.viscosityvpn.com
import os, re, sys

nameservers = []
search_domains = []

os.system("scutil < /usr/local/bin/changeDns.pref")

This tells scutil to run the file upon connection. Running scutil --dns after connecting shows that the DNS servers have been updated:

resolver #1
nameserver[0] : 192.168.1.1
nameserver[1] : 10.0.0.1
order : 200000

Disconnect and the system goes back to the DNS server offered by DHCP:

resolver #1
nameserver[0] : 10.0.0.1
order : 200000

Slingplayer for the iPhone

2009-04-02T23:22:00.002-05:00

Count me in as "disappointed." I was really looking forward to using my iPhone to access my Slingbox when the mobile application came out (and had even convinced myself that the $30 would be worth it), but that's not a concern anymore since Sling has decided that they're arbitrarily removing support for non-pro devices. I miss the days when companies encouraged upgrading by adding features, not by simply deprecating their previous product line.

Dumb move on their part, but it's at least one less thing to waste money on.

Using google talk as a logging mechanism

2009-04-01T22:11:00.003-05:00

So there's been an interesting side effect of using Jabber (specifically, Google Talk) to act an interface to the home automation system- logging. Google Talk allow for messages to be sent to offline contacts; these messages are saved and stored in the normal "Chat" dialog in the GMail interface. Since the automation system sends state notification to Google Talk, all of the messages are automatically archived in my account.

This is a nice little side effect. It provides a timestamp based on the browser's time zone and nearly ubiquitous access to the information. I also imagine that it'd be rather difficult to tamper with the timestamps. I now have a record of my garage door activity for the last several weeks (and indirect proof of my lack of a social life- I don't go out much apparently). My 9:30 Taco Bell run also will live in infamy.

House rules...

2009-03-03T08:19:00.003-05:00

rule "Close Garage Door"

when

event : TimeEvent()

garageDoor : GarageDoor(doorOpen == true)

jabber : JabberAlarm()

then

garageDoor.closeDoor();

log.info("Closed garage door by rule on " + new Date());

jabber.sendNotification("Closed garage door by rule on " + new Date());

end

It keeps me from letting all the riffraff in when I leave the door open at night. Thanks drools!

A conversation with my house

2009-03-03T08:13:00.003-05:00

It even cleans up after me. :) In case it's not clear, I'm the penguin. I'm just speaking in javascript.

eBay and Reputation

2009-02-25T10:19:00.003-05:00

Stories like this demonstrate how broken the eBay/Paypal system is. I've been trying to think of a practical solution to fully fix the business model to no avail. Escrow services seem to be the only way to be reasonably protected but that scales poorly, is costly, and is difficult for high-tech or esoteric transactions.

eBay is one of the first and most successful examples of a reputation-based identity system, yet is still remarkably flawed. Is it because people are naive to the concept of reputation, greed/ignorance leading them to carry out deals with people with no/poor feedback, or reputations simply not being relevant to peer-to-peer commerce? Such systems will never fully defend against someone willing to throw away their identity to score a quick buck, but the anecdotal evidence is everywhere and eBay's reputation as a scammer's haven is becoming solidified.

The above story doesn't detail buyer's feedback, but it is definitely relevant.

Facial Recognition and Biometrics

2009-02-18T06:46:00.003-05:00

Slashdot points to an article describing the "cracking" of facial recognition software used as an alternative login for some laptops. It may be a liberal use of the term "cracking," but it's yet another reason why biometrics should be used sparingly (if at all) and as a single factor in a multi-factor authentication system. It's just too easy to capture and reproduce human qualities that most biometric readers will believe. Try revoking those credentials.

Someone in the identity movement should contact Hollywood and tell them to knock off the sci-fi authentication schemes. I'm convinced that is where much of this biometric craze originates. Isn't painful to watch a show where biometrics provide the "strong" security (which actually offer trivial protection), and the next scene has a ciphertext or firewall being cracked in seconds? I'm talking to you, 24.

Face Detection and iPhone Video Streaming

2009-02-15T11:44:00.005-05:00

I recently purchased a Linksys WVC54GCA WiFi camera. It's a wonderful little camera, but my primary reason for purchasing it was to be able to stream video to my iPhone; it uses Motion JPEG which is the only video option available in Mobile Safari. It actually works very well, though my intention is to eventually attach it to my iRobot Create to give it "vision." More on that later.

Anyway, despite the camera's strengths, there are a few limitations. First, the camera can only support 4 simultaneous clients and the performance degrades linearly with each additional client (from my anecdotal experience). Second, the only access control the camera offers is HTTP Basic Authentication backed with a 4-user list configurable from its web interface that doesn't integrate well with any other application or security system. I figured that the best and most direct way of fixing the problems was to proxy the feed through my MacPro to manage the connection and user access there instead of on the camera.

As I was imagineering this system, I also got the bright idea to go ahead and do facial detection (not recognition -yet-) on the stream. After doing some research on the technology, I decided to use the OpenCV libraries developed by Intel and subsequently open sourced. My initial prototypes were extremely slow (1-2 FPS) since the Java libraries depended on JNI calls to a non-thread-safe C library. I did more research and found the Faint (Face Annotation Interface) library which did Haar in pure, multithread-able Java. (I had to take the beta code from the SVN since it wasn't released yet.) That finally got me a much more acceptable 10+ FPS.

Now I have the camera stream being cached within a custom-built Tomcat webapp that does the detection and also provides security for the stream. It can support much more than the 4 users available from the camera and without a FPS hit. It's pretty cool. Right now it just draws a red rectangle around the detected face, but obviously more triggers and actions are possible and desirable. It should definitely be noted that the stream (with facial detection) is viewable from the iPhone! Now- to just get the damned thing attached to my iRobot and my little mobile sentry will be complete. :)

dscacheutil -flushcache

2009-02-06T14:28:00.003-05:00

I've been needing to flush the DNS cache on my Mac a lot lately. (Possibly due to VPN hackery) Anyway, the nice little utility for OSX to flush the DNS cache (dscacheutil) is okay, but I'm pretty sure that it also flushes out any Safari cookies/sessions too. Isn't there a less destructive command for clearing the DNS cache?

The weakest link

2009-02-02T07:30:00.002-05:00

Sad but true. Probably could be have had countless other punchlines, like "let's have a hot-sounding girl call him up and ask him" or any other socially-engineered password harvesting technique.

Zoombak Dissection

2009-02-01T12:14:00.002-05:00

I've had a lot of fun with the Zoombak GPS device. Ever wonder what's inside one of those little guys? I did, but couldn't find any images on the internet to satisfy my curiosity. So I dissected mine.

It uses a 3.7V 890mAh battery, a Siemens 133851-V02 cellular chipset, and a Cirocomm 574B GPS module. As suspected, you can clearly see the holder for the T-Mobile SIM card (which I've already removed).

Weak vs. Strong Password (On a sticky)

2009-01-31T10:51:00.002-05:00

"Be sure to write down the insane password it generates for you (below), as a weak password would be far worse than a strong password jotted down on a sticky note next to your PC."

Is this the logic we use now when it comes to password management?

from : AppleInsider

Infocard Transaction (Becoming?) Possible on iPhone

2009-01-29T08:33:00.003-05:00

I think this is a big step forward for identity federation on the iPhone, mainly because it's the merging of two subjects I find rather interesting. I'm not a big Objective-C developer, but reading MobileOrchard's post on protocol handlers within the iPhone SDK gave my brain a kick-start this morning.

Imagine this: As described in previous posts, you encounter a page with an infocard:// link as the login button. That kicks off an iPhone InfoCard selector application, which retrieves the WS-Mex data from the RP page and then interacts with the chosen IDP using WS-Trust to retrieve a token. The retrieved token would ideally then be POSTed to the RP within Safari, but apparently Safari won't deliver app-formed POST data yet. So the last piece of the puzzle would be to either URL-encode the token (yuck), or do some kind of artifact retrieval (equally bad if not worse).

Monster.com Security Breach

2009-01-26T06:48:00.001-05:00

Absolutely disgusting. A company's (lack of) security allows a data breach, and they cavalierly dismiss it as a price of doing business.

As is the case with many companies that maintain large databases of information, Monster is the target of illegal attempts to access and extract information from its database.

Which should have actually said: "As is the case with many companies that maintain large databases of information, we failed to take the proper precautions to secure your information against unauthorized access and theft." It's even worse they they don't intend to email users about the breach. The solution they provided offers little comfort.

It is important to know the company continually monitors for any illicit use of information in our database, and so far, we have not detected the misuse of this information.

If the information has been accessed (and probably copied), how do they intend to detect/prevent the misuse of information? Maybe they should enter the DRM space if they've got the solution.

(from: http://help.monster.com/besafe/jobseeker/index.asp)

PPTP Tunnel and /sbin/route

2008-12-18T14:17:00.004-05:00

My SSH tunnel was acting flaky, so I decided to use the PPTP server feature on my DD-WRT router. It was extremely straightforward, though sending all traffic through the tunnel was a non-starter. To fix it, I had to route my "naughty" sites through the VPN and around the corporate network. My router at home is configured to use 192.168.1.0/24.

#!/bin/sh

/sbin/route -n add -net login.oscar.aol.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net talk.google.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net imap.gmail.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net smtp.gmail.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net facebook.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net ebay.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net me.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net mail.mac.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net gmail-imap.l.google.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net gmail-smtp.l.google.com $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net 205.188.0.0/16 $IPREMOTE >> /tmp/ppp.log 2>&1

/sbin/route -n add -net 64.12.0.0/16 $IPREMOTE >> /tmp/ppp.log 2>&1

This belongs in the /etc/ppp/ip-up config file which should be set as executable. The script is run upon successful connection to the VPN. The last two entries are required to route AIM traffic through the tunnel. The background of this config can be found here: http://www.easyzonecorp.net/network/view.php?ID=572

Apple transcends standards!

2008-10-20T08:57:00.003-05:00

Wow. If only it were that easy. "My software is completely standards compliant. No- not with accepted standards, but standards that don't even exist yet!" Marketing just killed interoperability.

iPhone Sprinkler Control?

2008-06-13T05:46:00.000-05:00

Why?! The pandemonium!

Yeah, it needs to be polished a bit, but it works!

Solving WAYF via Bookmarklets

2008-06-10T22:54:00.009-05:00

The power of bookmarklets is still to be seen in many situations. Consider the "Where Are You From?" (WAYF) problem, a common issue with federation technologies. The simple question of where to send the user to complete a federated authentication is one of the more complicated and error prone issues in identity federation. The key metrics for any WAYF solution are that the user should have the opportunity to choose any relevant identity context and the process should be hard for a RP to subvert.

-SAML 1 tokens can be retrieved from an IDP with a specially formed HTTP GET request and a TARGET parameter pointing back to the RP site, though a pre-existing relationship must exist in order to allow this to work since most of the request (attributes, authN) is implicit and expressed in the SAML metadata.

-SAML2 tokens can be retrieved from an IDP with a HTTP POST request which articulates the request parameters (attributes, authN), but still requires the RP to be explicitly aware of supported IDP(s). While there are some tricks in the specification regarding the use of domain cookies, the approach is not very dynamic and is still prone to spoofing and other problems.

-InfoCard solves the problem through the user's selection of a card. The card is indicative of the location of the target identity provider. This is the best approach thus far, though it lacks ubiquity at the moment.

-OpenID addresses the problem by the user being prompted to input their OpenID url. This is the most straightforward approach, as the user is compelled to identify the IDP explicitly (or at least a pointer). Aside from a steeper learning curve, this approach suffers from spoofability assuming a malicious RP (as does SAML).

While all address the problem with varying levels of success, I believe that the bookmarklet approach maintains the benefits of wide interoperability while reducing spoofability of the IDP's interface. The provisioning process would work like so:

The user logs into the IDP for the first time.
The IDP validates user's credentials, offers bookmarklet which can be stored in the user's browser. The bookmarklet has sufficient logic to parse the protocol specific parameters from the RP site required to issue a token.
The user accesses an RP site and navigates to the login page.
The user clicks the IDP's bookmarklet. The bookmarklet's Javascript parses the RP's information and redirects the browser to the IDP's site with the RP's parameters encoded into the URL.

This approach works with all modern browsers. (except IE7, though IE8 works!) It preserves the user centricity of the interaction because the user has to choose an identity bookmarklet to log in, and it reduces spoofability since we are not depending on the RP to preform the redirection. This profile is sufficiently abstract enough that it could be used to improve existing SAML enterprises and could easily be integrated to OpenID.

The bookmarklet code itself is extremely simple. If we use Infocard as our example, we can easily search for the embedded object type of "applicationx/infocard," gather the required/optional claims, and redirect the user's browser to the IDP's site. Assuming the browser supports the "infocard://" protocol:

var idp="infocard://";

var objects = document.getElementsByTagName("object");

var infocardObject;

for(var i = 0; i < objects.length && infocardObject == null; i++){

if(objects[i].type == "application/x-informationCard")

infocardObject = objects[i];

}

if(infocardObject == null){

alert("It appears there is no InfoCard login on this page.");

}else{

var parentElement = infocardObject;

while(parentElement != null && !parentElement.action)

parentElement = parentElement.parentNode;

var target = parentElement == null ? window.location.pathname: parentElement.action;

var requiredClaims=(document.getElementsByName("requiredClaims")[0].value).replace(/\s+/g,'%20');

document.location.href=idp+"requiredClaims="+requiredClaims+"&paramName="+infocardObject.name+"&respondToUrl="+target;

}

If the browser isn't cooperative, then we can replace the idp variable with the hard-coded URL for the IDP, though the user is then forced to have multiple bookmarklets.

Apple Java Bug Report

2008-06-04T15:12:00.001-05:00

Problem ID: 5903500

* SUMMARY

Java Web Start applications are not receiving file arguments for their associated file types. When an JWS application is installed to the desktop with mime-type and extension associations, the JWS Client correctly invokes the application when attempting to open a related file; it fails, however, to include the file path as a parameter to the JWS application.

* STEPS TO REPRODUCE

1. Install a JWS application to the desktop with a file association in the JNLP file (ex. .xyz).

2. Double-click a .xyz file in Finder.

* RESULTS

Application launches without any command-line parameters. Expect the subject file to be included as application main() arguments "-open /path/to/file".

Web-Based Lightweight Card Selector [note]

2008-05-31T18:36:00.003-05:00

I should note that the web-based card selector can work with existing IDP's (since we're doing WS-Trust, after all) and with current RP's with Infocard web form/object login with a specially created bookmarklet. This approach opens the door to even current browsers which do not support HTML5. But more on this later.

Web-Based Lightweight Card Selector

2008-05-31T17:08:00.008-05:00

Something we've been working on is the ability to create a web-based card selector which will work in situations where a full card selector is not available or appropriate. Since selectors are not yet ubiquitous and inappropriate in many tactical situations, we are working on using a HTML5 based approach to enable an Infocard/CardSpace-based enterprise to work with standard web browsers.

The major changes in HTML5 which allow for this to occur are offline caching (HTML Manifest), the navigator.registerProtocolHandler action, and the DOM/Session storage capabilities. For more information, see Mark Finkle's excellent blog on Firefox 3's offline features and the WHATWG HTML5 Draft Specification for the rest. With these capabilities to be included in future web browsers, we can now assume that the client browser:

Can cache URL resources and seamlessly serve them when connectivity to the IDP cannot be established
Can route particular protocol requests from arbitrary RP's to a registered IDP web app
Can (persistently) store a user's preferences and settings locally, where information regarding trust and disclosures can be held.

With these capabilities, one can begin to see how a web app could operate as a client card selector:

The user accesses an IDP provisioning site, where the card selector resources (HTML, Javascripts, etc) can be retrieved for later use and registered to handle a target protocol such as "infocard://" (perhaps even "openid://"?). At this point, all required Card metadata would be retrieved and stored.
After provisioning occurs, the user access an RP with a login link which specifies the target protocol and any parameters needed for login, e.g. infocard://respondToUrl=[rpurl]&requiredClaims=[claims]&optionalClaims=[claims]
The browser prompts the user to select a registered webapp to handle the invocation, which roughly parallels card selection. Upon selection of the IDP offline app registered in step 1, the browser redirects the user to the cached application. (Note that per the WHATWG draft specification, no information necessarily goes back to the IDP at this point)
The cached web app parses the URL encoded information provided in step two and previews the requested claims to the user. This is analogous to the pre-retrieval step of the Infocard ceremony. The user may select/deselect optional attributes or cancel the transaction at this point.
If the user chooses to continue, the cached Javascript preforms a AJAX WS-Trust RST to the IDP's endpoint specified during provisioning.
The IDP responds with an RSTR which the cached Javascript parses, displaying the display token to the user (for verification) and the security token into an embedded form with the RP's respondToUrl as the action.
After review, the user chooses to submit the token, which is posted to the RP site in the same fashion as current card selectors (HTTP POST with a xmlToken value).

This approach seemingly solves the problem of a lack of card selectors and lightweight clients assuming that all major browser implement HTML5 (which appears to be the case). The above approach actually works as demonstrated by our proof of concept which uses only Firefox 3 or any browser with Google Gears.

The registerProtocolHandler (and possibly even the MIME handler) seem to have a number of possibilities within the federated identity communities. As demonstrated above with the Infocard scenario, this can address the vexing "Where are you from?" problem which plagues web-based federated identity solutions including OpenID. Omitting the RP from the redirection phase via the web app selector and a carefully crafted offline web app should do wonders to reduce spoofability and increase usability.

While this is a big step to lightweight identity selectors, it does lack a number of the nice features available in a full card selector:

Cannot provide "clues" regarding the applicability of registered web apps (such as disabling cards/webapps which are inappropriate for the required claims)
Cannot easily integrate with the OS for things such as public/private key creation, thus this is clearly aimed toward managed card with browser-friendly authentication.
Encryption in Javascript is hard. XMLEnc with the RP's certificate isn't possible with this approach, so we have to depend upon Audit mode or unencrypted tokens over HTTPS.

Below is a simple web-based card selector provisioning data flow, though I forgot to put in the card metadata exchange in step 4.

The offline cache is much more useful than just for the protection of the user privacy; once offline tokens within Infocard become possible, this approach should still be very viable. I have a screencast of our demo and I'll update this post when I get around to uploading it to YouTube.

IPhone Garage Door Opener

2008-05-29T18:50:00.004-05:00

In a past life I wrote automation controllers for large facilities. Now, I'm obsessed with needlessly automating my house (since it's my first). Thus, I present to you, my latest in ridiculously over-engineered automations:

The iPhone Garage Door Opener

Why? Cause it's cool to be able to press a button on my phone and have my garage door open. That, and, I have a horrible habit of leaving my garage door open all night for anyone to access, and now I can create a script to remotely close the door at a given time.

The stuff I bought consists of an NPort 16 port serial server (5610, if I remember) and an National Control Devices ProXR 4 Relay, 8 Input serial controller. To sense state, I included a garage door contact sensor with input into the ProXR.

On my MacPro, I have Tomcat running with a servlet which responds to the AJAX calls from my little iPhone-customized JSP page. The UI updates every 5 seconds, updating the door state and the current temperature in the garage (since a temperature sensor comes on the ProXR). So now I can use my iPhone to control my garage (which is almost useful)!

OMG INTERNET VOTE

2007-11-21T15:35:00.000-05:00

13949712720901ForOSX

There. I did it. Now please make it happen, Apple.

Lots of progress, little updating

2007-11-21T15:14:00.000-05:00

A lot has happened since the last time I've posted:

I've got SAML 1.1 working with LifeRay Portal. This was for a demo, but the code could be used in production (IMO). It works in the same way that the existing CAS filter works, except that there's a lot more code responsible for validating SAML.

Been poking around with the OpenSSO Federation Libraries. I'm trying to find a SAML 2 implementation that I can use (quickly), and the OpenFedLib libraries seem a bit more intuitive than the upcoming OpenSAML2 implementation. (Probably because I haven't taken the time to figure out their XMLTooling) I've got SAML2 tokens shoved into the InfoCard IDP, too bad there are exactly 0 RPs that'll support it. :)

I'm really excited about the Claims-based architecture stuff that Kim's been talking about. We're been looking at such an approach for assertion translation/normalization. More on this later.

Why can't the DoD learn from others' mistakes?

2007-08-20T23:02:00.000-05:00

Joint Enterprise Directory Service (JEDS)

Although there has been failure after failure when attempting global aggregation of information (for countless reasons), why is it that we're spending more money going down this dead-end trail? Has the case for federation not been made yet? The litany of technical and security concerns which go painfully unanswered is saddening.

HSPD-12 and Privacy

2007-06-19T21:46:00.000-05:00

Stefan offers some interesting points regarding the debated anonymous credentials, a term which Kim as sworn off:

Whenever you read about “anonymous credentials”, you should really think of these as minimal disclosure certificates. “Minimal disclosure” implies three privacy properties: (1) minimization of traceability, (2) minimization of linkability, and (3) selective disclosure:
Minimization of traceability means that there is nothing in a certificate beyond any disclosed attribute data it may contain that can be used to link its presentation to its issuance.
Minimization of linkabilility means that there is nothing in a certificate beyond any disclosed attribute data it may contain that can be used to link its presentation to the presentation of other certificates of the same user.
Selective disclosure means that the user of a certificate, when presenting the certificate, can (unconditionally) hide attribute data contained in the certificate that does not need to be revealed. More generally, properties of encoded attribute values can be disclosed while any other information remains hidden.

These properties hold in the face of collusions between relying parties and identity providers. What’s more, they hold unconditionally, even if relying parties and identity providers actively collude from the outset and try to build in “cryptographic backdoors” in the algorithms used to digitally sign identity claims.

This has interesting implications with HSPD-12, the requirement for all Government activities to use strong authentication for networked systems. This has been implemented by issuing smart cards with an embedded PKI certificate to government employees (and contractors) and requiring the use mutual SSL pretty much everywhere. So rationale behind the client PKI certificates aside, we can say that linkability and traceability are foregone conclusions in these environments. There is, however, a battle to be had regarding discretionary user information release.

Identity federation in such situations are less of an issue of federated authentication, but more focused upon the federation of attributes to enable authZ decisions.

Cardspace Quirks

2007-06-19T19:04:00.000-05:00

I'm glad to see that I'm not the only one out there battling various Cardspace bugs and quirks. I'm shocked that I hadn't see her blog earlier.

As the shepherd of the Pamelaware module, maybe she can focus a bit of effort in quashing the bugs in that code which were inherited from Kim's implementation.

Privacy and Need-to-know

2007-06-19T14:56:00.000-05:00

It's rather frustrating to see how many people dismiss the concept of discretionary information release as an issue which only the tin-foil-hat and "naughty" communities are concerned. Perhaps I have too narrow a view since I tend to look at things from an enterprise/government point of view, but we're not just dealing with the commercial space, are we?

I spend a great deal of my day (everyday) trying to explain the need for such concepts within the DoD. An intrinsically hierarchical group where every agency assumes they may have carte blanche access to peer and subordinate agencies, there is little true federation. To share data, it normally requires one organization or another to surrender control over their information, leading to power struggles of epic proportions.

When you finally get them to sit down at the table, the concept of cooperative data exchange (rather than the forced or ransacked types) are usually foreign concepts. If not, they are typically jaded because of similar over-promises in the past which ultimately led to the above situation. Eyes cut at one another suspiciously. When they finally acquiesce (due to political or financial pressure) they instinctively demand to release as little data as possible. A desire to know and retain oversight over the data is being "surrendered" about their users when they use external resources, and to have a clear audit/accountability trail for external users who access their resource is quite common.

Note that exact same things are usually demanded when most people talk about privacy, except the here we call it "need-to-know". Need-to-know used to simply apply to release of well-defined and labeled information; within the enterprise, however, this concept has reached a new level. All information is regarded as sensitive until deemed otherwise. Sometimes it's because they have legitimate security concerns, other times it just because of stubbornness.

So the issue that the Government (with a capital "G" this time) is often cited for shortfalls, cross-organization information sharing, is unfortunately tied to this problem in my opinion.

Firstrade Privacy Shenanigans

2007-06-17T21:03:00.000-05:00

I've been with Firstrade for some time now, allowing me to invest what little extra money I occasionally find. When initially establishing the account, I faxed my life away to them (voided check, form filled with personal information, etc). I've expressed my frustration with the number of paper documents they use, littered with personal information, so I was happy when they offered an online version of the information. My shredder finally got a reprieve.

Recently, however, I changed the institution with which I bank and attempted to notify Firstrade of the same. As directed on their website, I sent the updated forms via fax to them. A day later I received a notice via email stating that I needed to take the forms, a voided check, and two forms of ID and mail the information to them. Having lost a passport in the mail recently, I was not happy with the idea of putting every piece of personal and financial information into one envelope handled by the USPS.

So I inquired as to the rationale behind this demand. After all, my experience with a passport would support an argument that fax is more secure than postal mail. If their concern was regarding the reputability of facsimile documents, I believe that there is ample legal precedent to prove that such requirements are unnecessary. This was the response:

Thank you for emailing Firstrade. Please note that currently Firstrade requires that amended ACH setup requires you to send in the actual form with the voided check. This is a risk management issue that we are working out with ADP Clearing. We apologize for any inconvenience.

"Risk management". Why did that sound familiar? I deal quite a bit with management throwing the term around, so I know how it can be abused. Does the term actual have any valuable meaning in the above statement? It did not to me. It appeared as if they wanted to throw in a obtuse term which will intimidate the average customer to simply accept the assertion. I'm a bit more stubborn than that, unfortunately.

The only conclusion I could draw was that, due to some dispute between them and ADP, they are placing the burden of the "risk" upon the customer. I wasn't too happy with that:

I don't believe I fully understand:

To cover your "risk-management" concerns, you're putting my personal information at risk by forcing me to send it through the mail? I'm going to put ID cards, a check, and account information into one envelope handled by the USPS? Your risk management is, then, to shift all of the risk onto your customers?

Not going to happen.

Not that I expected to get a concession in response to the email, but I was hoping for at least a more coherent explanation of the "risk" they were trying to manage. Instead, I got an equally cavalier and patronizing email in response:

We are writing in response to your inquiry regarding the ACH profile amendment for your account ***. Kindly note that we are unable to process the amendment at this time, due to the fact that the required documents are not yet received. We understand your concerns about your privacy; however, risk management measures are necessary.

Damn. And I thought that the only place I had to worry about wanton abuse of security terms was while at work.

Interop (OpenSaml and PHP Infocard)

2007-06-15T18:56:00.001-05:00

What I've had to do so far to get the PHP RP to accept an OpenSAML-created assertion:

1) Force namespace prefixes for all SAML elements. The default xmlns values are eventually processed by the PHP code, though are pushed to the end of the element (breaking c14n)
2) Turn off the inclusive namespace prefix directives
3) Disable all unused namespace declarations. Saml, Samlp, xsd, xsi, and a few others are declared within OpenSAML objects (presumably for flexibility)
4) Change the xmlsec encoding of the certificate, which pretty-prints the base64 certificate with various unneeded (but not egregious) whitespace
5) ... Eh, I started blogging too late to catch everything. 1-4 are the major changes.

It finally works though. These are all bugs with the PHP code so far as I can tell. Why change the IDP code then? Because it's pretty clear from the few RPs out there that Kim's code has made an impact and is used in many projects. The RP accepts some SAML, and ultimately interoperability comes first.

Hopefully he'll take it under advisement for the next revision.

OpenSAML and Infocard

2007-06-15T18:36:00.000-05:00

OpenSAML (to include Apache Xmlsec) and the PHP RP seem to disagree about what to do with unused namespaces during canonicalization. Xmlsec strips out the namespace declaration, whereas the PHP keeps it in. Looking at the spec, I'm going to side with Xmlsec.

Raw XML:

<attribute xsd="http://www.w3.org/2001/XMLSchema" xsi="http://www.w3.org/2001/XMLSchema-instance" attributename="surname" attributenamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><attributevalue>MyLastName</attributevalue></attribute>

XmlSec:

<Attribute AttributeName="surname" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><AttributeValue>MyLastName</AttributeValue></Attribute>

PHP:

<Attribute xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" AttributeName="surname" AttributeNamespace="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname"><AttributeValue>MyLastName</AttributeValue></Attribute>

Long time, no post...

2007-06-15T17:58:00.001-05:00

Just throwing out notes before I forget.

Kim's PHP Infocard implementation appears to have a problem with its canonicalization routine. To demonstrate, let's look at this example assertion element:

<assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion" assertionid="uuid-1B045A32-5024-B4EB-93AE-0D718C87BC0D" issueinstant="2007-06-15T22:35:05.993Z" issuer="https://xxx" majorversion="1" minorversion="1">...

Which, in this case, ends up being the spec compliant. The PHP code incorrectly forms:

<assertion assertionid="uuid-1B045A32-5024-B4EB-93AE-0D718C87BC0D" issueinstant="2007-06-15T22:35:05.993Z" issuer="https://xxx" majorversion="1" minorversion="1" xmlns="urn:oasis:names:tc:SAML:1.0:assertion">

This places the namespace after the attributes, which violates the spec. There are a couple of other little quirks I'm hitting which I'll post as I find them.

OpenID and Unique IDs

2007-02-21T00:49:00.000-05:00

George Fletcher, a really smart AOL guy, mentions in his latest entry:

One final thought. There should be no reason why my IdP can't provide public personal identifiers in certain instances, pseudonymous identifiers in others, and temporary identifiers with claims in still others.

I would agree that in the generic sense of an Identity Provider (IdP) that such an assertion holds. In some implementations, especially in OpenID's case, this obviously isn't true. This breaks when you depend on the user to serve a unique identifier directly to the verifying resource/service provider. Not to say that this couldn't be fixed in practice, mind you.

The discussion regarding reputation in his post is a valid one. I just happen to believe that it's more of a convenient "feature" that you can't turn off. There are a lot of situations where this is bad.

AOL's (Really)OpenID

2007-02-21T00:28:00.000-05:00

Can someone please explain to me how this is going to foil a spammer's script?

Perhaps I'm just confused. I realize that it's just supposed to be a beta implementation, but it's going to be hard to sell OpenID even as a blog-spam panacea with these kinds of problems.

Also, could we offer some OpenID-relevant security tips instead of the mind-numbing password length/composition suggestions? How about verifying the use of https, an aol.com address, appropriate use, etc. This issue may lead into discussions regarding the level of exposure that the user has to the OpenID experience. How aware should the user be of the underlying technology? Some have suggested that such exposure be minimized; I would suggest the contrary in this case.

Digg and OpenID

2007-02-20T23:47:00.000-05:00

Well, I knew it would eventually happen- a popular OpenID Digg article. I was curious, however, the form it would take. And now that Digg has thrown its support behind the initiative, the Web 2.0 community has taken notice. Here's the article I found:

Here are 5 reasons why I think OpenID Rocks:

1) 1 ring to rule them all - why wouldn’t you want the ability to have 1 sign-in across all blogs?

2) Bye-bye comment spam.

3) Verify who is actually making comments. Many fake Matt Cutts’, Jason Calacanis’ make comments and require verifying IPs or other time-consuming checks when prolific people do comment.

4) MyOpenID’s (inaptly-named) affiliate system is a nice tool for developers and large site owners.

5) De-centralized authentication leaves no single player holding all the cards.

Here are 6 reasons why OpenID sucks

1) It is (as yet) too complicated for average website owner to implement.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Now, there's a variety of misconceptions as well as informed points in this piece, but it represents the common perception of OpenID by a relatively "enlightened" Digg user. Similarly, the Digg comments always make for great reading. Here, a response to the above:

I'm getting sick of this FUD over OpenID. It has THE SAME "TRUST" AS EMAIL BASED AUTHENTICATION. The only differences are:

1. You can change your provider at any time but keep your same openID (a plus)
2. They can't send you anything (another plus).

YOU manage your authentication. They don't need to send you password resets etc. They don't have an email address to sell to a thrid party, or to spam you with their product "newsletters". OpenID is BETTER than email based account management.

The only true con is that you REQUIRE a website (1 page) to use one.

1) It is (as yet) too complicated for average website owner to implement.

Uh.. you paste a line of html into your index page.

2) The security implications of this type of cross-site authentication haven’t been fully explored.

It's as secure as email as a login mechanism. If your webserver is compromised you lose. If you email server is compromised you lose. How is this any different?

3) OpenID doesn’t necessarily provide trust. Theres nothing stopping a fake Mark Cuban from creating a fake OpenID, or worse, a fake identity provider. This is the chink in the armor of the decentralized system.

Yes there is. You don't link to the fake Mark Cuban's provider in your page. It's as simple as that. What's to stop someone from making a fake email address claiming to be you?

4) Too confusing to users. “OK I want an OpenID. Wait..what is myopenid? Is that different from GetOpenID? Do I need to get an OpenID on all of them?”

This is called RTFM. Put "openid" into any search engine and there's your answer. If someone knows enough about OpenID to want one, they will be able to find out how to get one.

5) Hackish implementations. For example, the wordpress plugin actually creates a local wordpress users behind the scenes. In my opinion, this is an unacceptable hack.

This has nothing to do with OpenID as a standard. Just the quality of the particular plugin you're looking at.

6) Lack of implicit strong authentication. An OpenID login is really only as strong as the identity providers authentication. OpenID probably should never, and will never, be used for financial logons for this reason. The flip-side is that if an IDP provides strong auth, then the OpenID is as secure as that link in the chain.

Your "security" on financial sites is only as secure as the email address you associate with it. Your online banking security is only as secure as your email account.

Just as with email, you can be your own provider. There is no requirement to EVER trust a third party.

The ONLY WAY to compromise an OpenID account is to either compromise the webserver hosting the link to the provider, or to compromise the provider. If your email server gets compromised its the SAME RESULT.

While I'm not going to sit here and detail the problems with both posts, it does represent the understanding and perception problem that OpenID currently has. I believe it only goes to further my assertion that OpenID is still not ready for the limelight. Digg's adoption of the standard is certainly a boon for the OpenID community, but it may lead to a new group of users which is blindly passionate about technology they do not fully understand. (See above)

I'm not posting this to disparage the Digg nor the OpenID communities, but I do believe that the OpenID guys owe it to their prospective users to discuss the pros and cons of the technology. (Some of which I described in my last post)

AOL OpenIDiocy

2007-02-16T16:01:00.000-05:00

While the subject is intentionally inflammatory, I am simply frustrated how AOL can push a specification into the limelight which makes security worse in its current form. Unfortunately, the hype and ballyhoo which has ushered in the coming of OpenID has largely excluded any intelligent discussion of the security implications outside of the email lists. Now, I'm happy to hear about the integration and use non-phishable technologies with OpenID (such as Firefox 3.0 & CardSpace), though AOL's decision to move ahead without addressing the array of concerns is rather careless. Even if AOL's intention for the service is as a proof-of-concept or a demonstration, it exposes very real credentials and resources.

To reiterate the security concerns, here's why I won't use an AOL OpenID:

1) It places too much power in the hands of a potentially dangerous website. Instead of sending me to openid.aol.com/sn, I get sent to a similar looking site. In AOL's case, this is painfully easy to pull off given the simplicity of their interface. After naively providing my credentials to the site, all of my attached resources that I consider valuable are compromised. It puts any OpenID protected resource, my AIM account/email (if I used it), and any other resource where I might reuse the same credentials at risk. Now, I don't reuse passwords between resources, but how many people do?

2) It creates OpenID's for people who don't understand OpenID. I can now create a website that offers a login page that says,

Don't have an OpenID? You do if you have an AIM account! Log in right here:

and continue with my phishing attack. Now such an attack could admittedly happen even outside of the OpenID context, but it immediately taints the (otherwise) good work that has been done in the community. Even with a non-phishing OpenID site, does the average user realize that they're revealing their screen name to the site? Not a pseudonym/unique ID, but the actual user's screen name.

3) AOL's OpenID login interface does not have human-in-the-loop verification. How many AIM accounts are used by spammers currently? How trivial is it now for that account to be "repurposed" into a blog spamming account for those sites which support OpenID? OpenID's best defense so far to such threats has been the high-cost, low-return of setting up a spammer-sponsored OpenID provider. AOL's easily automatable interface, complete with innumerable already established dubious accounts, are quite likely to overcome this problem for them and form a blog-spamming haven.

Also, consider that the OpenID mantra has been operation in full promiscuous mode. When blogs start getting spammed, are they going to block all of AOL? Individual users?

4) The concept of having a unique ID on the internet just doesn't suit me, especially when it's my AOL ID. Now, many will say that this is "tin-foil-hat land", though I think this is just as bad, if not worse than, the Intel serial number controversy. Is it really that much worse that you have people actively offering the ID to sites rather than hardware doing it for them? At least the processor offered an obscure ID number with it rather than my AOL screen name!

And, if you think for a second that the fact that you consent to the transaction is any consolation, please refer to point #2 above.

-

There are further questions about the accountability between providers and websites, the ability to preform MITM attacks, and other privacy concerns, but the 4 reasons above should be enough to invoke some critical thinking. Some of these issues are with OpenID, while others are related to AOL's implementation, though all are arguably frightening.

I am not an opponent of OpenID. After the phishing problem is handled, I think that it will be a highly useful tool for authentication to low-value resources (i.e. most of the sites on the internet), especially when you understand the risks and implications. But it's just not ready for the prime-time yet. But with AOL's decision and the hype from the Web 2.0 crowd, it's already on its way there.

I would encourage anyone considering using this technology (either as a client or a implementer), to seriously research the security implications. Even more importantly, AOL should actively offer disclaimers regarding these issues. They're too important to allow a user to fall prey to a nefarious website.

Crazy?

2007-02-11T04:12:00.000-05:00

The latest version of the InfoCard integration guide calls out a problem that I groaned about earlier:

IMPORTANT NOTE: Notice that the URI used as the value of the ValueType attribute on the wsse:KeyIdentifier element to indicate a SHA1 thumbprint based key identifier is a slightly outdated URI value. The new prescribed value as per the WS-Security v1.1 standard should be as follows:

http://docs.oasis-open.org/wss/oasis-wss-soap-message-security-1.1#ThumbPrintSHA1

Support for this newer URI will be added in a future versions of the Information Card Profile.

So as much as I would like to think that someone out there actually listened to my complaints, I realized that this was probably documented before I said anything. Oh well.

Success!

2007-02-11T03:34:00.000-05:00

Ah. Sweet success. Finally.

A InfoCard compliant STS which issues credentials from a LDAP backend based on X509 credentials. A pursuit which was wonderfully enlightening, painfully tedious, and maddening at times. Thanks to an idiotic obsession to complete this thing and some limited help received from a Java PingIdentity guy on the MSDN forums about proper certificate hashing (!), I've got a working proof of concept based on the work of the XMLDAP work.

As I close the compiler and take a few deep breaths (and back everything up to a DVD-R), I figured I'd have a quick reflection upon a few things I've learned.

1) Microsoft hasn't seemed to dedicate the necessary support to handle developers' questions. Perhaps it was just the time of the day/week/year that I asked, but getting the ear of anybody of consequence on the MSDN forums was not possible. Simple yes/no questions appear to languish unanswered for weeks and months. I won't rant about this subject again, but an identity metasystem built upon open standards but with a closed reference implementation and no support can be just as frustrating to develop for as an all-closed solution.

2) PingIdentity announcement of their intention open-source their InfoCard related code (RP and STS) is just lip-service. I defy them to prove me wrong. :)

3) The CardSpace client wants WS-Security headers, but it really doesn't care what's included.

4) The CardSpace client will fail with a critical fault if it cannot write to the logs. It's a bug that's been identified in the MSDN forums, but it's pretty damn frustrating when the CardSpace client fails, causing IE to fail, causing Explorer to fail, eventually requires Windows restart. (for approximately 20 iterations when I thought it was my STS cards causing the problem)

5) One's progress on a given task is directly proportional to the demand for one's presence elsewhere. It is, therefore, impossible to get anything done.

6) As I continue working with the technologies, the more my mind wonders regarding use cases and applicability.

More to come later, but a good high-level start.

CardSpace Apache Module

2007-02-06T12:17:00.000-05:00

Ashish Jain announced the release of the Apache CardSpace Module today in his blog. I'm really happy to hear that. Together with the Firefox 3.0 adoption of the spec, there should be plenty of tools to start piecing together some really interesting solutions.

But where is the bigger fish (IMO), the open-source STS? There is apparently some interest judging from the comments on his blog, but emails requesting access have thus far been dismissed. Or maybe it's just my emails.

My IDP Quest...

2007-02-06T12:04:00.000-05:00

I'm still having fun in my IDP quest. I've successfully navigated the X509V3Credential issue thanks to some help from the MSDN board and despite some apparently bad or outdated MS doco.

What does that mean? I'm accepting requested along with a client certificate (which I trust), which is then included into the card I issue. When the user selects the card, the CardSpace client will retrieve the certificate from the appropriate store and use it for authentication back to the IDP. The IDP will retrieve attributes based on the certificate subjectDN from an LDAP, and send them back to the user in a SAML assertion. And then it dies.

Why? I'm not including the right WS Security headers in the response, if the CardSpace logging is to be believed. Which ones do I need to include? Got me. I don't know if it's a requirement set by the CardSpace client or by WS-Trust (which I'm admittedly not terribly knowledgeable about), but I'm working on it now. I'm going to review the spec to hopefully find some insight on the problem.

Ditto...

2007-02-03T01:15:00.000-05:00

As a frequent listener of STODID, I have to say that I'm in complete agreement with Paul. Not that I'm not interested in OpenID, but let's diversify a bit...

I'm glad Aldo is listening, however. Maybe some specific discussions about these technologies in the enterprise realm (and no, not just OpenID).

:)

(Not) Working with InfoCard

2007-02-03T00:12:00.000-05:00

So I've got a working STS based on the work provided by the XMLDAP code- great work by the way. Issuing card and pulling user info from an LDAP, I'm really happy about how things are coming together.

Now if I can just get X509 authentication working. I've hit a few issues along the way, but the cards are kinda working now- they're at least importing correctly. I'm issuing cards with X509Credential identified with a SHA-1 hash of the certificate I want to use, but the Windows CardSpace client goes brain-dead when trying to find the certificate I specified. I browsed the MSDN forums looking for a solution, and I'm hoping that someone can clear up why this is happening.

I'm a bit frustrated at the problems I've been hitting; not because I because I have any expectation of a seamless development/integration process, but because I don't have the ability to examine the CardSpace client. As the de facto reference implementation for identity selectors, not supporting it is simply not an option (my personal admiration for the XMLDAP selector aside). Perhaps I've just been spoiled by the ability to load open source products into a debugger and figure out why things are breaking, but I hate being hamstrung by an issue that I could likely figure out with a bit more visibility.

Please, Microsoft- provide more context and detail on the client logging. A namespace error leading to an entry of "Inner Exception: 'None' is an invalid XmlNodeType. Line 1, position 1." isn't terribly helpful. I realize that this is a V1 release, but this is painful. When attempting to use the corrected card using X509, the client dies with a dialog box stating "The certificate associated with this card could not be found" and not so much as an log entry for an undoubtedly loggable event.