It's time to ditch passwords. Mobile-based biometrics offer a better way.

Passwords as an authentication mechanism have been declining in usefulness over time. The headlines are filled with increasingly sophisticated attempts at phishing passwords. And of course, some of those passwords aren't that difficult to guess anyway. 


As figure 12 from Verizon's 2019 Data Breach Investigations Report shows, more than 60% of data breaches can be traced back to a password compromise. Clearly, relying on passwords for security is a losing bet.

Given these weaknesses, it's about time we ditch passwords. We need password-free authentication mechanisms! 

I believe using mobile-based biometrics can offer a path to eliminate passwords while offering both increased security AND enhanced usability. Structuring solutions with care and thought can help preserve user's privacy as well.

Biometrics measure characteristics about you as an individual, such as your voice, face or fingerprint and then turn that into a unique model that can be used to identify you. Apple's Face ID for example uses facial characteristics to determine a person's identity. Microsoft's Windows Hello uses fingerprint or facial characteristics to let people log into Windows without a password. Millions of users are comfortable with using biometrics in their daily lives.

There are several issues with biometrics, but a well-designed system can mitigate or eliminate them. First, biometrics can be spoofed. Some biometrics such as fingerprints are easier to spoof than others such as face and voice. Second, the use of biometrics presents unique privacy concerns. They need to be stored carefully and their lifetime carefully controlled. Finally, there is always the possibility of false rejects, where a user doesn't match their own biometric.

With good product design using mobile-based biometrics, we can mitigate or eliminate these issues. A well-designed system would have the following features:
  • Use multiple biometric modalities (e.g. face and voice) for verification
  • Store biometrics securely on the phone
  • Use a given phone as a second factor of authentication

By combining the phone and collected biometrics, we have a powerful two-factor authentication system. An attacker would need to steal the phone as well as build a biometric spoofing system. Given how dependent users are on their mobile phones, they would quickly detect that their phone is missing should an attacker steal it. Compare this to passwords where users are usually unaware of their password being stolen. 

Next, by using multiple biometrics, the system can switch between biometric modalities to raise the difficulty for an attacker. For example, if the system collected face and voice biometrics, when the user wants access, it may randomly select one or both modalities to use. It can even adapt based on the risk profile of the authentication. Failure on one biometric may cause it to use the other. An attacker now not only has to steal the phone without detection, she also needs to build two distinct spoofing systems. Of course, there are simple techniques such as liveness to detect spoofing, as well as active research in academia on how to algorithmically detect spoofing, so we can have confidence that spoofing will become progressively more difficult. 

The use of multiple biometrics also deals with the false reject problem neatly. If a user fails authentication on one modality, they can usually succeed by trying again. If that fails, they can then try gaining access using the second modality. Since biometric systems are designed to have very low false reject rates, the probability of sequential false rejects across multiple modalities is infinitesimally small. 

Such a system can be made highly secure with this design, but what about user privacy? I think Apple presents a very viable model on how to treat user biometrics. It stores biometrics securely on the device, in the Secure Enclave. The mobile app using biometrics should only store the user's biometrics on the device, and under the highest security storage mode available. This way, biometrics can be protected from unauthorized access. In addition, they should be deleted when the mobile application is deleted. This gives users assurance that they are in full control of their data.

It is my belief that the promise of general-purpose password-free authentication systems, especially for enterprise authentication, will be fulfilled by mobile-based multi-biometric systems. Given the state of password authentication, their arrival will not be a moment too soon. 





The debt that Silicon Valley owes to MLK Jr.

On MLK Day, the nation remembers Martin Luther King Jr. and all his contributions to civil rights. He is certainly one of the few that have changed the face of this country for the better, using nonviolence to make it live up to its founding creed. What is I think less well known is how that struggle impacted Silicon Valley for the better.

The Immigration Act of 1965 changed the demographics of immigration into this country, and that act was a direct consequence of the civil rights struggle. The prior dispensation enforced quotas based on existing populations already here, which effectively meant that non-white immigration was more or less a trickle. The focus on human rights and civil rights made such a system untenable, and in 1965 a fairer immigration system was put into place. 

(ok that's a fictional Silicon Valley, but it looks way cooler than the real thing)

For Silicon Valley, this had very consequential and positive effects. Newly minted tech companies needed engineers to fuel their growth, and the new immigration system allowed them to hire engineering talent in a way that was not possible before. Then of course, these new foreign engineers liked what they saw here, became Americans and started their own companies, adding to the economic activity of the Valley. It was the inception of Silicon Valley's virtuous cycle of company formation. 

This cycle then created what we think of as distinctive features of the Valley - these engineers, the founders of their companies and regular employees could if they were lucky strike it rich, which meant that the limited real estate they then went to buy went up in value. Enter the phenomenon of the $2M shack.

New restaurants then opened to cater to those missing the foods of the home country, leading to a diverse food scene -  one of the most interesting in the nation. Some locals liked the new foods, and now it's hard to think of the Bay Area food scene without Indian, Vietnamese or Chinese restaurants. 

So on this MLK Day, people in Silicon Valley should be grateful to MLK Jr. not only for the equality of rights that we take for granted for all people, but also for being a central reason why Silicon Valley is what it is today.


Teach your old C preprocessor a new trick

How many times has this happened to you: it's late at night, you're debugging code that uses an enum that means something to the app but totally meaningless to you, and the output prints a whole bunch of enum values, and you have no clue what they stand for?

Well, it happened to me once too many times, and I looked around for a solution that didn't involve maintaining two separate lists - one of the enums and one of their string values. That was a potential debugging headache waiting to happen, and it certainly wasn't elegant! Since I didn't find anything suitable, I came up with this solution that uses the C preprocessor's stringize operator, and lets you maintain only one copy of the enum values for easy editing. The solution extends the X Macro pattern. Note that this is in the Objective C flavor, and you'll need to remove the '@' (string literal) operator if you're not using Objective C.

First, the definition:

#define ENUM_TABLE \X(ENUM_ONE),    \
X(ENUM_TWO)    \

#define X(a)    a
typedef enum Foo {
    ENUM_TABLE
} MyFooEnum;
#undef X

#define X(a)    @#a
NSString * const enumAsString[] = {
    ENUM_TABLE
};
#undef X

Now, to use it, it's fairly straightforward:

MyFooEnum t = ENUM_ONE;
NSLog(@"Enum test - t is: %@", enumAsString[t]);

t = ENUM_TWO;
NSLog(@"Enum test - t is now: %@", enumAsString[t]);

which outputs:

2014-10-22 13:36:21.344 FooProg[367:60b] Enum test - t is: ENUM_ONE
2014-10-22 13:36:21.344 FooProg[367:60b] Enum test - t is now: ENUM_TWO

I hope it eases your debugging!

How Game Theory Can Inform Product Creation And Management

We've all seen this situation: a new company creates what looks like a dumb product that experts say has zero chance of taking off. Said product is released to the marketplace, and it takes off like a rocket. Users love it. Our experts are dumfounded. There are of course web monuments to the canonical foolish prediction of experts.

So that begs the question - why do some products succeed while others fail? 

I believe that the mathematical area of game theory can offer a useful framework for understanding this phenomenon, specifically the concept of the Nash equilibrium. You may remember it from the movie "A Beautiful Mind" (though oddly enough what was depicted in the movie isn't quite the Nash equilibrium). A Nash equilibrium in a game exists when the players in that game, taking into account the strategies of the other players, can't improve their payoffs by changing strategies. In other words, they have arrived at a strategy that they believe maximizes their payoffs, given their understanding of the strategies of the other players around them.

A new product, therefore, must play within a 'game' where the 'players' are customers, competitors and influencers. The current game is at a Nash equilibrium point, where players don't have an incentive to change behaviors. Thus, a new product must positively change payoffs for some players within this universe, and enough of them, such that the system as a whole moves to a new Nash equilibrium. 

This implies three important insights that make intuitive sense to those who have experienced both successful and unsuccessful product launches. 

First, it is important to understand at the most granular level possible who the players are within the system. In the case of an enterprise product, it is tempting to classify a large corporation as a single player, but in most cases this would be suboptimal. A large corporation is composed of multiple business and administrative units, each with its own set of goals and concerns. And each person within these departments brings their own goals, ambitions and concerns. It's easier to sell a new product if you understand these concerns of these players and can align its benefits to their goals. In other words, you are changing their payoffs and giving them an incentive to push toward the new Nash equilibrium you desire. For a mobile app, the analysis is somewhat simpler. Without understanding who the players are in your game, however, it's unlikely that your product can align up to their desires, and thus unlikely to generate traction in the marketplace.

Second, the payoff change should be significant enough for the various players to want to change their strategies. This is more pithily explained by Paul Graham's phrase "Make something people want". If you understand who your target players are, then it becomes much easier to understand their wants. In many cases, especially for a somewhat revolutionary product, the target players may not realize they want it till it's available. Even after something is available, targets may be underwhelmed by what's released. However, understanding how they view the game and the payoff will allow you to set a starting point that maximizes the product's chances. And this understanding will allow you to chart out the path for refinement of the product's features, giving you a better foundation for choosing which features to change and which to drop.

Third, if you've played the game correctly, and the system is now at a new Nash equilibrium, then congratulations! - you have a payoff too in the new dispensation. Understanding the payoffs of the other players will let you understand what your likely payoffs might be. Note that your payoff may not directly be from your users - ad supported models, for example. Understanding how your payoff relates to that of the other players within the game lets you craft a payoff for yourself as well.

By reframing product creation and management within the context of game theory, I hope to enhance your understanding of your own product ecosystems, whether enterprise or consumer. Note that the framework is generalizable to pretty much any product - whether a SaaS product, a mobile app or even a burger joint! I'd be happy to hear your thoughts and comments.

PS I've been thinking of further implications of this framework, and have a series of blog posts planned. Be sure to sign up on the left to be notified of new posts.