Pls shed more light on this…
Are you saying online transactions should be done without PIN?
Validation by CVV?
This (PINs on online transactions using Chip & PIN cards) does not happen anywhere else outside Nigeria. Okay, maybe it’s allowed in some other unscrupulous country I don’t know of atm.
The CVV is validated by the card network and not meant to be stored either. How about recurring transactions? You may ask. They are meant to be CVV-less. The presence of a CVV while attempting to charge a card is stating that the cardholder is at that point in time entering their card details and authorizing the transaction.
Not exactly correct. In the U.K, there have been instances in the past where PIN was required for online transactions, but this has been largely phased out.
For instance if you had a current account in Lloyds, for every online purchase, they re-directed you to their portal to enter the verifications details before transactions are completed. They phased that out a long time ago. However, the recent one they’ve also recently phased out is PIN/token verification for Business account. Before you had to use the token and a pin card reader to sign in, set up a new recipients for transfers and to do the actual transfers. It was basically hardcore, cumbersome but more importantly and relevant in this context - secured.
But guess what ? Lloyds scrapped the PIN/token stuff because customers hated it. Other banks like Barclays also reduced dependance on token. Not because it was any less secure (although there was all that RSA hack scandal some years ago), it’s more of a usability issue. The good thing is customers are also protected when fraudulent misuse occurs. I think that’s the main difference between what happens elsewhere compared to Nigeria. At the end of the day, no system is completely secured & not everyone can take drastic actions like @techscorpion but super important that customers are reimbursed smoothly and quickly when frauds occurs.
So, I was very specific.
Broadly, there are three types of cards.
- Mag stripe only (largely phased out - still used by many American card holders. PINs used for cash withdrawal and are verified over the network, presumably stored in the bank)
- Chip and Signature (looks exactly like Chip and PIN, but doesn’t contain a secure area with an encrypted PIN block - PINs are stored in the bank)
- Chip and PIN (the variants we switched to in Nigeria over 5 years back. Contains encrypted PIN block)
Your example of Lloyds using a token and hardware PIN card reader was a way to verify the PINs the way they would at an ATM - inside a specialized reader that can verify the PIN entered offline. It wasn’t actually being transmitted over the network.
2 Likes
I still use the PIN and hardware token combination. I’m actually quite surprised that some people didn’t like it.
Going back to the “PIN shouldn’t be stored outside the card” idiom, I’ll be more specific and say, the PIN should never exist outside the trust relationship between who owns the private key (ie. the card) and who has been given possession of the public key i.e the secure PIN pad, or the issuer’s Hardware Secure Module (HSM) which is essentially an array of smart card micro controllers.
The EMV spec is quite complex, and allows card issuers to specify a list of allowable Cardholder Verification methods, which include “Offline PIN verification”, “Online PIN verification”, and even “Signature only”.
With the former, a Secure Pin Pad (on the ATM or terminal) uses the card’s public key to encrypt the PIN, transmits it to the card, which decrypts it with its private key, and confirms the PIN.
With the latter, and this part is very important, the card uses its private key to create a cryptogram that contains all the details of the transaction. All that information is sent to the issuer’s HSM who uses the issuer key to verify that the cryptogram came from the card, before authorising the transaction. The verification at the issuer is done with keys that are stored in the HSM, not SQL databases.
The spec is careful to ensure that the trust relationship between card and issuer is never broken. At no point should a 3rd party such as a merchant or an acquirer able to access or store the PIN. Quickteller (and anybody else that accepts a PIN on the web or a mobile keypad) breaks the model because they accept the PIN through a non-secure PIN pad, and do not encrypt it with the card’s private key before transmitting it to the issuer. EMV only allows for online PIN verification when it originates from the card through a cryptogram. Anything else is wrong. That said, if I’ve misunderstood the principles, I’ll be happy to be proven wrong.
A friend of mine woke up one morning to learn that his account was drained with his card at 2am, even though the card never left his side. ATM fraud is huge and underreported in Nigeria. Coupled with a banking industry that’s home to sharks, I’ll err on the side of extreme caution.
2 Likes
Boss, I thought you broke your card. 
Not quite boss. I broke my Nigerian card. I still have a very secure UK one and a pitifully insecure US one but at least they aren’t making any pretences. 
I literally setup my PIN by dictating it over the phone to an IVR while activating one of my US cards. I was mind blown for a bit then read up to update my knowledgebase on the whole EMV matter.
The US is an enigma. On one hand, their megacorps (Visa and Mastercard) are pioneering “Chip and Pin” around the world, and on the other, their home base is stuck with stone age payment technology.
I’ll be the first to admit that I’m a bit of an old curmudgeon when it comes to electronic money security issues. I believe we need to strike a balance between security and flexibility. The specs act as our arbiter and when the people we trust break them, it makes you wonder what other holes are there…
Sidebar:
Any ETA on enabling multi-party beneficiaries in PayStack transactions?
This keeps me up at night re: Nigerian banks, my good friend.
I won’t lie. None yet. Sometime in Q3 fine? If we can squeeze it in sooner, I will let you know. It is quite interesting how wanted this feature is, but then I get the idea.
Good one @xolubi see your point.
Well this is what happens when convenience trumps security.
This thread is really informative, but frightening.
If i ever have a million naira in my account, i’ll break my atm card, burn it, divide its ashes into two parts…i’ll blow one part into the air in Lagos and i’ll blow the other part into the air in Kaduna.
Can’t take any chances.
5 Likes
Which means if you ever have 5 Million in your Account, you will have your brain wiped so that you wont remember your Account Details. #PunIntended. 
Some Ibadan startup founders have up to 5 million naira in their account?
bruhhh!!! na wa.
I think that in stating your case, you missed out the most important danger of using biometrics for authentication, the fact that stolen biometric data cannot be replaced. One can easily change a compromised PIN or reset a stolen password, but what would be the solution to stolen biometric information? Growing new fingerprints, perhaps.
8 Likes
Spent some months on a national card project and this was the biggest challenge to using biometrics. If your prints was compromised, how do you re-secure it? Include a PIN, challenge response or password? That opened up a rabbit hole and devolved pretty quickly.
1 Like
I’ll weigh in.
First of all, you don’t want to store the prints, or at the very least, you treat it like full credit card number i.e. you tokenize it. However, what you really want is the minutiae. You want to take the highest quality scan, grab as many minutiae as possible, then you encrypt it, and store it in a hash bucket.
Secondly, you don’t want to to create a direct relationship between the profile and its minutiae set. You can do this by:
- Creating two buckets - one for hashed profiles, and the other for encrypted biometrics.
- Choosing a small enough bucket size of say 1000. For Nigeria’s population of 180mln, that gives you 180,000 buckets and 1000! = 4.02 x 102567 possible mappings, which is computationally infeasible for a brute force hack.
- Storing the encrypted minutiae with a nonce.
What does it achieve? If your database ever gets compromised, the attacker cannot draw any inference between a profile (because it is one-way hashed) and its biometrics, and any brute force attack is infeasible. To cover all bases, the nonce can be revoked thereby rendering any compromised minutiae unusable for authentication.
Ehh, so is @techscorpion still coming on this thread?
3 Likes
I can’t say I really understand anything after this quote, its 12:30pm and I’m woolly headed already, long day.
But this [quote=“niyi, post:39, topic:5355”]
First of all, you don’t want to store the prints, or at the very least, you treat it like full credit card number i.e. you tokenize it. However, what you really want is the minutiae. You want to take the highest quality scan, grab as many minutiae as possible, then you encrypt it, and store it in a hash bucket.
[/quote]
presents another operational challenge, that been having the same quality of minutiae when matching. For 1-to-1 matches like in the airport example somewhere above, no wahala. You can just keep going until you get a good enough minutiae that generates the same encrypted value as the original captured. but in a 1-to-many scenario and in the wild where scanners are shit, then you’d have the ‘You’re not you’ problem, which is a bummer.
No serious human being wants to use biometrics on a large scale for 1-to-many matching, if you hear someone pushing biometrics on the news for any large scale effort, chances are they just want to steal public funds.