10 Tips to Safe Online Shopping

How times have changed. I can remember when Christmas didn’t start until after Thanksgiving—not before Halloween as we see things in stores and online now. Seems like the holiday season and decorations start earlier and earlier every year.

But one thing that hasn’t changed is that Black Friday is still a big shopping day. And with the advent of online shopping has emerged Cyber Monday (the first Monday after Thanksgiving) which is another big sale day for online shoppers. In fact, a recent McAfee study revealed that 70% of American’s plan to shop online this holiday season. And nearly half (48%) of us will be shopping online on Cyber Monday.

Although many of us may take advantage of these great deals that the holidays offer, we also need to be aware of the risks. Online shopping is a fun and convenient way to make purchases, locate hard-to-find items, and discover bargains, but we need to take steps to protect ourselves.

To stay safe this holiday season while shopping online:

  1. Check the site’s web address—Once you arrive at a site, you need to make sure that it is legitimate and not a fake site. So check the URL and make sure you really are at www.amazon.com and not www.amazan.com even though they make look alike.
  2. Check that the site is secure—The McAfee survey revealed that 20% of Americans cannot ever tell if a site is secure. Some things to look for on a secure site include:
    • Check to make sure that the web address starts with https instead of http, which indicates that encryption is being to protect your information.
    • Look for lock symbol on the page which is another indication that the site is using encryption.
    • Look for a security seal, such as the McAfee SECURE™ trustmark, indicating that the site has been scanned and verified as secure by a trusted third party. This security seal indicates that the site will help protect you from identity theft, credit card fraud, spam, and other malicious threats..
  3. Pay with a credit card—Credit cards on the whole offer better protection against fraud than debit cards. You won’t be liable for fraudulent purchases and the thieves won’t be able to drain your bank account if they get your account #. Most banks now offer virtual or one time use credit cards numbers. You can go to your bank’s online site and enter your credit card number and it will give you a number that you can use for a specific purchase. Any use of that one-time credit card number will be automatically flagged or not approved by your bank.
  4. Do not use a public computer or free wireless connection to shop online—If you are using a public computer, strangers may be able to access your browsing history and even your login information. To protect yourself, do all of your online shopping from your home computer or your personal mobile device. Never shop using an unsecured wireless connection (like those free Wi-Fi hotspots at coffee shops) because hackers can access your information.
  5. Make sure you have a clean computer or mobile device—Make sure you have up-to-date security software on all your devices, like McAfee All Access, that can safeguard your privacy, protect against identity theft, and defend against viruses and online threats.
  6. Keep a paper trail—Keep a copy of your order number and receipt, and note which credit card you used. When you receive your credit card statement, review it to make sure that the charge placed on your card is correct and that there are no extra fees or charges.

And here’s a couple more:













































By following some of these simple tips, you can enjoy all the advantages that online shopping has to offer and prevent risking your personal information.

I hope you have a safe, enjoyable holiday shopping season.

The post 10 Tips to Safe Online Shopping appeared first on McAfee Blogs.

Mobile Malware is Here: Beware!

iPhones, Androids and other smartphones are much more than just a way to call our friends and family and store their phone numbers. Today’s smartphones have become our most personal computer and contain much more than pictures and contacts. They now allow us to access financial data, bank accounts, and medical information from anywhere at any time. And for many people, their mobile device has or is replacing their PC.

With all this convenience and access, comes some risk. Criminal hackers see this as an opportunity for them to access your information and make money. And so as the number of mobile devices has grown, McAfee has seen the amount of mobile malware grow.

The Android platform remains the largest target for both mobile malware and spyware. In fact, we see very few mobile threats that are not directed at Android phones. After a slight decline earlier in the year, Android malware has rebounded and almost doubled this quarter with over 20,000 samples.

The infographic below illustrates some of the ways that cybercriminals use to “infiltrate” your mobile device.


























































































What most of these attacks have in common is that they allow a cybercriminal to take over your mobile device in some way. This is why it is critical to protect your mobile device.

  • Only buy apps from a well-known reputable app store, such as Google Play
  • Keep your operating system software updated
  • Be selective about websites you visit
  • Avoid clicking links in text messages or emails, especially if they are from people you don’t know
  • Stay educated on the latest tricks, cons and scams
  • Use comprehensive mobile security, like McAfee Mobile Security that includes antivirus, anti-theft, and web and app protection or comprehensive device protection like McAfee All Access that protects all your devices including your mobile devices

The post Mobile Malware is Here: Beware! appeared first on McAfee Blogs.

Happy 5th Birthday Android!

From Cupcake to Jelly Bean, the last five years have brought many different flavors of smart phones to Android users. People can’t seem to get enough of these delicious digital treats, grossing over 500 million active Android devices worldwide and expecting to reach one billion at some point in 2013.

With its increasing popularity, it’s no surprise that the Android OS is the most attractive target for writers of mobile malware. From April to June 2012, McAfee Labs found that practically all new mobile malware was directed at the Android platform. The attacks included SMS-sending malware, mobile botnets, spyware and destructive Trojans.

Mobile threats continue to evolve as writers of mobile malware become more advanced in their practice. They are looking to steal consumer and business data from unprotected devices ranging from customer lists to personal financial information. These threats are growing in their sophistication and continue to find vulnerabilities through users’ pictures and social media applications.

In the last few months McAfee Labs has uncovered the latest emerging threats that Android users should be watchful for:

“Drive by downloads:” From April to June 2012 there was an emergence of mobile Android “drive by downloads.” These mobile drive by downloads drop dangerous malware on your phone when a user visit a malicious site. Once the user tricked into running the app it steals the personal data stored on your phone.

Twikabot.A: A new botnet client, Android/Twikabot.A, uses Twitter as a means of controlling and executing attacks. The user unexpectedly downloads the malware onto their phone after clicking on a Twitter picture link or message. Once downloaded the attacker can, tweet infected links to followers, install additional malware, delete files and leave the back door open for other attackers.

Stamper. A: Malware authors have evolved the Android/Moghava.A into a new Trojan threat known as Android/Stamper.A by simply changing a few lines of the original malicious code. This damages photos by photo-bombing the user’s pictures with an image of a baby. Users looking for a voting app for the Japanese female pop band, AKB48, unknowingly download the Trojan. The baby picture is from an ad campaign originally targeted at male fans of the band, posing the question “if you and a member of AKB48 had a kid, what would it look like?” The ad campaign put together a sumo wrestler and band member and featured an image of what that ensuing baby would look like. While the Trojan doesn’t change anything except the image and a few strings in the image stamping, users expecting to get results from the pop group’s fan site instead have all their pictures damaged with a photo-bombing baby.

McAfee Labs recommends that all Android users take appropriate precautions to safeguard their devices and personal information. For more information on how Android users can protect their devices visit mcafee.com/us/mms/. You can also download a free guide on mobile security from our Security Advice Center.

The post Happy 5th Birthday Android! appeared first on McAfee Blogs.

Cyber-Scrooges Set in Motion the 12 Scams of Holidays

The holidays are supposed to be a fun-filled time for celebrating with family and friends, but cybercriminals see this as a time of opportunity. They look to take advantage of us during this time when we’re in the spirit of giving and when we’re scrambling to get our gifts purchased, trees trimmed and donations made.

In a recent study, McAfee found that 70% of Americans plan to shop online during the holiday season and that 24% of us will be doing that shopping via our mobile devices. The scary part is that 88% of us would be willing to trade personal information in order to receive a great offer—something that could cause us to fall into scammers’ traps.

Here are the “12 Scams of the Holidays,” the dozen most dangerous online scams to watch out for this holiday season, revealed today by McAfee.


To make sure your holidays are not stolen by the Grinch, here are some tips on how to protect yourself against scams during the holidays, and year-round:

  • Stay suspicious—Like mom said, be wary of any offer that sounds too good to be true.
  • Practice safe surfing—When searching for holiday gifts, use a safe search plug-in such as McAfee SiteAdvisor®.
  • Practice safe shopping—Make sure you stick to reputable e-commerce sites that have been verified as safe by a trusted third-party, like the McAfee SECURE™ mark. Also look for “https” at the beginning of a site’s web address, which indicates that the site is secured.
  •  Use strong passwords— Make sure your passwords are at least eight characters long and contain a variety of upper and lower case letters, numbers and symbols.
  •  Be careful when clicking—Don’t click on links in messages from people you don’t know, and use a URL expander to know what site you are going to before clicking on a shortened URL.
  • Use comprehensive computer security—Make sure you have up-to-date security software that includes antivirus, anti-spyware, anti-spam, and anti-phishing protection for all your devices, including your mobile phone and tablet.
  • Educate yourself—Keep up-to-date on the latest scams and tricks cybercriminals use, so you can learn to recognize scams and avoid potential attacks.

Robert Siciliano is an Online Security Expert for McAfee. He is the author of 99 Things You Wish You Knew Before Your Mobile was Hacked!  Disclosures.

The post Cyber-Scrooges Set in Motion the 12 Scams of Holidays appeared first on McAfee Blogs.

Single sign-on to Google sites using AccountManager

In the first part of this series, we presented how the standard Android online account management framework works and explored how Google account authentication and authorization modules are implemented on Android. In this article we will see how to use the Google credentials stored on the device to log in to Google Web sites automatically. Note that this is different from using public Google API’s, which generally only requires putting an authentication token (and possibly an API key) in a request header, and is quite well supported by the Google APIs Client Library. First, some words on what motivated this whole exercise (may include some ranting, feel free to skip to the next section).

Android developer console API: DIY

If you have ever published an application on the Android Market Google Play Store, you are familiar with the Android developer console. Besides letting you publish and update your apps, it also shows the number of total and active installs (notoriously broken and not too be taken too seriously, though it’s been getting better lately), ratings and comments. Depending on how excited about the whole app publishing business you are, you might want to check it quite often to see how your app is doing, or maybe you just like hitting F5. Most people don’t however, so pretty much every developer at some point comes up with the heretic idea that there must be a better way: you should be able to check your app’s statistics on your Android device (obviously!), you should get notified about changes automatically and maybe even be able to easily see if today’s numbers are better than yesterday’s at a glance. Writing such a tool should be fairly easy, so you start looking for an API. If your search ends up empty it’s not your search engine’s fault: there is none! So before you start scraping those pretty Web pages with your favourite P-language, you check if someone has done this before — you might get a few hits, and if you are lucky even find the Android app.

Originally developed by Timelappse, and now open source, Andlytics does all the things mentioned above, and more (and if you need yet another feature, consider contributing). So how does it manage to do all of this without an API? Through blood, sweat and a lot of protocol reversing guessing. You see, the current developer console is built on GWT which used to be Google’s webstack-du-jour a few years back. GWT essentially consists of RPC endpoints at the server, called by a JavaScript client running in the browser. The serialization protocol in between is a custom one, and the specification is purposefully not publicly available (apparently, to allow for easier changes!?!). It has two main features: you need to know exactly how the transferred objects look like to be able to make any sense of it, and it was obviously designed by someone who used to write compilers for a living before they got into Web development (‘string table’ ring a bell?). Given the above, Andlytics was quite an accomplishment. Additionally, the developer console changing its protocol every other week and adding new features from time to time didn’t really make it any easier to maintain. Eventually, the original developer had a bit too much GWT on his plate, and was kind enough to open source it, so others could share the pain.

But there is a bright side to all this: Developer Console v2. It was announced at this year’s Google I/O to much applause, but was only made universally available a couple of weeks ago (sound familiar?). It is a work in progress, but is showing promise. And the best part: it uses perfectly readable (if a bit heavy on null‘s) JSON to transport data! Naturally, there was much rejoicing at the Andlytics Github project. It was unanimously decided that the sooner we obliterate all traces of GWT, the better, and the next version should use the v2 console ‘API’. Deciphering the protocol didn’t take long, but it turned out that while to log in to the v1 console all you needed was a ClientLogin (see the next section for an explanation) token straight out of Android’s AccountManger, the new one was not so forgiving and the login flow was somewhat more complex. Asking the user for their password and using it to login was obviously doable, but no one would like that, so we needed to figure out how to log in using the Google credentials already cached on the device. Android browser and Chrome are able to automatically log you in to the developer console without requiring your password, so it was clearly possible. The process is not really documented though, and that prompted this (maybe a bit too wide-cast) investigation. Which finally leads us to the topic of this post: to show how to use cached Google account credentials for single sign-on. Let’s first see what standard ways are available to authenticate to Google’s public services and API’s.

Google services authentication and authorization

The official place to start when selecting an auth mechanism is the Google Accounts Authentication and Authorization page. It lists quite a few protocols, some open and some proprietary. If you research further you will find that currently all but OAuth 2.0 and Open ID are considered deprecated, and using the proprietary ones is not recommended. However, a lot of services are still using older, proprietary protocols, so we will look into some of those as well. Most protocols also have two variations: one for Web applications and one for the so called, ‘installed applications’. Web applications run in a browser, and are expected to be able to take advantage of all standard browser features: rich UI, free-form user interaction, cookie store and ability to follow redirects. Installed applications, on the other hand, don’t have a native way to preserve session information, and may not have the full Web capabilities of a browser. Android native applications (mostly) fall in the ‘installed applications’ category, so let’s see what protocols are available for them.


The oldest and most widely used till now authorization protocol for installed applications is ClientLogin. It assumes the application has access to the user’s account name and password and lets you get an authorization token for a particular service, that can be saved and used for accessing that service on behalf of the user. Services are identified by proprietary service names, for example ‘cl’ for Google Calendar and ‘ah’ for Google App engine. A (non-exhaustive) list of supported service names can be found in the Google Data API reference. Here are a few Android-specific ones, not listed in the reference: ‘ac2dm’, ‘android’, ‘androidsecure’, ‘androiddeveloper’, ‘androidmarket’ and ‘youngandroid’ (probably for the discontinued App Inventor). The token can be fairly long-lived (up to two weeks), but cannot be refreshed and the application needs to obtain a new token when it expires. Additionally, there is no way to validate the token short of accessing the associated service: if you get an OK HTTP status (200), it is still valid, if 403 is returned you need to consult the additional error code and retry or get a new token. Another limitation is that ClientLogin tokens don’t offer fine grained access to a service’s resources: access is all or nothing, you cannot specify read-only access or access to a particular resource only. The biggest drawback for use in mobile apps though is that ClientLogin requires access to the actual user password. Therefore, if you don’t want to force users to enter it each time a new token is required, it needs to be saved on the device, which poses various problems. As we saw in the previous post, in Android this is handled by GLS and the associated online service by storing an encrypted password or a master token on the device. Getting a token is as simple as calling the appropriate AccountManger method, which either returns a cached token or issues an API request to fetch a fresh one. Despite it’s many limitations, the protocol is easy to understand and straightforward to implement, so it has been widely used. It has been officially deprecated since April 2012 though, and apps using it are encouraged to migrate to OAuth 2.0, but this hasn’t quite happened yet. 

OAuth 2.0

No one likes OAuth 1.0 (except Twitter) and AuthSub is not quite suited for native applications, so we will only look at the currently recommended OAuth 2.0 protocol. OAuth 2.0 has been in the works for quite some time, but it only recently became an official Internet standard. It defines different authorization ‘flows’, aimed at different use cases, but we will not try to present all of them here. If you are unfamiliar with the protocol, refer to one of the multiple posts that aim to explain it at a higher level, or just read the RFC if you need the details.  And, of course, you can watch for this for a slightly different point of view. We will only discuss how OAuth 2.0 relates to native mobile applications.

The OAuth 2.0 specification defines 4 basic flows for getting an authorization token for a resource, and the two ones that don’t require the client (in our scenario an Android app) to directly handle user credentials (Google account user name and password), namely the authorization code grant flow and the implicit grant flow, both have a common step that needs user interaction. They both require the authorization server (Google’s) to authenticate the resource owner (the user of the our Android app) and establish whether they grant or deny the access request for the specified scope (e.g., read-only access to profile information). In a typical Web application that runs in a browser, this is very straightforward to do: the user is redirected to an authentication page, then to a access grant page that basically says ‘Do you allow app X to access data Y and Z?’, and if they agree, another redirect, which includes an authorization token, takes them back to the original application. The browser simply needs to pass on the token in the next request to gain access to the target resource. Here’s an official Google example that uses the implicit flow: follow this link and grant access as requested to let the demo Web app display your Google profile information. With a native app things are not that simple. It can either

  • use the system browser to handle the permission grant step, which would typically involve the following steps:
    • launch the system browser and hope that the user will finish the authentication and permission grant process
    • detect success or failure and extract the authorization token from the browser on success (from the window title, redirect URL or the cookie store)
    • ensure that after granting access, the user ends up back in your app
    • finally, save the token locally and use it to issue the intended Web API request
  • embed a WebView or a similar control in the apps’s UI. Getting a token would generally involve these steps:
    • in the app’s UI, instruct the user what to do and load the login/authorization page
    • register for a ‘page loaded’ callback, and check for the final success URL each time it’s called
    • when found, extract the token from the redirect URL or the WebView‘s cookie jar and save it locally
    • finally use the token to send the intended API request

Neither is ideal, both are confusing to the user and to implement the first one on Android you might event have to (temporarily) start a Web server (redirect_uri is set to http://localhost in the API console, so you can’t just use a custom scheme). The second one is generally preferable, if not pretty: here’s an (somewhat outdated) overview of what needs to be done and a more recent example with full source code. This integration complexity and UI impedance mismatch are the problems that OAuth 2.0 support via the AccountManager initially, and recently Google Play Services aim to solve. When using either of those, user authentication is implemented transparently by passing the saved master token (or encrypted password) to the server side component, and instead of a WebView with a permission grant page, you get the Android native access grant dialog. If you approve, a second request is sent to convey this and the returned access token is directly delivered to the requesting app. This is essentially the same flow as for Web applications, but has the advantages that it doesn’t require context switching from native to browser and back, and is much more user friendly. Of course, it only works for Google accounts, so if you wanted to write, say, a Facebook client, you still have to use a WebView to process the access permission grant and get an authorization token.

Now that we have an idea what authentication methods are available, let’s see if we can use them to access an online Google service that doesn’t have a dedicated API.

Google Web properties single sign-on

Being able to access multiple related, but separate services without needing to authenticate to each one individually is generally referred to as single sign-on (SSO). There are multiple standard ways to accomplish this for different contexts, ranging from Kerberos to SAML-based solutions. We will use the term here in a narrower meaning: being able to use different Google services (Web sites or API’s) after having authenticated to only one of them (including the Android login service). If you have a fairly fast Internet connection, you might not even notice it, but after you log in to, say, Gmail, clicking on YouTube links will take you to a completely different domain, and yet you will be able to comment on that neat cat video without having to log in again. If you have a somewhat slower connection and a wide display though, you may notice that there is a lot of redirecting and long parameter passing, with the occasional progress bar going on. What happens behind the scenes is that your current session cookies and authentication tokens are being exchanged for yet other tokens and more cookies, to let you seamlessly log in to that other site. If you are curious, you can observe the flow with Chrome’s built-in developer tools (or similar plugins for other browsers), or check out our sample. All of those requests and responses are essentially a proprietary SSO protocol (Google’s), which is not really publicly documented anywhere, and, of course, is likely to change fairly often as Google rolls out upgrades to their services. With that said, there is a distinct pattern, and on a higher level you only have two main cases. We are deliberately ignoring the persistent cookie (‘Stay signed in’)  scenario for simplicity’s sake.

  • Case 1: you haven’t authenticated to any of the Google properties. If you access, for example, mail.google.com in that state you will get a login screen originating at https://accounts.google.com/ServiceLogin with parameters specifying the service you are trying to access (‘mail’ for Gmail) and where to send you after you are authenticated. After you enter your credentials, you will generally get redirected a few times around the accounts.google.com, which will set a few session cookies, common (Domain=.google.com) for all services (always SID and LSID, plus a few more). The last redirect will be to the originally requested service and include an authentication token in the redirected location (usually specified with the auth parameter, e.g.: https://mail.google.com/mail/?auth=DQAAA...). The target service will validate the token and set a few more service-specific sessions cookies, restricted by domain and path, and with the Secure and HttpOnly flags set. From there, it might take a couple of more redirects before you finally land at an actual content page.
  • Case 2: you have already authenticated to at least one service (Gmail in our example). In this state, if you open, say, Calendar, you will go through https://accounts.google.com/ServiceLogin again, but this time the login screen won’t be shown. The accounts service will modify your SID and LSID cookies, maybe set a few new ones and finally redirect you the original service, adding an authentication token to the redirect location. From there the process is similar: one or more service-specific cookies will be set and you will finally be redirected to the target content.
Those flows obviously work well for browser-based logins, but since we are trying to do this from an Android app, without requiring user credentials or showing WebView’s, we have a different scenario. We can easily get a ClientLogin or an OAuth 2.0 token from the AccountManager, but since we are not preforming an actual Web login, we have no cookies to present. The question becomes: is there a way to log in with a standard token alone? Since tokens can be used with the data APIs (where available) of each service, they obviously contain enough information to authenticate us and grant access to the service’s resources. What we need is an Web endpoint, that will take our token and give us a set of cookies we could use to access the corresponding Web site in exchange. Clues and traces of such a service are scattered around the Internet, mostly in the code of unofficial Google client libraries and applications. Once we know it is definitely possible, the next problem becomes getting it to work with Android’s AccountManger.

Logging in using AccountManager

The only real documentation we could find, besides code comments and READMEs of the unofficial Google client applications mentioned above, is a short Chromium OS design document. It tells us that the standard (at the time) login API for installed applications, ClientLogin, alone is not enough to accomplish Web SSO, and outlines a three step process that lets us exchange ClientLogin tokens for session cookies valid for a particular service:
  1. Get a ClientLogin token (this we can do via the AccountManager)
  2. Pass it to https://www.google.com/accounts/IssueAuthToken, to get a one-time use, short-lived token that will authenticate the user to any service (the so called, ‘ubertoken’)
  3. Finally, pass the ubertoken to https://www.google.com/accounts/TokenAuth, to exchange it for the full set of browser cookies we need to do SSO

This outlines the process, but is a little light on the details. Fortunately, those can be found in the Chromium OS source code, as well as a few other projects. After a fair bit of digging, here’s what we uncovered:

    1. To get the mythical ubertoken, you need to pass the SID and LSID cookies to the IssueAuthToken endpoint like this:
    2. The response will give you the ubertoken, which you pass to the TokenAuth endpoint along with the URL of the service you want to use:
    3. If the token check out OK, the response will give you a URL to load. If your HTTP client is set up to follow redirects automatically, once you load it, needed cookies will be set automatically (just as in a browser), and you will finally land on the target site. As long as you keep the same session (which usually means the same HTTP client instance) you will be able to issue multiple requests, without needing to go through the authentication flow again.
    What remains to be seen is, can we implement this on Android. As usual, it turns out that there is more than one way to do it:

    The hard way

    The straightforward way would be to simply implement the flow outlined above using your favourite HTTP client library. We choose to use Apache HttpClient, which supports session cookies and multiple requests using a single instance out of the box. The first step calls for the SID and LSID cookies though, not an authentication token: we need cookies to get a token, in order to get more cookies. Since Android’s AccountManager can only give us authentication tokens, and not cookies, this might seem like a hopeless catch-22 situation. However, while browsing the authtokens table of the system’s accounts database earlier, we happened to notice that it actually had a bunch of tokens with type SID and LSID. Our next step is, of course, to try to request those tokens via the AccountManager interface, and this happens to work as expected:

    String sid = am.getAuthToken(account, "SID", null, activity, null, null)
    String lsid = am.getAuthToken(account, "LSID", null, activity, null, null)

    Having gotten those, the rest is just a matter of issuing two HTTP requests (error handling omitted for brevity):

    String TARGET_URL = "https://play.google.com/apps/publish/v2/";
    Uri TOKEN_AUTH_URL = Uri.parse("https://www.google.com/accounts/TokenAuth");

    String url = ISSUE_AUTH_TOKEN_URL.buildUpon().appendQueryParameter("SID", sid)
    .appendQueryParameter("LSID", lsid)
    HttpPost getUberToken = new HttpPost(url);
    HttpResponse response = httpClient.execute(getUberToken);
    String uberToken = EntityUtils.toString(entity, "UTF-8");
    String getCookiesUrl = TOKEN_AUTH_URL.buildUpon()
    .appendQueryParameter("source", "android-browser")
    .appendQueryParameter("auth", authToken)
    .appendQueryParameter("continue", TARGET_URL)
    HttpGet getCookies = new HttpGet(getCookiesUrl);
    response = httpClient.execute(getCookies);

    CookieStore cookieStore = httpClient.getCookieStore();
    // check for service-specific session cookie
    String adCookie = findCookie(cookieStore.getCookies(), "AD");
    // fail if not found, otherwise get page content
    String responseStr = EntityUtils.toString(entity, "UTF-8");

    This lets us authenticate to the Android Developer Console (version 2) site without requiring user credentials and we can easily proceed to parse the result and use it in a native app (warning: work in progress!) from here. The downside is that for this to work, the user has to grant access twice, for two cryptically looking token types (SID and LSID).

    Of course, after writing all of this, it turns out that the stock Android browser already has code that does it, which we could have used or at least referenced from the very beginning. Better yet, this find leads us to an yet easier way to accomplish our task. 

    The easy way

    The easy way is found right next to the Browser class referenced above, in the DeviceAccountLogin class, so we can’t really take any credit for this. It is hardly anything new, but some Googling suggests that it is neither widely known nor used much. You might have noticed that the Android browser is able to silently log you in to Gmail and friends, when you use the mobile site. The way this is implemented is via the ‘magic’ token type 'weblogin:'. If you use it along with the service name and URL of the site you want to access, it will do all of the steps listed above automatically and instead of a token will give you a full URL you can load to get automatically logged in to your target service. This magic URL is in the format shown below, and includes both the ubertoken and the URL of the target site, as well as the service name (this example is for the Android Developer Console, line is broken for readability):


    Here’s how to get the MergeSession URL:

    String tokenType = "weblogin:service=androiddeveloper&"
    + "continue=https://play.google.com/apps/publish/v2/";
    String loginUrl = accountManager.getAuthToken(account,tokenType, false, null, null)

    This is again for the Developer Console, but works for any Google site, including Gmail, Calendar and even the account management page. The only problem you might have is finding the service name, which is hardly obvious in some cases (e.g., ‘grandcentral’ for Google Voice and ‘lh2’ for Picasa).

    It takes only a single HTTP request form Android to get the final URL, which tells us that the token issuing flow is implemented on the server side. This means that you can also use the Google Play Services client library to issue a weblogin: ‘token’ (see screenshot below and note that unlike for OAuth 2.0 scopes, it shows the ‘raw’ token type). Probably goes without saying, but it also means that if you happen to come across someone’s accounts.db file, all it takes to log in into their Google account(s) is two HTTPS requests: one to get the MergeSession URL, and one to log in to their accounts page. If you are thinking ‘This doesn’t affect me, I use Google two-factor authentication (2FA)!’, you should know that in this case 2FA doesn’t really help. Why? Because since Android doesn’t support 2FA, to register an account with the AccountManager you need to use an application specific password (Update: On ICS and later, GLS will actually show a WebView and let you authenticate using your password and OTP. However, the OTP is not required once you get the master token). And once you have entered one, any tokens issued based on it, will just work (until you revoke it), without requiring entering an additional code. So if you value your account, keep your master tokens close and revoke them as soon as you suspect that your phone might be lost or stolen. Better yet, consider a solution that lets you wipe it remotely (which might not work after your revoke the tokens, so be sure to check how it works before you actually need it).

    As we mentioned above, this is all ClientLogin based, which is officially deprecated, and might be going away soon (EOL scheduled for April 2013). But some of the Android Google data sync feeds still depend on ClientLogin, so if you use it you would probably OK for a while. Additionally, since the weblogin: implementation is server-based, it might be updated to conform with the latest (OAuth 2.0-based?) infrastructure without changing the client-side interface. In any case, watch the Android Browser and Chormium code to keep up to date.


    Google offers multiple online services, some with both a traditional browser-based interface and a developer-oriented API. Consequently, there are multiple ways to authenticate to those, ranging from form-based username and password login to authentication API’s such as ClientLogin and OAuth 2.0. It is relatively straightforward to get an authentication token for services with a public API on Android, either using Android’s native AccountManager interface or the newer Google Play Services extension. Getting the required session cookies to login automatically to the Web sites of services that do not offer an API is however neither obvious, nor documented. Fortunately, it is possible and very easy to do if you combine the special 'weblogin:' token type with the service name and the URL of the site you want to use. The best available documentation about this is the Android Browser source code, which uses the same techniques to automatically log you in to Google sites using the account(s) already registered on your device.

    Moral of the story: interoperability is so much easier when you control all parties involved.