1. It's extraordinarily difficult to create a fingerprint spoof from a latent print. Yes, there are people who can do it - I can do it - but it's not easy. Notice on the videos of breaking into the iPhone 5s or 6 that latent prints are taken from a single fingerprint placed carefully on a squeaky clean screen. On your average phone, not so much. Someone who picks up my phone off the seat in a subway will be incapable of breaking in - unless I've just cleaned the screen with windex and carefully placed my fingerprint on it.
This is not true, unfortunately. It is true that most devices will have a set of partial prints on them, but it's not actually that difficult to assemble them into a whole print, especially if you're okay with making a whole batch of gummi fingers. You simply apply feature extraction to the partial prints, match up common features across the partials and generate a set of candidate full prints. Doing this requires some software knowledge, but not really that much. I expect to see open source libraries that do it, soon. Once you have your set of candidates, use a high-resolution 3D printer to generate a set of molds, cast your gummi fingers, and try them.
However, this still doesn't mean they're ineffective. They're less secure than a decent password, yes, but that's far from useless.
Fingerprints, in fact all biometrics, are not passwords -- they are usernames.
This is completely wrong. Biometrics are neither usernames nor passwords. They have fundamentally different security properties from both. See http://it.slashdot.org/comment...
the finger (or whatever) it's being presented is real, live and attached to the person who is trying to authenticate, that would be really hard
Unless you are protecting the nuclear launch codes (google 00000000), the device realizing whether or not your finger is still alive and attached to you doesn't matter. For anything other than those launch codes, your finger is worth more than your device.
Liveness matters mostly because liveness seems to be the easiest way to validate "realness". All of the best up-and-coming technologies for detecting fake fingers focus on detecting liveness.
Anyone who cares to can watch a YouTube video, spend $20 at the local hobby shop to get the materials, and spend a couple of hours turning an image of a fingerprint into a gummi finger which will fool most sensors. However, that doesn't mean it's worthless. It only means it's worthless against someone who is willing to do that.
The problem is, the fingerprint is already on the scanner, so there's probably a way to do it with a lot less effort. We just don't know what it is yet.
Meh.
This isn't new technology, and people have been playing with breaking it for quite a long time. It's always possible that someone will come up with a brilliant and dramatically-easier way -- but, really, the gummi finger is pretty darned easy, so the bar for better breaks is high (or low, depending on your perspective) -- but it seems unlikely. And if it does, it will just revise the scaling a bit, not fundamentally change the analysis.
I wish I wasn't an AC here, but dang it, I felt the need to respond.
It means that biometrics should be the username, not the password.
No. This is just as wrong as viewing a fingerprint as a password. Biometrics make lousy identifiers.
What? They make fine identifiers, when compared to the other option, entering your user name or id into a box. It's perfectly fine to view some biometric data as user identification.
Nope. You're wrong.
The birthday paradox is deadly to biometric identification on large-scale systems. It's okay on small systems with relatively few users, but scale it up and it simply doesn't work unless (as many systems do) you also apply some other disambiguating information, like a phone number or an identifier of some sort or statistical modeling to narrow the set of likely candidate templates. Well, unless you're okay with lots of false positives. Put 50K people in one system and identify them by fingerprint only, and virtually anyone who walks up will be identified as someone, and many people in the system will frequently get identified as someone else.
It's not fine to view that same data as authentication, simply because it doesn't prove the user is who he claims to be. The biometric data says "this is who I claim to be", something else needs to be there to say "and this is how I can prove it".
Nope. Assuming you already have a claim of identity (i.e. a username), a biometric provides a decent proof of that identity. How strong that proof is depends on the context and the procedures. For an extreme example (from a system I actually built), if there's an armed guard examining your finger for evidence of fakery, then it's actually very strong. On a mobile device, not so much, but it's still useful. See the other post I linked.
No, I'm not. I'm comparing the usage of both in relation to the level of security they offer. Totally different.
No, you're not comparing security levels, because you're talking about rotation and authenticator secrecy. Both of those concepts are completely irrelevant to biometric security, which means that you're completely misunderstanding how biometric security works, and also the ways in which it doesn't work. Please read my post; it offers an accurate assessment of relative security levels, with a correct understanding of the processes and security models underlying both.
You can do this with any rooted android device and tasker.
No, it would require changes to the system, because the fingerprint subsystem doesn't expose the finger ID to the framework. The HAL API reports the finger ID to fingerprintd, but that doesn't report it further up the call stack.
So you'd to modify fingerprintd to return the finger ID, change the Binder API between fingerprintd and the framework, and modify the framework to report it as well. Or I suppose you could hack fingerprintd to write the last-authenticated FP ID to a file and then allow apps that want to know which finger was used to read it. That would involve poking a few other holes in the security architecture, but would be the easy brute force way.
And the first thing anyone who cares about security does with an Android device is root it and install their own ROM that is free of carrier encumberances and spyware.
Or just buys a Nexus device and (optionally) refuses the various questions asked during setup about providing data to Google.
BTW, be very careful with rooting, and I recommend absolutely refusing any rooting solution that involves disabling SELinux. It's up to you, but poking large holes in the security model does significantly damage your device security.
Any device that can perform different actions based on different finger prints?
None are on the market that I'm aware of. iOS and Android both intentionally avoid distinguishing between different enrolled fingers, because the average user would find it very confusing. I don't know if Microsoft has done the same for Windows phone, but if they haven't they were remiss in their user testing, or they'd have discovered the same issue.
It seems likely that some future alternative Android ROMs will provide this feature.
Problem is, at some point, there's an interface between the hardware and the software, and I have access to the software, and can rewrite it to always get a positive from the hardware
If you have physical access to the hardware and the software then NO authentication is effective. There is no such thing as a secure device in hostile hands.
In an absolute sense, this is true. But in practice it's false.
There are many different degrees of capability among attackers. Your kid sister will be defeated by just about anything. The NSA can penetrate virtually anything. In between, there are lots of gradations, and it is useful to deploy various levels of countermeasures that make the more important on-device secrets harder to access.
On hashing, it really doesn't matter, even if it is feasible. And if it were, it would have been done.
And I would say fingerprints are secrets to some extent.
When thinking about security, you should assume they're public knowledge. If they happen to be less available than that, then you're in better shape than you thought. But given that they're not rotatable and are left everywhere, no good security design should be based on the premise that fingerprints are secret.
I agree, but would point out that using a fingerprint to unlock a strong key on a phone, then using that to authenticate to a remote server is quite strong.
It means that biometrics should be the username, not the password.
No. This is just as wrong as viewing a fingerprint as a password. Biometrics make lousy identifiers. You still need to use a username when authenticating with a biometric. Biometrics work fine as authenticators but they work completely differently from passwords.
I don't understand one thing. You mention that the matching of livescans against templates is done in an area which can't be altered or interfered with. And yet, at some point that hardware (I'm assuming it's all hardware) must send a positive signal to the software that it's OK to unlock the screen.
Yup.
Surely I could compromise the code that accepts that signal to simply always be a positive signal?
Certainly... except for other code running in the area which can't be altered or interfered with.
This is the reason that Android 6.0's fingerprint matching is required to be done in the Trusted Execution Environment (TEE), because that matching signal is used not just by the regular OS to unlock your screen, but also by other code in the TEE to unlock access to cryptographic keys which are presumably used to protect the most important stuff on your phone.
For example, using the new features in Android Marshmallow's hardware-backed keystore (especially this one, your bank's app could set up an ECDSA signing key that is used to authenticate to their servers, providing access to your banking information. That key could be configured to be unlocked by your fingerprint. If the fingerprint matching were provided in the regular OS then any compromise of the regular OS would enable access to your bank account, because the TEE-based ECDSA key would be relying on a signal from the regular OS to tell it to unlock the key. But because the TEE-based ECDSA key relies on a signal from the TEE-based fingerprint matcher, a compromise of the regular OS won't get the attacker in to your bank account (not unless you're around to put your finger on the scanner).
FYI, for Marshmallow the password authentication has also been moved into the TEE, and TEE-based keys can also be access controlled with password auth. So your bank could do the same sort of thing, but require you to enter your device password rather than present a fingerprint.
Or am I completely off base here?
Nope, what you said made perfect sense, you were just missing some pieces.
I should mention that for Android 6.0 the Compliance Definition Document (which specifies what it means to be Android) makes all of the TEE stuff "strongly recommended", but not "mandatory" for Marshmallow devices. However, it is all mandatory for devices that have fingerprint readers. The CDD also warns that it will become mandatory for N. In spite of not being mandatory for Marshmallow, though, it looks like nearly all major device vendors will have the new TEE stuff in their new devices (those launching with Marshmallow).
Using a fingerprint for authentication is like using one unchangable password for every system. Bad practice!
Complete nonsense.
You're equating fingerprints with passwords. They're not passwords. Password security derives from the secrecy of the password. Anyone who knows the password can enter it, but we presume attackers can't enter it because they don't know it. Fingerprint security derives from the difficulty of presenting the known value to the sensor. Everyone knows your fingerprint (you leave them everywhere!), but we presume attackers can't enter it because they only have a picture of it, not a finger with it.
In practice, making fake fingers is not terribly hard. But shoulder-surfing PINs is even easier. Which is more secure? That depends on who you're trying to protect your data from. The FBI absolutely will make fake fingers and unlock your phone, but they may not have an opportunity to shoulder surf a PIN. Advantage: PIN. Your suspicious girlfriend probably won't make fake fingers, but has ample opportunity to shoulder surf you. Advantage: fingerprint.
Which is better for you? You decide.
In practice for most people the choice isn't between fingerprint or password, it's between fingerprint or nothing, because a password is just too inconvenient. Advantage: Fingerprint, by a very, very large margin.
eg. you boil image data down to bits that are repeatable in the face of repeated scans, like you check whether feature X is significantly more prevalent than feature Y in this print
But you can't check if feature X is significantly more prevalent than feature Y if all you have to compare against is a hash of the features. That's the point. And, no, you can't usefully hash the individual features independently because the sample space of each is too small. If there are only, say, 10 bits of entropy in the hash of each feature, you can brute force each of them independently and de-hash the template, so the hashing was useless.
However, hashing of fingerprint templates is pointless anyway. Salted hashing is a way to keep attackers who get the hashed secrets from being able to recover the original secrets. But fingerprints are not secrets.
They aren't some super secret thing you try to keep secret from everybody. You not just leak your DNA everywhere, you leak your fingerprints too. And unlike passwords, you can't just simply change them.
Correct. The security of fingerprints, like all biometrics, derives not from the secrecy of the data (because it's not secret, particularly not your fingerprints), but because of the difficulty of providing someone else's data to the sensor.
In an ideal world, with a sensor that is able to distinguish with 100% accuracy whether the finger (or whatever) it's being presented is real, live and attached to the person who is trying to authenticate, that would be really hard. In the real world, with the sensors on typical consumer devices, and in an unsupervised environment (i.e. no security guard watching to check that you aren't trying anything funny), it's really not very hard at all. Anyone who cares to can watch a YouTube video, spend $20 at the local hobby shop to get the materials, and spend a couple of hours turning an image of a fingerprint into a gummi finger which will fool most sensors. However, that doesn't mean it's worthless. It only means it's worthless against someone who is willing to do that.
Compare this to a more common mobile device authentication method: a four-digit PIN. It's rather easy to shoulder surf a four-digit PIN, especially with the assistance of smudges, and particularly if you're a friend or family member of the target. In practice, friends and family members are the most common unwanted intruders on mobile devices. Against a typical person, who isn't likely to mess around with lifting prints and manufacturing fake fingers, a fingerprint -- weak as it is in absolute terms -- is stronger than a PIN or Android pattern.
Even more important, many people find a PIN, pattern or password simply too cumbersome to use. Android's Smart Lock helps, by enabling the device to apply rules to determine when the device has probably not left your possession and to stay unlocked longer in those cases, but even that's too inconvenient for many. So that majority of mobile device users (on devices without FP scanners) don't use any lockscreen at all.
Having no lockscreen is far less secure than fingerprint authentication, in case anyone is unclear about that.
Thus, for people who would otherwise use no security, the extreme speed and convenience of a good fingerprint scanner makes it feasible to protect their devices. That's a big win for those people, even if someone messing with etching compounds and wood glue can get past it.
IMO, the biggest problem with the current crop of mobile fingerprint sensors isn't the devices, sensors or software, it's the users' perception of them as very high security. They're not. They're relatively weak, but highly convenient security. As long as people don't expect too much from them, they're awesome.
So, the bit about fingerprint template storage security is much ado about nothing. The new Android fingerprint subsystem (which I worked on) does a decent job. Templates are encrypted with keys that are inaccessible to the Android OS and kernel, and the matching of livescans against templates is likewise done where even a completely-compromised kernel can't alter or interfere. But that's actually not because templates are highly sensitive data. It's partly just good security hygiene and partly because the hardware-backed keystore can rely on fingerprint authentication to unlock secrets, and it doesn't make sense for it to simply trust the regular Android OS... since the reason that stuff is done in the secure context is so that compromises of the regular OS can't muck with it.
I wouldn't be surprised if you aren't even lying, you could be plausible deniability bait.
That would imply there's someone else behind the scenes, hidden from me and subverting my work. But there's simply no room for that to be true.
Which still wouldn't imply that I or many others believe you.
Sure, you can just believe that I'm lying. But that's only possible because you don't know me.
I mean, why wouldn't Google do this? Seems this design is coming out about the same time as more people are becoming savvy to the invasion of trackers, and maladware and are installing software to get around the practice.
There are many, many reasons why Google wouldn't want to. Included among them is the fact that both the founders and a large percentage of the employees would rebel for both moral and business reasons (though, honestly, the moral reasons are more important). Google has never been particularly comfortable with advertising. Larry and Sergey refused to do it for the first portion of Google's history, until they hit on the idea of using small, text-only ads that were relevant to the search terms and therefore might actually be of use to users.
Any group I was involved in, especially the one who is the biggest player in monetizing users internet habits, would want to preserve their cash cow, and work at ways to defeat the tracking
So how do you square that view of Google with the fact that the company provides users with tools to opt out of analytics and targeted advertising, and makes no attempt to defeat ad blockers, or even remove them from the Google-providedstores? Tracking users is useless if you can't show them ads (and don't sell user information to others, which Google doesn't do).
Seriously, Google does not want to track you without your permission. Google does want to offer you services that are so compelling that you think giving that permission is a good trade. But if you don't want to make that trade, you should be able to opt out, because tricking, coercing or screwing your customers is bad business. So Google will not only let you, but help you opt out, if that's what you want -- while still allowing you to use Google's services!
And "ethics" doesn't cut it as an excuse.
To decent people ethics is a reason, not an excuse. Which doesn't mean the company never does anything wrong; it's a big company these days, and people do screw up sometimes (e.g. StreetView Wifi, Safari settings workaround, Buzz auto-friending... and that's pretty much it.). But Google has learned from those screwups and is considerably more careful these days.
Oh, that reminds me of one really clear reason that Google wouldn't do this: The 20-year consent decree that Google signed with the Federal Trade Commission that includes regular external audits of Google's privacy practices, with big, sharp teeth via both direct fines and punishments and negative PR should Google ever fail.
Tracking you will be much more efficient. Built in, unblockable analytics.
No.
I work on the Android security team, and we actively block any attempt to build tracking into the core platform. It's not hard to do, either. Mostly what happens is that people design new features which they don't realize could be used for tracking, we point them out, and they say "Oh, right, guess I need to find another way."
Google doesn't really want to track you, except as voluntary quid-pro-quo for using some service you value.
Large tech companies -- including Google -- have exited countries before over repressive laws; The "someone will build it" argument therefore rings hollow.
You think Samsung, LG, HTC, etc. would refuse to sell devices in the UK if Google didn't provide what was required? I think you're forgetting that Android is open source.
The search engine, maps and other services are not, however.
And all are easily replaced with competitor's products. I suppose if Google could arrange a pact with Microsoft, it would at least take a little time for replacements to spring up. Given Microsoft's history and philosophy, though, I don't think they'd play ball.
I should also point out that all of the people who believe that they can divorce themselves of responsibility for the results of their actions just because they themselves didn't directly cause the outcome is an even bigger source of making the world a worse place. Truly ethical people consider all of the ramifications of their options, rather than just washing their hands and telling the world that they didn't do the bad thing.
Slashdot Mirror
Microsoft is just following the lead of Google and Apple by making it impossible to comply with such requests.
What have Google and Apple done to make it impossible to comply with legal requests?
1. It's extraordinarily difficult to create a fingerprint spoof from a latent print. Yes, there are people who can do it - I can do it - but it's not easy. Notice on the videos of breaking into the iPhone 5s or 6 that latent prints are taken from a single fingerprint placed carefully on a squeaky clean screen. On your average phone, not so much. Someone who picks up my phone off the seat in a subway will be incapable of breaking in - unless I've just cleaned the screen with windex and carefully placed my fingerprint on it.
This is not true, unfortunately. It is true that most devices will have a set of partial prints on them, but it's not actually that difficult to assemble them into a whole print, especially if you're okay with making a whole batch of gummi fingers. You simply apply feature extraction to the partial prints, match up common features across the partials and generate a set of candidate full prints. Doing this requires some software knowledge, but not really that much. I expect to see open source libraries that do it, soon. Once you have your set of candidates, use a high-resolution 3D printer to generate a set of molds, cast your gummi fingers, and try them.
However, this still doesn't mean they're ineffective. They're less secure than a decent password, yes, but that's far from useless.
Fingerprints, in fact all biometrics, are not passwords -- they are usernames.
This is completely wrong. Biometrics are neither usernames nor passwords. They have fundamentally different security properties from both. See http://it.slashdot.org/comment...
Unless you are protecting the nuclear launch codes (google 00000000), the device realizing whether or not your finger is still alive and attached to you doesn't matter. For anything other than those launch codes, your finger is worth more than your device.
Liveness matters mostly because liveness seems to be the easiest way to validate "realness". All of the best up-and-coming technologies for detecting fake fingers focus on detecting liveness.
You didn't read my post. Rotation is irrelevant to biometric security.
The problem is, the fingerprint is already on the scanner, so there's probably a way to do it with a lot less effort. We just don't know what it is yet.
Meh.
This isn't new technology, and people have been playing with breaking it for quite a long time. It's always possible that someone will come up with a brilliant and dramatically-easier way -- but, really, the gummi finger is pretty darned easy, so the bar for better breaks is high (or low, depending on your perspective) -- but it seems unlikely. And if it does, it will just revise the scaling a bit, not fundamentally change the analysis.
I wish I wasn't an AC here, but dang it, I felt the need to respond.
It means that biometrics should be the username, not the password.
No. This is just as wrong as viewing a fingerprint as a password. Biometrics make lousy identifiers.
What? They make fine identifiers, when compared to the other option, entering your user name or id into a box. It's perfectly fine to view some biometric data as user identification.
Nope. You're wrong.
The birthday paradox is deadly to biometric identification on large-scale systems. It's okay on small systems with relatively few users, but scale it up and it simply doesn't work unless (as many systems do) you also apply some other disambiguating information, like a phone number or an identifier of some sort or statistical modeling to narrow the set of likely candidate templates. Well, unless you're okay with lots of false positives. Put 50K people in one system and identify them by fingerprint only, and virtually anyone who walks up will be identified as someone, and many people in the system will frequently get identified as someone else.
It's not fine to view that same data as authentication, simply because it doesn't prove the user is who he claims to be. The biometric data says "this is who I claim to be", something else needs to be there to say "and this is how I can prove it".
Nope. Assuming you already have a claim of identity (i.e. a username), a biometric provides a decent proof of that identity. How strong that proof is depends on the context and the procedures. For an extreme example (from a system I actually built), if there's an armed guard examining your finger for evidence of fakery, then it's actually very strong. On a mobile device, not so much, but it's still useful. See the other post I linked.
No, I'm not. I'm comparing the usage of both in relation to the level of security they offer. Totally different.
No, you're not comparing security levels, because you're talking about rotation and authenticator secrecy. Both of those concepts are completely irrelevant to biometric security, which means that you're completely misunderstanding how biometric security works, and also the ways in which it doesn't work. Please read my post; it offers an accurate assessment of relative security levels, with a correct understanding of the processes and security models underlying both.
You can do this with any rooted android device and tasker.
No, it would require changes to the system, because the fingerprint subsystem doesn't expose the finger ID to the framework. The HAL API reports the finger ID to fingerprintd, but that doesn't report it further up the call stack.
So you'd to modify fingerprintd to return the finger ID, change the Binder API between fingerprintd and the framework, and modify the framework to report it as well. Or I suppose you could hack fingerprintd to write the last-authenticated FP ID to a file and then allow apps that want to know which finger was used to read it. That would involve poking a few other holes in the security architecture, but would be the easy brute force way.
And the first thing anyone who cares about security does with an Android device is root it and install their own ROM that is free of carrier encumberances and spyware.
Or just buys a Nexus device and (optionally) refuses the various questions asked during setup about providing data to Google.
BTW, be very careful with rooting, and I recommend absolutely refusing any rooting solution that involves disabling SELinux. It's up to you, but poking large holes in the security model does significantly damage your device security.
Any device that can perform different actions based on different finger prints?
None are on the market that I'm aware of. iOS and Android both intentionally avoid distinguishing between different enrolled fingers, because the average user would find it very confusing. I don't know if Microsoft has done the same for Windows phone, but if they haven't they were remiss in their user testing, or they'd have discovered the same issue.
It seems likely that some future alternative Android ROMs will provide this feature.
Problem is, at some point, there's an interface between the hardware and the software, and I have access to the software, and can rewrite it to always get a positive from the hardware
If you have physical access to the hardware and the software then NO authentication is effective. There is no such thing as a secure device in hostile hands.
In an absolute sense, this is true. But in practice it's false.
There are many different degrees of capability among attackers. Your kid sister will be defeated by just about anything. The NSA can penetrate virtually anything. In between, there are lots of gradations, and it is useful to deploy various levels of countermeasures that make the more important on-device secrets harder to access.
On hashing, it really doesn't matter, even if it is feasible. And if it were, it would have been done.
And I would say fingerprints are secrets to some extent.
When thinking about security, you should assume they're public knowledge. If they happen to be less available than that, then you're in better shape than you thought. But given that they're not rotatable and are left everywhere, no good security design should be based on the premise that fingerprints are secret.
I agree, but would point out that using a fingerprint to unlock a strong key on a phone, then using that to authenticate to a remote server is quite strong.
It means that biometrics should be the username, not the password.
No. This is just as wrong as viewing a fingerprint as a password. Biometrics make lousy identifiers. You still need to use a username when authenticating with a biometric. Biometrics work fine as authenticators but they work completely differently from passwords.
I went into detail here.
I don't understand one thing. You mention that the matching of livescans against templates is done in an area which can't be altered or interfered with. And yet, at some point that hardware (I'm assuming it's all hardware) must send a positive signal to the software that it's OK to unlock the screen.
Yup.
Surely I could compromise the code that accepts that signal to simply always be a positive signal?
Certainly... except for other code running in the area which can't be altered or interfered with.
This is the reason that Android 6.0's fingerprint matching is required to be done in the Trusted Execution Environment (TEE), because that matching signal is used not just by the regular OS to unlock your screen, but also by other code in the TEE to unlock access to cryptographic keys which are presumably used to protect the most important stuff on your phone.
For example, using the new features in Android Marshmallow's hardware-backed keystore (especially this one, your bank's app could set up an ECDSA signing key that is used to authenticate to their servers, providing access to your banking information. That key could be configured to be unlocked by your fingerprint. If the fingerprint matching were provided in the regular OS then any compromise of the regular OS would enable access to your bank account, because the TEE-based ECDSA key would be relying on a signal from the regular OS to tell it to unlock the key. But because the TEE-based ECDSA key relies on a signal from the TEE-based fingerprint matcher, a compromise of the regular OS won't get the attacker in to your bank account (not unless you're around to put your finger on the scanner).
FYI, for Marshmallow the password authentication has also been moved into the TEE, and TEE-based keys can also be access controlled with password auth. So your bank could do the same sort of thing, but require you to enter your device password rather than present a fingerprint.
Or am I completely off base here?
Nope, what you said made perfect sense, you were just missing some pieces.
I should mention that for Android 6.0 the Compliance Definition Document (which specifies what it means to be Android) makes all of the TEE stuff "strongly recommended", but not "mandatory" for Marshmallow devices. However, it is all mandatory for devices that have fingerprint readers. The CDD also warns that it will become mandatory for N. In spite of not being mandatory for Marshmallow, though, it looks like nearly all major device vendors will have the new TEE stuff in their new devices (those launching with Marshmallow).
Using a fingerprint for authentication is like using one unchangable password for every system. Bad practice!
Complete nonsense.
You're equating fingerprints with passwords. They're not passwords. Password security derives from the secrecy of the password. Anyone who knows the password can enter it, but we presume attackers can't enter it because they don't know it. Fingerprint security derives from the difficulty of presenting the known value to the sensor. Everyone knows your fingerprint (you leave them everywhere!), but we presume attackers can't enter it because they only have a picture of it, not a finger with it.
In practice, making fake fingers is not terribly hard. But shoulder-surfing PINs is even easier. Which is more secure? That depends on who you're trying to protect your data from. The FBI absolutely will make fake fingers and unlock your phone, but they may not have an opportunity to shoulder surf a PIN. Advantage: PIN. Your suspicious girlfriend probably won't make fake fingers, but has ample opportunity to shoulder surf you. Advantage: fingerprint.
Which is better for you? You decide.
In practice for most people the choice isn't between fingerprint or password, it's between fingerprint or nothing, because a password is just too inconvenient. Advantage: Fingerprint, by a very, very large margin.
eg. you boil image data down to bits that are repeatable in the face of repeated scans, like you check whether feature X is significantly more prevalent than feature Y in this print
But you can't check if feature X is significantly more prevalent than feature Y if all you have to compare against is a hash of the features. That's the point. And, no, you can't usefully hash the individual features independently because the sample space of each is too small. If there are only, say, 10 bits of entropy in the hash of each feature, you can brute force each of them independently and de-hash the template, so the hashing was useless.
However, hashing of fingerprint templates is pointless anyway. Salted hashing is a way to keep attackers who get the hashed secrets from being able to recover the original secrets. But fingerprints are not secrets.
They aren't some super secret thing you try to keep secret from everybody. You not just leak your DNA everywhere, you leak your fingerprints too. And unlike passwords, you can't just simply change them.
Correct. The security of fingerprints, like all biometrics, derives not from the secrecy of the data (because it's not secret, particularly not your fingerprints), but because of the difficulty of providing someone else's data to the sensor.
In an ideal world, with a sensor that is able to distinguish with 100% accuracy whether the finger (or whatever) it's being presented is real, live and attached to the person who is trying to authenticate, that would be really hard. In the real world, with the sensors on typical consumer devices, and in an unsupervised environment (i.e. no security guard watching to check that you aren't trying anything funny), it's really not very hard at all. Anyone who cares to can watch a YouTube video, spend $20 at the local hobby shop to get the materials, and spend a couple of hours turning an image of a fingerprint into a gummi finger which will fool most sensors. However, that doesn't mean it's worthless. It only means it's worthless against someone who is willing to do that.
Compare this to a more common mobile device authentication method: a four-digit PIN. It's rather easy to shoulder surf a four-digit PIN, especially with the assistance of smudges, and particularly if you're a friend or family member of the target. In practice, friends and family members are the most common unwanted intruders on mobile devices. Against a typical person, who isn't likely to mess around with lifting prints and manufacturing fake fingers, a fingerprint -- weak as it is in absolute terms -- is stronger than a PIN or Android pattern.
Even more important, many people find a PIN, pattern or password simply too cumbersome to use. Android's Smart Lock helps, by enabling the device to apply rules to determine when the device has probably not left your possession and to stay unlocked longer in those cases, but even that's too inconvenient for many. So that majority of mobile device users (on devices without FP scanners) don't use any lockscreen at all.
Having no lockscreen is far less secure than fingerprint authentication, in case anyone is unclear about that.
Thus, for people who would otherwise use no security, the extreme speed and convenience of a good fingerprint scanner makes it feasible to protect their devices. That's a big win for those people, even if someone messing with etching compounds and wood glue can get past it.
IMO, the biggest problem with the current crop of mobile fingerprint sensors isn't the devices, sensors or software, it's the users' perception of them as very high security. They're not. They're relatively weak, but highly convenient security. As long as people don't expect too much from them, they're awesome.
So, the bit about fingerprint template storage security is much ado about nothing. The new Android fingerprint subsystem (which I worked on) does a decent job. Templates are encrypted with keys that are inaccessible to the Android OS and kernel, and the matching of livescans against templates is likewise done where even a completely-compromised kernel can't alter or interfere. But that's actually not because templates are highly sensitive data. It's partly just good security hygiene and partly because the hardware-backed keystore can rely on fingerprint authentication to unlock secrets, and it doesn't make sense for it to simply trust the regular Android OS... since the reason that stuff is done in the secure context is so that compromises of the regular OS can't muck with it.
I wouldn't be surprised if you aren't even lying, you could be plausible deniability bait.
That would imply there's someone else behind the scenes, hidden from me and subverting my work. But there's simply no room for that to be true.
Which still wouldn't imply that I or many others believe you.
Sure, you can just believe that I'm lying. But that's only possible because you don't know me.
I mean, why wouldn't Google do this? Seems this design is coming out about the same time as more people are becoming savvy to the invasion of trackers, and maladware and are installing software to get around the practice.
There are many, many reasons why Google wouldn't want to. Included among them is the fact that both the founders and a large percentage of the employees would rebel for both moral and business reasons (though, honestly, the moral reasons are more important). Google has never been particularly comfortable with advertising. Larry and Sergey refused to do it for the first portion of Google's history, until they hit on the idea of using small, text-only ads that were relevant to the search terms and therefore might actually be of use to users.
Any group I was involved in, especially the one who is the biggest player in monetizing users internet habits, would want to preserve their cash cow, and work at ways to defeat the tracking
So how do you square that view of Google with the fact that the company provides users with tools to opt out of analytics and targeted advertising, and makes no attempt to defeat ad blockers, or even remove them from the Google-provided stores? Tracking users is useless if you can't show them ads (and don't sell user information to others, which Google doesn't do).
Seriously, Google does not want to track you without your permission. Google does want to offer you services that are so compelling that you think giving that permission is a good trade. But if you don't want to make that trade, you should be able to opt out, because tricking, coercing or screwing your customers is bad business. So Google will not only let you, but help you opt out, if that's what you want -- while still allowing you to use Google's services!
And "ethics" doesn't cut it as an excuse.
To decent people ethics is a reason, not an excuse. Which doesn't mean the company never does anything wrong; it's a big company these days, and people do screw up sometimes (e.g. StreetView Wifi, Safari settings workaround, Buzz auto-friending... and that's pretty much it.). But Google has learned from those screwups and is considerably more careful these days.
Oh, that reminds me of one really clear reason that Google wouldn't do this: The 20-year consent decree that Google signed with the Federal Trade Commission that includes regular external audits of Google's privacy practices, with big, sharp teeth via both direct fines and punishments and negative PR should Google ever fail.
I wouldn't be surprised if you aren't even lying, you could be plausible deniability bait.
That would imply there's someone else behind the scenes, hidden from me and subverting my work. But there's simply no room for that to be true.
Tracking you will be much more efficient. Built in, unblockable analytics.
No.
I work on the Android security team, and we actively block any attempt to build tracking into the core platform. It's not hard to do, either. Mostly what happens is that people design new features which they don't realize could be used for tracking, we point them out, and they say "Oh, right, guess I need to find another way."
Google doesn't really want to track you, except as voluntary quid-pro-quo for using some service you value.
Large tech companies -- including Google -- have exited countries before over repressive laws; The "someone will build it" argument therefore rings hollow.
You think Samsung, LG, HTC, etc. would refuse to sell devices in the UK if Google didn't provide what was required? I think you're forgetting that Android is open source.
The search engine, maps and other services are not, however.
And all are easily replaced with competitor's products. I suppose if Google could arrange a pact with Microsoft, it would at least take a little time for replacements to spring up. Given Microsoft's history and philosophy, though, I don't think they'd play ball.
Hit send too soon.
I should also point out that all of the people who believe that they can divorce themselves of responsibility for the results of their actions just because they themselves didn't directly cause the outcome is an even bigger source of making the world a worse place. Truly ethical people consider all of the ramifications of their options, rather than just washing their hands and telling the world that they didn't do the bad thing.
So, you can't actually counter my argument, and instead have to fall back on generalities and platitudes.
BTW: http://www.appy-geek.com/Web/A...
"Must have features GPS, bluetooth and music storage for roughly 5 hours of use during a marathon. Pretty much everything else is a nice to have."
Nobody else found funny that for a sport watch a clock/chronograph is not among the "must haves"? And it supposedly is a "smart" one!
It's kind of implied. If you have a GPS receiver, you have a clock.