ignisvulpis

Monday, November 03, 2014

X-Auto-Login at Google

Below you can find evidence that Google is using the X-Auto-Login header in production.
Please see my other post for context: http://ignisvulpis.blogspot.de/2014/09/deviceautologin.html
 I am using "wget" to get gmail web page and the HTTP response contains the X-Auto-Login header.

I think that Google should standardize this.
Currently Google is using OpenID2 here but it is probably ease to standardize this with OpenID Connect.

ignisvulpis@namenlos:~/mozilla-central$ wget -S https://mail.google.com/mail --user-agent="Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2049.0 Safari/537.36"
--2014-11-03 12:23:50--  https://mail.google.com/mail
Connecting to 212.201.109.5:8080... connected.
Proxy request sent, awaiting response... 
  HTTP/1.1 302 Moved Temporarily
  Content-Type: text/html; charset=UTF-8
  Cache-Control: no-cache, no-store, max-age=0, must-revalidate
  Pragma: no-cache
  Expires: Fri, 01 Jan 1990 00:00:00 GMT
  Date: Mon, 03 Nov 2014 11:23:51 GMT
  Location: https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=googlemail&emr=1
  X-Content-Type-Options: nosniff
  X-Frame-Options: SAMEORIGIN
  X-XSS-Protection: 1; mode=block
  Server: GSE
  Alternate-Protocol: 443:quic,p=0.01
  Connection: close
Location: https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=googlemail&emr=1 [following]
--2014-11-03 12:23:51--  https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=googlemail&emr=1
Connecting to 212.201.109.5:8080... connected.
Proxy request sent, awaiting response... 
  HTTP/1.1 200 OK
  Content-Type: text/html; charset=UTF-8
  Strict-Transport-Security: max-age=10893354; includeSubDomains
  Set-Cookie: GAPS=1:lAGQAL021CeF4UofSLjbzRnvJw_Eqw:256mW0v3ZoeLVjLo;Path=/;Expires=Wed, 02-Nov-2016 11:23:51 GMT;Secure;HttpOnly;Priority=HIGH
  Set-Cookie: GALX=xATUIfBPIN4;Path=/;Secure
  X-Frame-Options: DENY
  Cache-control: no-cache, no-store
  Pragma: no-cache
  Expires: Mon, 01-Jan-1990 00:00:00 GMT
X-Auto-Login: realm=com.google&args=service%3Dmail%26continue%3Dhttps%253A%252F%252Fmail.google.com%252Fmail%252F
  Transfer-Encoding: chunked
  Date: Mon, 03 Nov 2014 11:23:51 GMT
  X-Content-Type-Options: nosniff
  X-XSS-Protection: 1; mode=block
  Server: GSE
  Alternate-Protocol: 443:quic,p=0.01
  Connection: close
Length: unspecified [text/html]

2014-11-03 12:23:51 (1,44 MB/s) - ‘mail’ saved [70172]

ignisvulpis@namenlos:~/mozilla-central$ 

Friday, September 12, 2014

DeviceAutoLogin

Maybe you are an Android user and wondered how sometimes the browser logs you in without asking for a password?

Well, I wondered but never found the time to investigate.

Thanks to the awesome W3C Web Cryptography Next Steps Workshop and thanks to the usual jet-lag I found that time now. First I thought that this is Google-ism "Chrome does some questionable proprietary trick and knows just how to login to Google accounts". That is half-true.

There is chatter on the chromium list but I seems that the Android browser knows this trick since 2011 and Chrome for Android was released in 2012.

So how does it work?

  1. a site responds with a special HTTP header "X-Auto-Login" 
  2. the browser sees that header 
  3. the browser asks the device's account system for local accounts for the realm parameter of the header (e.g. realm=com.google) 
  4. the browser asks for a special kind of token from that account 
  5. the browser asks the user for consent to login 
  6. the token is an URL - so if the user consents the browser opens that URL 
  7. the site the URL points to accepts the token 
  8. the site redirects the browser to the original page the user wants to use

Tadah!

I think this is neat. But why doesn't Google talk about it? Why isn't this standardized at W3C?
Anyway. How can you benefit?
As a user? You already do.
As a website with your own mobile app?
  1. Well, Google is probably not issuing tokens for your site. Maybe they do or would do because they want to be an identity provider?... 
  2. Issue the tokens yourself.
  1.  What you need on the Android device is an AccountAuthenticator.  
  2. let your website issue the X-Auto-Login HTTP header "realm=com.yourdomain&args=..." 
  3. let your Account Authenticator from step a generate tokens based on 'String authTokenType="weblogin:" + args;' 
  4. let your site accept the tokens generated by your Account Authenticator

I think this is a good idea. If your company has an mobile app then build that Account Authenticator. This is even more true if your company has several mobile apps. (Put the authenticator in your own CompanyServices.apk (like Google does with the GooglePlayServices) so you can update independently from your apps.)

You might know that I work for a 100% subsidiary of Deutsche Telekom. Why isn't DT doing this? Don't ask me. I am telling them for years that our own AccountAuthenticator would be "gold". But who listens to me. Working for a big company has its challenges.

Back to wondering... How can we get this or something similar standardized through W3C?

Maybe I should write a blog post to make it more known. But then who reads this blog anyway. ;-)


Thanks for listening.

Tuesday, February 18, 2014

Web Identity Restart?

Well, how can you restart something that never started? ... Never mind.

I am wondering whether it makes sense to have a W3C workshop on "Internet Identity" again. http://www.w3.org/2011/identity-ws/

My impression in 2011 was that the common ground was not very broad so the group decided to launch the W3C WebCrypto working group because all agreed that crypto is a precondition to web identity. Now, three years later I do not see much progress in web crypto or web identity (for that matter).

In the meantime the FIDO alliance was established which has HW-based authentication but a license model that requires that implementers are a FIDO alliance member. That is the opposite of a web standard.

So I think that the WebCrypto WG will not give us "identity for the web". Signing/verification/encryption/decryption are too low level and too easy to use wrong. This is not the way to web identity.

Maybe it is time to restart the web identity effort in W3C.

Tuesday, July 09, 2013

ACM Digital Identity Management

The call for papers to ACM Digital Identity Management is open http://cccs.ncl.ac.uk/dim2013/

"Identity at the Crossroads"

This workshop will explore crucial issues concerning interoperable identity management technologies for the information society.
Identity management has seen a series of development in the recent years. Whereas identity management and federation standards have been solidified and adopted in practice, nations world-wide are investing in electronic identity systems as strong root identities for their citizens offering a promise for strong authentication. Privacy-enhancing identity systems have reached some technical maturity and may offer user authentication with minimal disclosure. At the same time, personal identifiable information and the user's identity has become a commodity to drive the business of global corporations. Whereas such companies sought to bind the users accounts to their unique identity, there has been a reported unrest and anxiety of users because of their diminishing privacy protection.
We see identity at the crossroads. One possibility is the unique identification and strong authentication road that may offer increased trust for e-commerce and increasing cloud services. Another is the road of attribute exchange and leveraging the user's personal identifiable information that may benefit business and help users to have a consistent experience among many mobile compute platforms. Finally, there is the privacy-enhancing identity systems road that may offer additional protection for the user's civil rights. Partially these different roads seem to contradict each other. Research can offer roads less taken that overcome these seeming contradictions and come up with next generation identity solutions.

See you in Berlin in November!

Monday, June 10, 2013

HTTPS EveryWhere Kantara Initiative

I noticed that when I am logged into https://idp.kantarainitiative.org/ and I then access documents
on kantarainitiative.org there is no SSL protection. This is probably not good.

HTTPS Everywhere to the rescue!

HTTPS Everywhere Logo


















I added my own rule to the HTTPS Everywhere Firefox addon. (Works in Firefox 21.0)

<ruleset name="KantaraInitiative">
 <target host="www.kantarainitiative.org" />
 <target host="kantarainitiative.org" />
 <target host="idp.kantarainitiative.org" />

 <rule from="^http://idp\.kantarainitiative\.org/" to="https://idp.kantarainitiative.org/"/>
 <rule from="^http://(www\.)?kantarainitiative\.org/" to="https://kantarainitiative.org/"/>
</ruleset>

Put the above ruleset into the Firefox Profile folder into a file named e.g. kantarainitiative.xml.
On Windows it should be located in a folder similar to this location:
D:\Users\nennker.axel\AppData\Roaming\Mozilla\Firefox\Profiles\uzmmhdde.default\HTTPSEverywhereUserRules
Now whenever I visit Kantara HTTPSEverywhere redirects Firefox to the SSL protected service.

Support EFF!


Thursday, May 30, 2013

Android SSO

The documentation of Android's AccountManager is infamously uninformative. AccountManager is available since API level 5 and I got the impression that Google changed it a lot. I am not sure whether it is still work-in-progress. Probably.

So how does Google do SSO for their own services? Not long ago Google introduced Google Play Services

Google Play Services contains an Authenticator that handles all Accounts for "com.google". The Google apps like GMail etc query this Authenticator for access tokens using the Authenticators getAuthToken method. The application can then use this access token to access the API of its backend server.

How can this be secure? How does the Google Play Services SDK (GoogleAuthUtil) know that GMail is a trusted app?
I am guessing here but I think that Google uses the same mechanism that Google recommends for developers. The keys used to sign an Android app are retrievable by the SDK and can be send to the backend. The backend then checks whether the keys match preconfigures keys.
Of course this security has its limits. On a rooted phone or a custom build phone any app can claim to be the e.g. GMail app by replacing the Android library calls that fetch the signing keys. But then Google knows to which user (Google account) a phone is registered to. Maybe this can be used to inform the user that something is going on or the account can be inactivated. Difficult.
(The new Google Play Developer Console helps.)

I think this level of security is acceptable for most consumer cases.

So let's say your company is a mobile games company (Acme Games) and you want SSO between your apps. Now write your own authenticator and put it into an apk e.g. "Acme Services".
Now each of your games can query the existence of the Authenticator for your domain "com.acme".
If it exists then ask for an access token. If it does not exist then the user has to prove to your backend that he knows something only he can know. (Successful login to a third party (e.g. Google+ Sign-In) or plain username and password). In this step you should recommend to install Acme Services because it helps the user to login to future games he will install. (And synchronization services, backup etc).

It is a pity that not each game can contain an Authenticator. In fact it can but I have not tried it out. I do not know what happens if there are several Authenticators claiming to be authoritative for "acme.com". I guess this leads to trouble or else Google would chosen this way for their own apps.
At least it takes up space in each of your app... That is the official reason given by Google:

You're done! The system now recognizes your account type, right alongside all the big name account types like "Google" and "Corporate." You can use the Accounts & Sync Settings page to add an account, and apps that ask for accounts of your custom type will be able to enumerate and authenticate just as they would with any other account type.
Of course, all of this assumes that your account service is actually installed on the device. If only one app will ever access the service, then this isn't a big deal—just bundle the service in the app. But if you want your account service to be used by more than one app, things get trickier. You don't want to bundle the service with all of your apps and have multiple copies of it taking up space on your user's device.
One solution is to place the service in one small, special-purpose APK. When an app wishes to use your custom account type, it can check the device to see if your custom account service is available. If not, it can direct the user to Google Play to download the service. This may seem like a great deal of trouble at first, but compared with the alternative of re-entering credentials for every app that uses your custom account, it's refreshingly easy.


It is a pity that GoogleAuthUtils are not configurable with your domain, your token endpoint etc. Maybe that is asking too much. We are on our own here and have to reimplements GoogleAuthUtils for our purposes.

Through the method described in this post you are creating your own identity silo. Which is OK if your company is big enough and you do not care about the access tokens being useful at other  (your business partners) sites. If you implement your own authenticator then the backend API and token format are all your own responsibility. PROTIP: use OpenID Connect.


OpenID Connect is a profile of OAuth2. Google is recommending it too. Use it!

If you want interoperability later (business partner integration) then being standard compliant make things A LOT easier!


Tuesday, May 28, 2013

Google: Standardizing Payments on the Web: Introducing requestAutocomplete()

Google is taking huge steps to simplify payments. Which is great!

If you have about 25 minutes then watch this presentation.

The major takeaways:

  • Sites should use standardized names for form input field's autocomplete attributes.
    <input id="nme" name="username" autocomplete="full-name">
    id and name stay as they are but site owner should use standard values for autocomplete.
    WhatWG
  • The browser presents the user with a dialog that allows to choose between different sets of data; e.g. change to different shipping address.
  • On Chrome there is tight integration with Google Wallet and instead of your real credit card information a one time credit card is issued by the Google Wallet backend.
    Caveat: Google Wallet currently is US only!

Google Wallet is only one data source for autocomplete. If Google Wallet is not available then Chrome's local autofill  data is used for autocomplete.

Google said that they talked to other browser vendors but that they could not talks about it right now... Mozilla's Ben Adida compares it to the geoLocation API. Although there is not official statement from Mozilla. Apple shows no reaction yet.


Here is  a screenshot from the presentation showing sample HTML markup.


The documentation is here.

Well, this reminds me of our information card efforts.

Microsoft - the inventor of information cards - took another approach then to integrate into the website. HTML5 was not really there in 2005. Microsoft suggested to use HTML object tags and the website could use the object's parameters to specify what attribute is needed. The Information Card foundation standardized the attribute names.
We did some things differently than Google is doing now and maybe Information Cards where too secure and required too much change on the website. The most important difference between requestAutocomplete and the integration with Information Cards is that the data delivered to the site was a signed SAML token which could contain many more attributes about the user instead of only payment detail.
Providing signed data is kind of a good thing because the site - the relying party - could immediately validate the signature and be sure that the attribute values are issued by a probably trusted issuer. (I won't go into self-issued cards here)
Anyway, it seems the changes needed to be made to the site seemed to have been too big.

Google's requestAutocomplete takes a smaller step. The user experience is probably similar if you compared requestAutocomplete and the information card selection. requestAutocomplete is a big step forward for the current web if it succeeds.
The security improvements are not so big compared to information cards. The one time credit card feature is bound to Google Wallet and other browser vendors might not support Google Wallet. But this is probably not a show stopper. The security level of many current online payment schemes is in fact near zero. And requestAutocomplete is not going to change that.

One thing that I would like to build. Support for requestAutocomplete through a wallet installed on the mobile phone.

So Google's step forward is not as ambitious as the Information Card's one. But...
Who cares if the overall completion rate sky rockets.