Key transition

I'm migrating PGP keys from 0xF9FDD506 to 0x0C14A470. If you signed my old key, I would appreciate you signing my new key as well. Feel free to ping me with questions.

Accordingly, I've published a transition statement signed by both keys.

Why I use my bank's mobile site on my desktop

(or, cutting out bloat by using a platform where bloat won't fly)

Let me start off by saying I'm generally a huge fan of my bank, USAA. Their offerings are free of hidden fees, their phone support excellent, and the perks they provide are competitive. They don't have the best savings interest rates, but you can always find a better deal online to park money not actively in your checking account.

However, USAA's website is a behemoth. My account page took about 8 seconds to fully load, downloading 1.4MiB of content.

The "My Accounts" page you're redirected to after logging in.

It is frequently buggy; whenever I log in via Google Chrome on Ubuntu 12.04 I land on a page with a URL beginning with "https://www.usaa.com/inet/gas_bank/AccountBannerAjax" and a bunch of GET parameters like "currentaccountkey" and "accnumber" with values like "encrypted12a1f4dd1[…]". The server returns a 200 OK, promises a Content-Length of 20, but then actually returns zero bytes. After navigating to the homepage and clicking a button, I end up getting logged in, but I wonder what percentage of their userbase are experiencing this problem?

For some strange reason, I get a lot of checks. It appears that nobody else informed the banking system that it's 2013, and the easiest mechanism for people to send money without paying fees is still on paper. To its credit, USAA made remote deposit of checks available to all customers in 2006, when it was mostly an offering limited to businesses. However, it seems like they haven't updated their web workflow since then. 

Using it on the web still requires using a signed Java applet (itself discouraged by CMU's CERT) that does the incredibly complex task of… letting you select a file from your computer and upload it to their servers. At least, that's what I think it does, because any time I chose "Run", my browser complained a few minutes later that the tab had stopped responding. Regardless of functionality, you can accomplish almost anything their site could currently be doing with HTML5 and a third party service if they want to crop images locally.

Spinning after logging
in on Android

USAA's mobile app for Android has another host of problems; I haven't been able to log into it for 2 weeks, and when I chatted with someone today I was told they were "doing some maintenance this weekend", so I should try again in a few hours once that's finished.

I googled around a bit for some way to perhaps make the applet work in Ubuntu (which admittedly is not a supported platform), and came upon a Facebook thread where a rep suggested using the mobile web site.

A breath of fresh air

I loaded it in my browser, and was amazed at how well it functioned. Obviously designed for higher-end devices (It didn't even load in one WAP emulator I tried), the mobile web interface was a refreshing breath of fresh air. It scaled well to a full-screen device (see below), loaded quickly, and gave me all the information I would have wanted out of the normal web interface.

Most notably: remember the whole "upload a check" workflow that required a buggy Java applet on the main website? We get bog-standard HTML form fields, no additional magic. There goes any theories about the Java client doing some magic validation or prep of the image; here, all they're getting is the images and my session cookie.

I'm still shocked at whoever thought a My Yahoo!-style homepage was the best layout for a bank, but props to the web developers who managed to make a mobile interface that was both pretty and allowed me to work around broken functionality in their implementations on every other platform I had access to.

But why was the mobile web interface the least bloated? Easy. On the desktop, you generally have a nice pipe, or if not, the user knows it and won't be too upset if your site is just as slow as other sites similarly situated. On mobile, the user downloaded all the code already, so the only latency should be the API requests against the server, right?

On the mobile web users have come to expect relatively speedy mobile-optimised sites and there's less screen real estate to do fancy things that get in the way of content. For many sites, that's a huge improvement. Of course, it would be really nice if more banks supported open protocols for interactions (USAA has a read-only, limited-duration OFX feed), but I would settle for a better web interface.

So tl;dr: USAA, please make www.usaa.com redirect to m.usaa.com, kthxbai.

AMPED Status Update

This semester, I created an Android application which processes approval of transactions on the internet in conjunction with a web interface. I walked through the AMPED web interface and server code with my faculty mentor, and we conducted a security analysis of the protocol used in the project. The end result is an application which can be used to handle arbitrary authentication requests, as generated by a server. It performs secure authentication of these requests, and cryptographically signs approved transactions as per the initial proposal. I also produced a reusable Java library which can be incorporated in other projects.

Source code for all parts of the project are available on the web. The code has been released under the GNU General Public License, which allows for free use, modification, and redistribution under certain terms.

• Server + Python client software: http://github.com/lfaraone/mtnas


• Java library and client: http://github.com/lfaraone/mtnac-java


• Android application: http://github.com/lfaraone/mtnac-android (not available yet)

The application is static, and programmatic provisioning for, say, wide deployment, isn’t possible at the present time. In future research I would like to investigate mechanisms for securely provisioning new devices so that we could limit dependence on a secure channel for initial communication, while maintaining the non-repudiation capabilities of AMPED. For example, some combination of a QR code (for an initial shared secret) and a device’s cellular radio could be used to ensure a secure key exchange. After receiving a shared secret, the device would then generate a secret key and transfer the public portion to the server, using the shared secret as an ephemeral key for this purpose. This is similar to what’s used in Google Authenticator, but GA requires both the server and the client be able to generate valid authentication tokens, preventing non-repudiation.

Integrating AMPED into existing software systems would also be potentially fruitful, as this would allow us to see how the project would function under normal usage conditions. To this end, Dr. Simon has expressed interest in the possibility of using a future iteration of AMPED in the administration of wireless sensor networks.

AMPED was developed with funding from the George Mason University Office of Student Scholarship’s Spring 2012 research grant programme, URSP.

Comodo "SSL certificate" incident and what it means for you

For those of you who missed all the news coverage, here's a quick (and hopefully straightforward) explanation of the issue.

What is this?

Executive summary: The way secure communications is handled on the internet is broken, and a recent attack higlighted that. People running the latest version of their browsers are protected.

Whenever you visit a web site, your're either accessing that site through HTTP, the Hypertext Transfer Protocol, or via HTTP inside TLS (Transport Layer Security), aka HTTPS.

With HTTP, anything you do can be watched, recorded, etc by any entity between you and the site you are trying to visit. These entities include your ISP, various internet providers your ISP has peering agreements with, or anybody who is on the same Wifi (or sometimes wired) connection as you.

HTTPS encrypts your traffic to prevent such "man in the middle" attacks. Because the entire connection is private, it can be harder for organizations to filter out specific HTTPS sites.

My personal website is available via HTTPS, and your browser accepts that it is connecting to me and not an impostor because GeoTrust / RapidSSL checked the domain records to find my contact information, and called me up to make sure I am who I say I am.

To ensure that when you connect to a site, you are actually connecting to that site and not a malicious attacker, your web browser relies on Certificate Authorities, which vouch for a site's identity. Any CA can vouch for any domain, and there are almost 50 such entities which Mozilla Firefox fully trusts. Microsoft trusts hundreds, including a variety of governments ranging from France to South Korea to  Hong Kong.

What happened?

Recently one of these CAs, Comodo, was compromised, insofar as somebody was able to get a signed certificate for a domain they did not own. From what I understand, the attacker gained control of a reseller account at Comodo, and there were inadequate checks to prevent the now compromised account from issuing fraudulent certificates.

In this case, they were able to obtain certificates for the log in pages of Google, Yahoo, Windows Live, and Skype, as well as the Mozilla Addons site. Full details are in their incident report. Based on their initial analysis, the attack appears to be sourced from within Iran, and Comodo has concluded that the breach was orchestrated by the state.

Since Comodo's certificates are trusted by all major browsers, these sites can be impersonated by others, even though none of the targeted sites used Comodo.

Why should I care?

The Iranian government or another organization controlling those certificates can intercept usernames and passwords, and access private information. This is of primary concern to Iranian dissidents, but could be used by the government there to target anybody they don't like, given the right circumstances.

What can I do about it?

Well, this breach has shown that the process for revoking a certificate is horribly broken, since most browsers do not check to see if a certificate is still valid. Fortunately, the major browser vendors (Mozilla, Google, and Microsoft) have all issued updates, so if you are running the most updated version of your browser (which you should be doing anyway!) then you are protected against this specific attack. ((Well, Apple hasn't as of this writing, but you can work around it via this  method))

However, the incident shines light on the wider issue of the way our internet trust model works: allowing hundreds of unrelated organizations to vouch authoritatively that somebody else is who they say they are. This is a hard problem in information security to solve, and most of the proposed alternatives (cough DNSSEC) also suffer from having a trusted issuer. It will be interesting to see if any decentralized alternatives to CAs gain traction because of the Comodo affair.

Simple two-factor authentication

I've been thinking a lot recently about information security and passwords. It's widely agreed that two-factor authentication, which combines something-you-know (a password) with something you have (eg. a smart card or some one-time-password) is superior to using a password by itself. Most solutions I've seen, short of client-side certificates, both require a trusted third party and provide little auditability.

I'm working on a project which attempts to address those problems. Basically, the idea is that you attempt to perform an action on a website, like logging in, moving some money between accounts, or restarting a cluster. Then, your mobile device ((iPhone used in the graphic to the right because a SVG was handy. Image adapted from work by Virgile Pypaert [CC-BY-SA-3.0], via Wikimedia Commons)) (Android, iPhone, or some custom hardware) starts buzzing, displaying the text of the action. When you approve or deny the action, your device uses a locally stored private key to sign the text of the approval and send it back to the server. The server checks that you approved the same transaction number and text, then allows the action. The server can store the approval notice to allow auditors later to determine that somebody in possession of the private key signed the action request.

So far, I've written a small Django server application, and a Python CLI device and client. They're not yet ready for a public release; I need to write up installation instructions and test it a bit more, but I'll publish them soon on Launchpad. On the usability side of things, I plan to conduct some trials in January comparing it to things like Google Authenticator.

This should be less susceptible to MITM attacks than one-time-passwords, since you can authenticate specific transactions, rather than entire sessions.

On the other hand, I'm no security researcher. Dear lazyweb, are there any problems with the above approach? Also, if I'm going to release this (as I plan to once I get something working), I need a name. Ideas?

Key transition

As Christian mentioned, the Debian Keyring Maintainers did a "promote" this weekend of the new keyring. I figure it's an opportune time to perform a public key transition, since this had the effect of replacing my key on the keyring.

For my new key, 0xF9FDD506, I decided to opt for a 4096-bit RSA, which is stronger than I should have to worry about for the foreseeable future. The key is much better connected than my previous one, 0x0AC70206. I also have a transition document, ripped almost word-for-word from Christian's.

If you signed my previous key, you should sign the new one unless you're feeling extra paranoid today.

Low-tech anti-surveillance tool for the OLPC XO-1

After reading several articles about the alleged spying that was enabled by a Pennsylvania school district via its one-to-one MacBook, and seeing discussion on a variety of mailing lists, I've decided to implement my own zero-cost, no-hassle solution to the problem for the OLPC XO-1's camera.

This should be able to be adopted in deployments everywhere, by anyone with a piece of paper, or anything else they can slide through the plastic faceplate.

Just say no to fancy addons and factory-added "shutters" or "covers", make your own!

Personal Security: the Secret Question and Answer

In this session, we'll explore some parts of infosec which should be taught in primary school.

We're all too smart to use the same password on multiple sites, right?

While most people, I included, cannot say "yes" to the first question (at least not for everything), that alone is not enough. This is because no matter how secure your password is, be it 20 letters long with various dingbats and ?? characters, there is a weak link in this system. Or rather, two:

Your email is an obvious vulnerability: if someone was able to gain access to that, it would be trivial to reset your password for Facebook, YouTube, Meebo, etc.

What if you have a strong email password, you ask? In that case, we get on to the heart of the matter (which is also the most relevant to all those social networking users out there): secret questions.

Secret Q&As (SQAs) were initially a good idea: provide an alternative in case one has lost access to one's email, or never set one in the first place. (as with Gmail or Yahoo) It presents an interesting problem, however: while the average netizine is unlikely to know the mother's maiden name of dogggzlover98382374@hotmail.com, if even your name can be figured from your email address (or the attacker knows you personally), it is trivial to use sites such as Facebook and MySpace to find the answers to SQAs. A rather public example of this vulnerability can be seen when Sarah Palin's email account was broken into last summer: all of the information needed could be found out using public records.

An example of a possible attack against Facebook in particular:

• Gain access to someone's profile by either friend-requesting outright them or by masquerading as someone they know (and don't already despise)


• Look for an email address on the profile or in wall posts.


• Visit their email provider and reset their email password via the information in their profile.


• Now reset their Facebook password. This will send an email to their address, which you already have access to.

This works against any site that uses a email-loop, even if it is well designed to avoid common SQAs. Social networking sites, however, are particularly vulnerable because of the wealth of personal information one shares freely on them.

This is because, as they are part of your personal history and not transactional, SQAs are almost always the same between sites. So, if you're truly concerned about your information security: use something random for your SQAs and store them in a safe place.