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