The article demonstrates how easy it is to hijack’s someone’s phone number. And of course, once this is done, you can get the authentication SMS and get in. The article points to a solution that really makes your phone a second factor, such as the Google Authenticator application. It generates a one-time password every 30 seconds, without depending on any communication: you simply need to run the app.

But SMS-based second factor isn’t that bad, and it is definitely better than nothing, and Wired fails to tell us why:

• In the case of a big leak of a few million passwords, any second factor works to protect you against the robots who will check that the password is working before putting it for sale.
• However, it doesn’t protect you well from that guy who is chasing YOU. In that case, the SMS is definitely easier to hack than other methods that require physical access.

Unless you are famous or you are being unfriendly to hackers, it is quite unlikely that you will be targeted personally by a hacker (at least these days, this may change in a few years…).

So,if you are using SMS-based 2-factor authentication, you may think about other methods if they are available (Fido is great). But if you don’t use 2-factor authentication at all, please start by using this SMS thing, it will protect you at least against the major leaks that we are seeing these days.

Wondering which services you can protect with 2-factor authentication? Check this page and realize that most of the sites you use can be protected.

The idea is of course to use NFC technology to simplify this, which would allow the use of strong authentication in more situations. The idea is here to have credentials in mobile phone applications, and to use it in a NFC transaction with a PC. Here, the service provider delivers a user credential in the phone, or delegates this to a TSM. Because the credential will be stored in the secure element, it is possible to emulate all kinds of hardware tokens on the mobile phone, with a similar security level.

This is an interesting way to introduce new applications in the NFC secure element, especially ifhy can make our lives easier. Of course, this assumes that there actually is an infrastructure ready for downloading content to it, and business models in place to actually get the credentials in an efficient way to the secure element. So, some way to go here.

The motivation of myIDP is to reduce the amount of redundant data that we have to enter in various sites, especially related ot e-government, which is error-prone and leads to many validation problems. In the SuisseID, the idea is to add another claim assertion service. With myIDP, users can save data entered on e-forms that have been accepted by a service provider, for reuse in other circumstances. The idea behind it is that information that has already been accepted somewhere is more likely to be correct. Interestingly, the user has access to the recorded attributes, and can decide to remove some that she doesn’t want to be recorded.

MyIDP can function as an attribute provider or as a claim proxy . As an attribute provider, a service provider requests an attribute, MyIDP then asks the user to confirm the use of a recorded attribute, and signs it before to return it. As a claim proxy, the service provider request comes with a claim list request. MyIDP then returns the signed attribute together with a claim list URI, from which the service provider can download information about where the information has previously been accepted as valid, and use this information to decide how trustworthy the attribute is.

This project sounds really good, because once again, we are movng from hard identity to soft identity, where data is not 100% trusted but nevertheless more trusted than data entered manually. And of course, this model is very nice because, the more it is used, the more trustworthy it gets. The quality of attributes grows as they are getting used, and this is an important property.

Internet banking has now taken over as the main interface with banks, with of course a shift to mobile devices in the recent years. In the end, banking is adapting quite fast to technology, because customers expect them to move fast (if they don’t, customers can switch).

So, the banking ecosystem has adapted to integrate new technologies, and they do that fast. Of course, at least according to Vasco, the problem is fraud, and the solution is authentication. Vasco’s answer includes platgorm evaluation (jailbroken or not?), user evaluation (2-factor authentication), transaction evaluation (2-factor authentication again) and finally validation.

The next idea is to use NFC to improve 2-factor authentication, for instance to provision keys, to perform WYSIWYS checks. On the opposite, 2-factor authentication can benefit to NFC, by providing flexible authentication.

That all sounds interesting, but I will need a bit more technical information to undrstand what they are saying. In particular, I am always careful with solutions in which one of the 2 factors needed for authentication isnthe device on which I want to do something. This may not be very rational, bit I am not feeling good about it.

Of course, this presentation was a lot about advertising, and yiu can better understand where Vasco is going to by getting to MyDigipass. This offer sounds interesting for securing online accounts. Maybe that I will consider giving it a try.

What? No standard on the digits that may/may not be disclosed? I couldn’t get the facts from EMV or others (if you know, I am interested), but I noticed that although the digits printed on most of my (French) credit card receipts are the same (9 digits following the pattern xxxx xx00 0000 000x), some of my receipts include the infamous 4 last digits, and an Italian receipt includes the 8 first digits. Just with these few examples, I would say that, either there is no standard about which digits to show/hide, or the standard is not applied anyway. It is not difficult to guess that this is most likely not better on Internet, and not only at Amazon.

On this particular issue, I would blame Apple, because the information they require to grant access to an iCloud account is not sufficient (e-mail, billing address, partial credit card number). In particular, Apple allows you to forget the answers to your security questions, which doesn’t sound very good.

Mat Honan recommends in his paper to move beyond passwords and to adopt two-factor authentication. This sounds sensible, and I approve this move. However, in the present case, how useful would that be? If a cloud vendor uses two-factor authentication, then there must be a procedure for lost tokens. And this procedure better be good.

Not that it’s that complicated to design a procedure that works. We can for instance rely on existing infrastructure, like the Post Office. You can request your password to be snailmailed to you in a Certified Letter, which will require in-person delivery at your home or authentication with a government ID at the post office. This works perfectly against hackers, because they are not good at physical actions that require real presence.

However, this has some trade-offs: delay and price. Changing a password online is about free and instantaneous, whereas sending a physical letter has a cost, and it will take at least one day. I am ready to accept this delay and this cost to protect my most important cloud accounts, because I have some understanding of the risks. Not everybody does.

This actually represents an interesting role for two-factor authentication tokens: end-user education. Because they are a physical object, any user will understand that a new one needs to be sent if it is lost or compromised. And although they won’t be happy, they may/should/will associate the cost and delay associated to the token replacement to the security of their account.