security | Guillaume's blog

Using ATM to send cash – no bank account or card required, only a cell phone.

If you haven’t read this at bankwatch or banktech yet:

Privier’s New ATM Service Requires No Card, Account

The service is a cash-to-cash service targeted at the unbanked population. After registering a mobile phone online as well as other personal information, a user can go to an ATM, deposit cash, enter a mobile phone number, and receive in return a 10-digit withdrawal code that he can send to someone else.

This is essentially an authorization delegation mechanism, and as such it reminds me of OAuth, which allows authorization delegation for APIs on the Web.

The main issue here is adoption: the service is only valuable if the receiving party can go to an ATM that supports the technique, so my understanding is that this will have a real value when it is deployed by a large ATM network operator, or when it is supported accross networks via a common protocol.

Les banques devrait-elles devenir des fournisseurs d’OpenID?

This is a translation in French of an earlier post.

Il y a presque dix ans, au sommet du boom Internet, je me rappelle avoir avoir discuté avec un banquier qui me suggérait que dans le future, le rôle des banques ne se limiterait pas a garder l’argent de leur dépositaires, mais aussi à garder leur identité en ligne secrète. D’une certaine manière, cette prediction s’est concrétisée par le biais des programmes de protection contre le vol d’identité. Cela dit, si l’on définit l’identité comme la somme des informations personnelles qui distingue une personne d’une autre et qu’il est difficile voire impossible de se procurer, on voit bien qu’une grand partie de ces informations (et en particulier les secrets tels les mots de passe) sont disséminés dans un grand nombre de services en ligne (60 en moyenne, bientôt 200, d’après une étude du Yankee Group sur OpenID).

Comme chacun sait, OpenID constitue la solution non-propriétaire à ce problème, et pour les raisons présentées ci-après, il semblerait que les banques soient des candidats parfaits pour devenir fournisseurs d’OpenID:

“Qui peut le plus peut le moins”. Le niveau de sécurité imposées par les services en ligne aux mots de passe de leurs utilisateurs ainsi que l’intérêt des utilisateurs à avoir des mots de passe difficiles, varient d’un service en ligne à un autre, mais la banque en ligne est probablement un des services ou le niveau de sécurité des mots de passe est le plus élevé. La raison est simple: il s’agit du service où les utilisateurs ont le plus à perdre si leur mot de passe se retrouve dans de mauvaises mains. Ainsi, on peut difficilement imaginer un utilisateur s’authentifier auprès de son service de banque en ligne avec son le nom d’utilisateur et mot de passe de son compte Google, mais l’inverse est beaucoup plus plausible
Les banques ont plusieurs actifs existants relatifs à la sécurité:
- Elles ont déjà en place une infrastructure technique assurant la sécurité de l’accès en ligne aux comptes bancaires,
- Elles ont pour la plupart une image de marque forte en terms de sécurité, et
- Elles ont déjà en place des programmes de protection contre le vol d’identité qui fourniraient un complément d’assurance à OpenID, et ferait de cette technologie une vraie solution/vrai produit
- Les banques sont tenues légalement de connaître leurs clients, et ont pour cette raison probablement beaucoup plus d’information sur leurs clients (par example, documents officiels comme carte d’identité) que n’importe quel autre service en ligne (mais pour combien de temps encore?). Cela veut dire qu’elle possèdent le plus large éventail d’options d’authentification, leur permettant de supporter plusieurs niveaux d’authentification. Elles ne sont pas limitées au model d’OpenID classique de l’URL et du mot de passe: elles peuvent non seulement décider d’émettre des URLs OpenID qui soient distinctes du nom d’utilisateur, mais elles peuvent aussi et surtout utiliser une authentification multifacteurs, par exemple envoyer un numéro personnel secret par SMS à un téléphone mobile, ou demander à un utilisateur de cliquer sur un bouton pour être appelé par un centre d’appel, comme spécifié par les OpenID policy extensions.
Enfin, il existe de très bonnes raisons économiques. Un service OpenID offert par une banque consituerait:
- Un service à très forte valeur perçue (mot de passe unique pour potentiellement tous les services en ligne utilisés par un utilisateur) que les banques pourraient faire payer
- Une nouvelle façon de promouvoir leur image de marque: compte tenu du fonctionnement d’OpenID (redirection vers le fournisseur OpenID pour chaque authentification) les utilisateurs verraient le logo de la banque à chaque authentification.
- Un formidable outil marketing: les banques auraient connaissance de quand quel utilisateur utilise quel service et pourraient présenter en fonction des offres et publicités liées ou non à leurs produits lors de chaque authentification,
- Une très bonne manière de garder leurs client: le coût de changement de fournisseur OpenID s’ajoutant aux autres coûts de transfer de comptes bancaires à une autre banque.

Should banks bank on OpenID?

Almost a decade ago, at the height of the Internet boom, I remember talking to a banker telling me that in the future, banks would not just keep your money safe, but also your identity. To some extent, this has materialized with identity protection programs offering insurance against the risk of identity theft. That said, if you view the identity as the collection of hard- or impossible-to-obtain information about a person that uniquely distinguishes her from others, you would certainly admit that a big part of this information (in particular secrets such as passwords) are spread around in a variety of online services (60 on average, growing to 200 according to a Yankee report on OpenID).

OpenID, as everyone knows, is the open solution to this problem, and banks seem to be excellent potential OpenID providers for the following reasons:

“He who can do more can do less”. Password strength requirements and password strength user incentives are not equal among online services, but online banking is probably one of the services where password strength is highest, simply because this is where for most people the loss would be the highest if their password was to fall in the wrong hands. So, users won’t use an easy-to-remember Gmail username/password or blog commenting account to login at their bank, even if the bank trusts Google’s security, but they would probably not mind the reverse.
Existing security-related assets:
- Banks already have the security infrastructure in place to secure financial accounts,
- Most banks are already trusted brands in terms of security, and
- Banks already have identity theft protection program in place that would complement OpenID, which is just a technology
- Banks are required by anti-money laundering laws to know their customer, and have probably more identity-related information about their customers (ex. government-issued documents) than any other online service. This means they have the widest range of authentication options, allowing them to support multiple levels of authentications. They are not constrained to a public URL/private password model: they can not only decide to issue a OpenID URL that is distinct from the existing username, but also use multi-factor authentication for instance by sending a PIN by SMS to a phone or requesting the user to click and get a call from a call center agent, as requested by OpenID policy extensions.
Last but not least, compelling business reasons. A highly secure OpenID would be:
- A value-add service that the bank could charge a premium fee for
- A great way for banks to promote their brands (you’d see their logo everytime you authenticate), get to know their customers’ online usage patterns (which service you are using and when) and present new offers/ads (banking-related or not),
- A great way to retain customers.

twauth: mobile authentication with OpenID and Twitter

I stumbled upon Ian McKellar‘s twauth prototype: a Twitter and OpenID based mobile authentication solution.

The idea behind twauth is to address the usability issues of current mobile OpenID-based authentication workflows.

The particular issue that Ian’s twauth addresses it the effort place on the user to enter alphanumeric passwords.

Twauth addresses this issue by replacing the alphanumeric password entry by a digits-only 5-digit one-time code sent to the mobile phone via Twitter/SMS, that the user then enters on the openid authentication page.

Here are some screenshots of the complete workflow:

1. Entering the twauth mobile OpenID URL at the mobile ma.gnolia.com (m.gnolia.com) http://twauth.ianloic.com/twitteruserid:

2. Instructing the OpenID server to send a direct (private) Twitter message with a 5-digit code (ignore the garbage):

3. The mobile phone that is linked to the Twitter account linked with the twauth OpenID URL is sent a message with a 5-digit code (18010 – screenshot not available)

4. User enters the one-time 5-digit code:

5. You are authentic!

Mint.com: a perfect banking use case for OAuth

Mint.com provides a free service, which is able with your authorization, to connect to your bank(s), retrieve your bank account information and all your transactions and provide value-add services with the data. In particular, it allows you to see where you money is spent and give you hints at how you could save money. I personally think it is a superbly designed UI to the user data held at banks, which shows how much value there is to unlock, and also how much startups can be so much more efficient at delivering innovating services than banks themselves sometimes. Yodlee, a partner of Mint.com, was a dot com era example of this and Mint.com might be their Web 2.0 equivalent.

One problem is: Mint.com requires you to provide your actual username and password to the online banking service provided by your bank, which you use not just to view transactions, but also to make payments, transfers, etc.This approach has several drawbacks. One is that the user can be legitimately concerned about what would happen if this information would get compromised. Right now, Mint.com reassures its customers by saying: “We don’t store your info, Yodlee does”.

Another problem is that every time your online banking username or password changes, Mint.com stops working until you reconfigure it:

Mint.com screenshot showing: wrong username/password

Not very convenient. Add to this the fact that you can’t have any guarantee of what happens to your username/password when you want to terminate your relationship with Mint.com/Yodlee, and you may feel like you won’t use this application for now.

An implementation of OAuth protocol between Yodlee/Mint.com, the user and the bank can solve these problems at once, and would certainly further drive user adoption.

OAuth is self-described as a protocol for “secure API authentication”, but a better way to put it is that OAuth is a way for users to grant controlled access to their data hosted at online service A to another online service B. To use the car metaphor, if your data at online service A was a car, and online service B was the valet parking person, OAuth would be the way for the valet parking person to ask you for your car’s valet key, with which he can only drive a few miles and can’t open the trunk, and the way for you to give him the key. In security jargon, OAuth allows to delegate capabilities on your data to other applications, in the form of signed tokens, i.e. authorizations to do specific things with specific data that you sign with your identity. The beauty of it is: because these capabilities are signed by you, it can be presented by online service B to access your data at online service A without you having to provide your identity credentials (username/password typically) to online service B.

Coming back to the Mint.com/Yodlee use case, here is how it would work:

The user would go to Mint.com to request access to his data at the bank.
Mint.com would request his bank a token for a specific capability, for instance, retrieving transaction data
Upon receiving this request token, Mint.com would redirect the user to the bank’s token authorization page.
The user then authorizes the token (If he is not already logged in, he would do that first)
Mint.com can then substitutes the request token with the access token, and access the user’s data as they requested and as the user authorized, until the token is invalidated or expires.

Here are the benefits of OAuth for the user in this use case:

Mint.com/Yodlee never know the username/password used to log in at the bank.
When the user changes his username/password, Mint.com/Yodlee can still retrieves transaction data
When the user decides to terminate the relationship with Mint.com/Yodlee, he knows they don’t have is username/password and he knows that they can’t access his data anymore.
When you don’t want to use Mint.com/Yodlee anymore, you can simply invalidate

The big question is: how much work would be involved at banks and Yodlee to support OAuth, and in particular, what would they have to change?

Bank of America Online Banking’s user-friendly password strength indicator

Like many Web services, Bank of America Online Banking provides you with real-time feedback about the strength of your password when changing your password. What’s great with their implementation is that it does it via a thumb up indicator for each security rule your password must comply with that gets updated as the user fills out the password. This technique is the best I’ve seen so far at guiding the user into providing a secure password into a short amount of time, thus improving an experience that is generally frustrating given the generally low perceived value by users of these increasing security requirements (just like with anything security-related, users don’t value it until something bad happens to them).

This is a nice evolution from indicators that merely tell you whether the password is low strength or high strength, or even worse: password management systems like P-synch that only tell you what’s wrong with your new password after you have hit the reset button, requiring you to enter multiple time the password and hit the rest button.

Before the new password is provided, only 2 rules out of 4 are thumb up (one might argue that they should be disabled until the user starts to type)

Password strength indicators prior to passcode change

As the new password is typed, the thumps up turn green or red, until all are green and the user knows he can hit the reset button without fearing that the new password will be rejected.

Password strength indicators during passcode change