Factors in authentication(apenwarr.ca)
apenwarr.ca
Factors in authentication
https://apenwarr.ca/log/20190114
11 comments
That's the only real advantage of "chip"
cards: they can't be trivially copied.
(The switch from signatures to PINs is
mostly a distraction and adds little.)
That's not true in the US, anymore. You can just hit enter when prompted for a PIN, and everything proceeds as if you provided the correct PIN. Try it out next time you go shopping!
I wish I could find the news story that alerted me to the fact that every major processor was making this change in the US, but I can't seem to now. Still, it's easy enough to test for yourself.
I wish I could find the news story that alerted me to the fact that every major processor was making this change in the US, but I can't seem to now. Still, it's easy enough to test for yourself.
Yeah, I realized that recently as well. Apparently when they first rolled out the chip readers, people complained that the authentication took too long (5-15 seconds), so now all you have to do is stick the card in the chip reader, no PIN required (in most stores at least). Brilliant! Consumer behavior effectively turned the chip back into the old mag-stripe system.
Chips are better than magstripes. PINs versus signatures is orthogonal. From the original article:
"Even ancient magstripe credit cards share most of these advantages. Their main weakness is that a physical attacker can clone rather than steal your card, which is much harder to detect. That's the only real advantage of chip cards: they can't be trivially copied."
When you think about it, having to physically possess a card (and being able to disable a card when you realize you've lost it) provides 99% of the security benefit.
"Even ancient magstripe credit cards share most of these advantages. Their main weakness is that a physical attacker can clone rather than steal your card, which is much harder to detect. That's the only real advantage of chip cards: they can't be trivially copied."
When you think about it, having to physically possess a card (and being able to disable a card when you realize you've lost it) provides 99% of the security benefit.
I was always under the impression that the microprocessor on the chip should not allow a payment to be processed without the correct PIN. Apparently, based on the behaviour you described, my assumption is very wrong and the authorization is not made offline on the card itself.
The standard allows for both options (and that switchability has led to security holes in the past[1]). Nowadays I think most of them validate the PIN on the server side rather than on the chip, which is better in some ways.
[1] https://apenwarr.ca/log/20110222
[1] https://apenwarr.ca/log/20110222
Author does a good job in separating authentication and enrollment.
Especially that not all authentication factor are equal and the mobile phones are getting it right is on point.
(shameless plug, i'm the CEO, as ubiqu we have build al the tooling necessary to use your phone as a authentication and signing device across all digital channels)
TL/DR: phone as an authentication device is a good idea.
Especially that not all authentication factor are equal and the mobile phones are getting it right is on point.
(shameless plug, i'm the CEO, as ubiqu we have build al the tooling necessary to use your phone as a authentication and signing device across all digital channels)
TL/DR: phone as an authentication device is a good idea.
Until you get a new phone and codes don't sync and backup codes don't work.
Responding to your shameless plug, I work on this stuff (auth and enrollment for the security token), would love to chat if you have time!
This article does not get off to a promising start. It begins right off by mixing in completely orthogonal concepts, like privacy. It then has a random unsubstantiated and unsupported side swipe at a single specific semi-obscure joint US-Canada program with some conspiracy mixed in. Author then screws up how false positives/negatives work in the context of authentication, perhaps partly because their mind has already jumped the tracks here and switched to some panopticon thing rather then, you know, authentication. Author writes:
>"If you have a giant database of fingerprints or retinas or DNA samples or voiceprints or faces, and you have an algorithm for searching the database, and you have one sample you want to look up in the database to find the right match"
Sure that'd be the case for mass surveillance, but not for auth, be it on a phone or in the NEXUS program author cites. The individual is registered (in person) in the database and are asking that they, specifically, be authenticated, and obviously their biometrics are linked with their other info (like name). It's not "we see some random person, try to find them in the db" it's "This person states that they are John Doe, and are asking to be authenticated as such by presenting the following factors", so their specific entry is being pulled up and the factors compared just to that, which generates a result of some level of confidence which either meets the target threshold or fails. False positive would be somebody who isn't John Doe being successfully authenticated as John Doe, and false negative would be the real John Doe failing to be authenticated as John Doe. More factors, higher quality of individual factors, and more powerful comparison systems can raise the confidence level. Better ones do so at a more efficient time&cost ratio for the defender vs attackers.
There is some interesting stuff in this, and it touches on the important enrollment problem, but it also seems like a lot of unrelated tangents and wild goose chases mixed in. There also seems to be repeated instances of the classic screw up so common in security discussions (like those who cite that garbage xkcd) of failing to always remember that all security is an economic equation. Always have to keep that in mind or one can naturally fall down an endless hole and completely forget what the point of it all is.
>"If you have a giant database of fingerprints or retinas or DNA samples or voiceprints or faces, and you have an algorithm for searching the database, and you have one sample you want to look up in the database to find the right match"
Sure that'd be the case for mass surveillance, but not for auth, be it on a phone or in the NEXUS program author cites. The individual is registered (in person) in the database and are asking that they, specifically, be authenticated, and obviously their biometrics are linked with their other info (like name). It's not "we see some random person, try to find them in the db" it's "This person states that they are John Doe, and are asking to be authenticated as such by presenting the following factors", so their specific entry is being pulled up and the factors compared just to that, which generates a result of some level of confidence which either meets the target threshold or fails. False positive would be somebody who isn't John Doe being successfully authenticated as John Doe, and false negative would be the real John Doe failing to be authenticated as John Doe. More factors, higher quality of individual factors, and more powerful comparison systems can raise the confidence level. Better ones do so at a more efficient time&cost ratio for the defender vs attackers.
There is some interesting stuff in this, and it touches on the important enrollment problem, but it also seems like a lot of unrelated tangents and wild goose chases mixed in. There also seems to be repeated instances of the classic screw up so common in security discussions (like those who cite that garbage xkcd) of failing to always remember that all security is an economic equation. Always have to keep that in mind or one can naturally fall down an endless hole and completely forget what the point of it all is.
The authentication part is "easy" because verifying possession of a private key is well understood, and there are various mature physical means of preventing the private key from being read directly. Stuff like on-board TPM's in phones and laptops, smartcards, and Yubikeys (and similar keys) all implement interfaces that can do encryption operations using the private key on the device so that the private key is hardware-protected. Of course, if you're an engineer working on said hardware protection, I'm sure this problem is anything but "easy," but from my perspective it's great that someone else has abstracted that problem for me!
Enrollment though... I lose sleep over enrollment. At any substantial scale, say, 10,000 users, how do you mitigate what a malicious insider in the enrollment process can do? How do you make sure the enrollment service is itself secure? You have to plan an entire operational playbook just for recovery because if your enrollment system goes down, worst case you lock everyone out. (Goes without saying that the system going down should not default-allow...) And everything you do to lock down the enrollment system is also something that slows down your ability to modify/update/repair the enrollment system. It's not impossible, but it's currently very tricky to get right.
I think U2F is one of the most user friendly approaches we've seen in a long time from a usability perspective that still maintains a relatively clean security model.