Monday, March 30, 2015

New Firefox Add-On: QRCode Login

Current login mechanisms suffer from missing support by browsers and sites.
Browsers offer in-browser password storage but that's about that.
Standardized authentication methods like HTTP Digest Authentication and HTTP Basic Authentication were never really accepted by commercially successful sites. They work but the user experience is bad especially if the user does not have an account yet.

So most sites are left with form-based authentication were the site has full control over the UI and UX. Sadly the browser has little to offer here to help the site or the user other then trying to identify signup and login forms through crude guesses based on password field existence.

There is no standardized way for sites and browsers to work together.
Here is a list of attempts to solve some of the above issues:

Federations have their drawbacks too. Even Facebook login went dark for 4h a while ago which left sites depending on Facebook without user login.

In general there is this chicken-egg problem:
Why should sites support new-mechanism-foo when there is no browser support.
Why should browsers support new-mechanism-foo when there are no sites using it.

Then there are password stores. I use passwordsafe to store my password in one place. If I do not have access to that place (PC) then I can't login. Bummer.
Others use stores hosted on the Internet and those usually support most browsers and OSses through plugin/addons and non standard trickery.
I never could convince myself to trust the providers.

So. Drum-roll.
I started to work on a mechanism that has a password store on the mobile which allows you to login on your PC using your PC's camera.

The user story is as follows:
  1. browse to a site's login page e.g. https://github.com/login
  2. have my Firefox addon installed
  3. click on the addon's icon
  4. present your credential-qrcode to the PC's camera
  5. be logged in
Here is an example qrcode containing the credentials as a JSON array

The qrcode could be printed on paper or generated by your password store on your mobile. To help the user with the selection of the matching credentials the addon presents a request-qrcode to be read by the mobile first. This way the mobile ID-client can select the matching credentials.
(If you don't like to install addons to test this and for a super quick demo of the qrcode reading using your webcam please to to http://axel.nennker.de/gum.html and scan a code)

What are the benefits?
  • no need to change the site's javascript, html markup or https headers. No changes whatsoever needed on the accepting site.
  • no need to have an extra backend server to store your credentials.
  • no need to have an extra backend server to help mobile and browser to communicate.
  • no need for an enhanced browser or client. no need for the browser to know about new markup, new javascript APIs or HTTP headers.
What are the drawbacks?
  • reading the qrcode from the mobile's screen very much depends on the light and camera. Printed credentials work reliably but qrcode on mobile screens sometime give me headaches.
  • You have to install the addon.
  • This is an alpha version. Your mileage may vary.


Login page at githup with addon installed:

Screen after pressing the addon's toolbar icon. The qrcode helps the mobile ID-client to find the matching credentials:
Screen showing the camera picture which is scanned for qrcodes:
This is clearly only a first step but I believe that it has potential to be a true user-centric solution that helps me and you to handle the password mess.

Saturday, March 07, 2015

x-auto-login at Mozilla Services?

As I described here


Google is using a proprietary HTTP header named x-auto-login to log you into Google services like GMail using your local Android account.
This is cool.

Browse to a Google website and be logged in without the need to remember the super secure password. Sadly this is a closed system as we learned when implementing this for Firefox for Android (Fennec).
See https://bugzilla.mozilla.org/show_bug.cgi?id=1030650

Yes, Fennec can talk to the Authenticator and ask for a "weblogin:" token for "com.google" but the Authenticator answers differently depending on who asks. If Chrome is asking then the returned token redirects you to https://accounts.google.com/ and immediately logs you in, but when you'r Fennec then you are just redirected to https://accounts.google.com/ and have to enter username and password. Bummer.

Anyway: How about using this scheme for Mozilla services and using a Mozilla account on the device or local to the browser (Firefox Sync) if available.

  1. browse to e.g. https://bugzilla.mozilla.org/show_bug.cgi?id=1030650 (obviously a Mozilla service) and press the login button 
  2. get redirected to https://accounts.firefox.com/ServiceLogin?service=bugzilla&passive=true&rm=false&continue=https://bugzilla.mozilla.org/show_bug.cgi?id=1030650 &ss=1&scc=1&ltmpl=bugzilla&emr=1 
  3. the response includes an x-auto-login HTTP header in the response 
  4. Firefox sees the x-auto-login header and
    - on desktop look for Firefox Sync account use it to obtain a token from a token endpoint hosted at mozilla.org
    - on Android ask the AccountManager for a weblogin token for "org.mozilla". 
  5. redirect to the token (the token is an URL). In this case e.g. https://accounts.firefox.com/?t=accesstokenb64&...
  6. https://accounts.firefox.com/ validates the token and redirects back to https://bugzilla.mozilla.org/show_bug.cgi?id=1030650
I think this is doable and would benefit the users of Mozilla services.

Next step then (there is always a next step) is to allow third party logins e.g. from githup to bugzilla using x-auto-login.

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


Friday, September 12, 2014


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


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/"/>

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:
Now whenever I visit Kantara HTTPSEverywhere redirects Firefox to the SSL protected service.

Support EFF!