Ah the memories.

I just found a screenshot of a very old version of Jotlet – then called Aurora – cerca 2001. It brings back some good memories- built my senior year of high school through freshman year of college, this was Buck‘s and my first and largest project together at the time. I’m uploading here for some grins, and so I can keep all these old images somewhere besides a random directory on my server somewhere…

Aurora – precursor to Jotlet

Everything was themeable, the entire chrome could change w/ a click of the button, and check out that amazing logo in the top right: one of Buck‘s first ever logo/headers :) This version was built pre-Firebug, worked in IE6, everything was built in tables. Liberal use of iframes also going on here.

Stealing Passwords is Easy in Native Mobile Apps Despite OAuth


OAuth is a fantastic login protocol that allows disparate web applications to all use the same login provider. However, I’ve discovered that its use in native mobile applications is borderline dangerous, and in this post I’ll describe why.

Last year I released my first (and still only) iPhone application. Even though my app doesn’t use OAuth, the then recent Twitter/OAuth fiasco stoked my interested in mobile OAuth. I was particularly curious how OAuth providers protected their passwords in their mobile SDKs.

I downloaded the Facebook SDK and poked around in the iPhone simulator, and frankly I didn’t like what I saw. In less than an afternoon, I was able to build an app that could steal a user’s password as they logged in through Facebook Connect, all 100% transparent to the user, 100% transparent to Facebook, and 100% transparent to Apple. In a word, this is not a good sign for OAuth and native mobile apps. To be clear, this affects every single OAuth provider and mobile platform, not just Facebook and iOS.

Despite numerous web searches, emails, and even code submission to Facebook, I haven’t seen anyone talk about this problem on the web at all. Seeing as how the Facebook Connect SDK is almost 2 years old, and many other companies are following suit with OAuth in native mobile SDKs, I think this conversation is long overdue.

In this post, I’m going to explain how and why OAuth in native mobile apps does not secure your password, and why you should still be wary when logging into Facebook/Twitter/Google/anything through any app except their respective official native mobile apps. I’m writing this post to expose the still weak security for single sign on services in native mobile apps. I am not providing any source code, though after reading this post I’m sure you’ll agree that eavesdropping on an OAuth transaction in a native mobile app is extremely easy even for a novice programmer.

The Problem

The purpose of Oauth is to let application developers use Twitter/Facebook/anysite’s login mechanism, all while keeping the password 100% secret from the application developer. In this world, if the application turns out to be an untrusted malicious application, all the user needs to do is turn off access from that application on Twitter/Facebook/anysite’s settings page.

However, native mobile application developers are still able to access (steal) your password even when using OAuth for login, all 100% undetected. This means that for native mobile apps, using OAuth is not any more secure than using Basic Auth, and Twitter’s API change from Basic Auth to OAuth does nothing to protect user’s passwords from malicious application developers.

To be clear, this affects every OAuth implementation in native mobile apps, across iOS, Android, and [I believe] Windows 7.

When your password is safe: Web Apps

As our first example, let’s take a look at web apps – this is true for both mobile web apps and desktop web apps.

OAuth succeeds in protecting the user’s login information because the web browser is a 100% trusted agent and ensures that the application code on the web app’s domain name cannot access any information on the OAuth providers domain name. This is called Same Origin Policy.

For example, when [insert malicious web app here] begins an OAuth login, the browser opens a window/redirects/iframes to the authentication provider (probably Facebook, Twitter, Google, etc). Due to the browser’s security, it is impossible for the malicious app to eavesdrop as the user types in their password. After the user enters their username + password into the legitimate login screen, approves (or disapproves) the web app from accessing it’s account, and is then redirected back to the potentially malicious web app.

At no point in this transaction does the malicious web app have access to the user’s login credentials. Browser security prevents any scripts on the malicious site from interfering/listening to/intercepting the login credentials. It’s this trusted and neutral 3rd party browser that makes this negotiation possible. The phone’s built in browser acts as the trusted middleman during the OAuth transaction.

Once the user discovers the malicious apps evil plot, all the user needs to do is login to the OAuth provider’s trusted site and remove the malicious app from their trusted apps. done.

You’re safe, the world is happy, and OAuth saves the day. Not so in native mobile apps, let’s take a look:

When your password is not safe: Native Mobile Apps

In native mobile apps, the mobile application itself takes the place of the browser, so there is no longer a trusted neutral 3rd party browser to act as the trusted middle man in OAuth transactions – the mobile app itself acts as both the OAuth client and the OAuth middle man!

So what does this mean? It means any native mobile app implementing OAuth can steal your login credentials, completely transparent to you the user, the OAuth provider, and even the phone manufacturer/carrier.

Since the mobile app hosts a tiny instance of the web browser inside of itself, that app can see/do/act on anything inside the web content it shows – no exceptions. This means the Same Origin Policy we discussed above is now out the window. Even though the native app uses WebKit to do the rendering/browsing, that native app can also do absolutely anything to any webpage loaded inside of it, including stealing passwords, without the loaded website even knowing.

I’m not going to show any code, but I’ve verified in code that this is in fact possible. I’ve effectively stolen my own Facebook password using Facebook’s provided iOS OAuth library. It only took minor modifications using entirely publicly available APIs in iOS. The exact same attack could be used in any app that logins with Twitter, and is not specific to iOS – this affects Android (and presumably Windows 7 though I haven’t looked at their API).

How the attack works:

  1. Malicious attacker builds native mobile app and uses any publicly available OAuth SDK from Facebook/Twitter/anyone
  2. The attacker loads the legitimate OAuth login screen using a web view available from the phone’s public SDK
  3. The attacker runs JavaScript on that webview object, attaching JavaScript event handlers to any <input> element on the page
  4. When the value of an <input> changes, the injected JavaScript notifies the wrapping native application about the change
  5. User authenticates, and OAuth transaction is completed as normal – except the malicious app has been listening to every keystroke! Password: compromised!
  6. Malicious app uploads credentials to anonymous server in China

Since the attacker is (a) using publicly available APIs to (b) inject JavaScript on the authentication page (even if the page is over SSL), the malicious app developer is able to listen as the user types in their credentials. The OAuth provider has zero visibility that this attack is going on; there is no way to mitigate it from the provider side. Even a walled garden app store wouldn’t be able to weed out malicious apps based on (a) static analysis of code or (b) watching for malicious network traffic.

This is all because the embedded browser in native applications cannot be the trusted middleman in the OAuth handshake.

Mobile Web: 1, Mobile Native: 0

Currently, the only secure way for OAuth to exist in mobile is for mobile web applications. These applications still run in a trusted 3rd party browser that prevents cross domain script execution. Since mobile native apps fill the role of OAuth client and trusted browser, the user’s login credentials are not secure.

It should be noted that OAuth’s website makes no mention of using OAuth for native mobile apps, but clearly mobile app developers are still using it to solve the elusive secure authentication problem.

Again, this affects 100% of OAuth implementations in native mobile applications, regardless of OAuth provider or mobile platform.


For a long time, Twitter provided only basic auth for it’s API, but its more recent OAuth API isn’t actually any more secure. I believe that the only way to allow secure OAuth within native mobile apps is to have a more strict web browser API for native app developers, and to properly notify OAuth providers when their service is being accessed from an insecure mobile browser. Unfortunately the safest solution right now: don’t use OAuth.

I’m not sure what the correct long term solution is for login in native mobile apps, but OAuth currently falls very short. Mobile still has a long way to go to keep users passwords and data safe.

Adventures in Exotic Domain Buying

This past friday, I was poking around my bit.ly/pro account and couldn’t help but notice the giant yellow banner telling me I needed a custom short domain for my bit.ly account. The nerd that I am just had to get my very own shortener, especially since the window of opportunity might be waning. But what could I do? “welcome.totheinter.net” isn’t exactly short, and “wtti.net” isn’t terribly graceful (or even available!).

I used 101domain’s list of TLDs to spur my creativity. I really wanted to get “ad.am” or “re.ad”, but the second level domain has to be at least 3 characters, so I kept looking until I finally thought of “ada.ms”. Perfect! Especially so for a URL shortener; http://ada.ms/hff-promo will read as “Adam’s HFF Promo”. There was just one catch – the domain was unavailable.

Hoping I could bargain with the current owner, I did a quick whois of the domain and found this:

The domain was indeed registered, and (apparently through 2020!), but it was listed as suspended. Now I’ve been a bit lax with some of my domains in the past, and I know that “suspended” usually means “expired but with grace,” and the only reason registrars don’t outright throw the domain back into the wild is so that they can create another impending event – “quick! renew before someone else…. (probably no one?) snatches up your precious nearly-almost-but-not-quite-expired domain!!”

Since I was currently browsing a middle man’s website at 101domain, I decided to seek out the true source of .ms domains and find out for sure. I’d no idea who the final authority on .ms domains is, but the “mninet” from the whois was all the Googling it took to find out. I double checked the suspended status on their website – just in case – and found that it was, in fact, unavailable for registration. Strike two.

Down but not out, my last ditch effort was to email the Montserrat registrar directly:


I have found that the domain name ada.ms is currently suspended. Is this domain available to be registered? If not, how long does the domain need to stay suspended before it could be registered? I’d be very eager to register this name if at all possible, and appreciate any information you could give me.



This was late Friday night. Hopeful, I went to sleep.

After an eventful weekend (we bought our Christmas tree!), I awoke extremely excited to see this in my email:


That name will be Deleted to allow you to Register it.  Look for it around 10AM EST.


.MS Domain Management

Fantastic! And the casual “Look for it around 10AM” combined with the relatively rareness of .ms domains made me hopeful I wouldn’t be victim to domain sniping in the final moments. I refreshed my iPhone every 2 minutes for the next 2 hours waiting for the domain to become available. Sure enough – the ada.ms became available (it was closer to 11AM EST) as I was sitting in a coffee shop right before work this morning. 30 seconds later, my payment was pending and the domain was mine!

For now, I’ve kept with my plan and setup ada.ms as my custom bit.ly extension, but I’m open to other ideas. While the custom bit.ly domain is pretty cool, I’m a little bummed that the root domain redirects to bit.ly instead of allowing me to redirect it to welcome.totheinter.net – that small feature is for only $995 / mo for Enterprise customers. Instead, I might try using .htaccess, but it feels like a hack. Bit.ly already puts 1 hop between you and your destination. Using that hack would put another hop in between that :( . Either way, I’m more than happy for now, and I’m actually really excited to start using it to send out links. In fact, I have to force myself not to use it so I don’t turn into an overzelous link spammer peddling every mildly amusing link I come across :) .

Lesson learned: short domains are awesome.

Lesson two: Sometimes all it takes is a polite email for opportunities to open up, even when the door seems closed :)

And be sure to click the Tweet This button below the post – your twitter followers will undoubtedly be in awe of your internet savvy when they see the fancy ada.ms link back to the post! :)

Google Author link
Page 6 of 40« First...45678...203040...Last »