Lacking wings, the humans built the machines. Machines to take them around the world.
On wings of metal they soared. For work and for play. For reasons happy and sad. From one end to the other and back again.
But then, the humans got sick. And they did not soar anymore.
And so they wait. For the day to come when the humans will soar again.
Because the machines know, the humans will.
Wednesday, May 06, 2020
Sunday, April 17, 2016
EMV in the United States: Chip and Confusion
A little over a year ago, I wrote a post detailing the upcoming transition to EMV chip cards in the United States. Well now, six months after the October 1, 2015, liability shift that the media latched on to as "the day the US would start using EMV" (even though there were places where it could be used for at least a year prior), I've come to a conclusion on the current state of affairs. While many countries have "Chip and PIN", and a handful of other countries have "Chip and Signature", in the United States, we have "Chip and Confusion".
Before I get to far into this (seeing as my previous post worked out to be twelve pages long), I'll give my advice to ease the confusion up front: Don't overthink it. Whether you're a customer or a cashier, just do what the little screen says. If the screen says "insert", insert. If it doesn't, swipe. If it asks for a PIN, enter it. The other bit of advice I can give is that this confusion should be temporary. I've seen comments by people in other countries like Canada that already went through the transition to chip cards, and they indicate that there was confusion at first, but within a year or so people got used to dipping cards instead of swiping them.
I also made a flow chart of how the card payment process is currently working in the US. Without a chip card, things are fairly straight forward with not to many complications. But now, with the introduction of chip cards, sporadic merchant acceptance, and complications from debit cards, things are a lot more complicated.
So the biggest point of confusion for customers seems to be what they're supposed to do with the chip cards. Either they never use the chip, or they're never sure if they're supposed to use the chip or swipe, and seem to always do the wrong thing first. The crux of this problem is that while many places have chip readers, they don't all have the chip reader enabled. There are a variety of reasons for this, but for retailers with customer-facing terminals, it generally boils down to the software part isn't ready yet. Most of these retailers have point of sale systems that integrate payment handling with the rest of their systems, and so those systems need to be upgraded to support EMV transactions. Not only do the software changes have to be made, they also have to be certified, and there are backlogs in getting that completed.
I think most of that confusion can be avoided just by paying attention to the screen. With only a couple of exceptions that I've run into, if the screen says "insert", then the chip reader is enabled and I insert the card and the transaction is completed. If it doesn't, then I swipe. The more problematic case when this didn't work for me was at Vons, the brand used by Safeway in Southern California. There, I've run into terminals that say "swipe or insert", even though they don't have EMV enabled, and in one case I saw that prompt on a terminal that didn't have a card reader at all. What made this frustrating is that when I did insert, nothing happened. At another place where the terminal prompted to insert even though the chip reader didn't work, I got an error and was prompted to swipe, which is a more reasonable behavior since it at least instructs the customer what to do.
The other option would be to swipe first, then insert if prompted. This will work since a properly programmed EMV terminal will detect the card has a chip (there's a code included in the magnetic stripe that indicates this) and instruct the customer to insert the chip instead. The problem with doing this is that it exposes the customer to having the magnetic stripe on their card read and copied by a compromised terminal.
The second point of confusion seems to be signature versus PIN. Most US-issued cards are, at least for now, keeping things the same as they were before the arrival of EMV. Credit cards require a signature, while debit cards can either require a signature if run as "credit" or a PIN if run as "debit". The source of confusion seems to be primarily debit cards; I'll get to those in a moment.
Credit cards don't seem too bad; all of the major card issuers are issuing Chip and Signature cards so the customer is asked to sign in the vast majority of cases, just like they did with magnetic stripe credit cards, so there's not much change. Some do support PIN as well, for those places that can't handle a PIN. I haven't heard of any places like that in the US, though the PIN could be asked for at places like train ticket kiosks and self-service gas pumps in Europe. Barclaycard US does a good job of describing this on their web site:
One thing to keep in mind about the problem with Chip and PIN cards for merchants that aren't expecting them is that it's not limited to the handful of smaller banks issuing them. Visitors from many other countries will be using Chip and PIN cards. Before this wasn't an issue since when a Chip and PIN card was swiped in the US, it was treated just like an American card and the customer would be asked to sign. But as American merchants begin dipping these cards in the chip reader, the customer will be prompted to enter a PIN just as they would in their home country.
But the big problem is debit cards. US law requires that debit cards offer merchants the choice of routing transactions over at least two different unaffiliated networks. In practice, this commonly ended up giving the customer a choice of having their card processed as "credit" (signature) or "debit" (PIN), though there were exceptions. Restaurants typically would process only as credit to avoid the hassle of dealing with getting the customer's PIN, and some stores such as WinCo, Costco, and ARCO chose to keep costs down by accepting only (or primarily) debit cards.
Not only is this routing requirement unique to the US, it's compounded by the lack of a single national dominant debit processing network like Interac in Canada or EFTPOS in Australia and New Zealand. So it took a while for the industry to agree on a standard on how to get this to work with EMV, and as a result many of the first stores to implement EMV could only process EMV debit cards as "credit". This resulted in customers thinking their new EMV chip debit cards were less secure than their old magnetic-stripe only cards, since instead of being asked for a PIN, they were instead being asked to sign, or even do nothing at all since many retailers aren't required to collect a signature for small purchases. But now that retailers have EMV debit working, things have swung the other way. Some merchants, notably Kroger, have taken advantage of the switch to EMV and have taken away the "credit" or "debit" choice from customers using debit cards. While credit cards will be processed as they always have, debit cards at these merchants are now processed only as "debit" and a PIN is required. This is causing problems for a whole other set of customers who are used to selecting "credit" and signing with their debit cards, and either don't know or don't want to have to enter their PIN.
I don't want to dwell too much on yet another area of confusion, and that is knowing how to use card in the chip reader. Customers have gotten used to ATMs and self service machines where they insert the card into a reader, not unlike a chip reader, but instead of leaving it in the reader, they insert and remove it quickly in one motion. So the first time a customer attempts to use a chip reader, they may attempt the same thing, inserting and removing the card right away. However, the card needs to be left in the reader in order for the chip to do its thing, so this insert and remove motion doesn't work. Similarly, customers may not push the card all the way into the reader, even though they do leave it in. Fortunately, it seems like this is more of a problem of simply getting used to doing something different. I can imagine similar things happened (swiping too fast or too slow, or swiping the card such that the magnetic stripe doesn't even come in contact with the reader) when customers began swiping their own cards, rather than the cashier doing it.
So what do we have? Customers who don't know whether to dip or swipe. Cashiers who have never heard of credit card PINs. Customers not having the expected choice of "credit" or "debit" for debit cards. And very few people who even seem to know why these chip cards exist in the first place.
Or, to put it another way, Chip and Confusion.
Before I get to far into this (seeing as my previous post worked out to be twelve pages long), I'll give my advice to ease the confusion up front: Don't overthink it. Whether you're a customer or a cashier, just do what the little screen says. If the screen says "insert", insert. If it doesn't, swipe. If it asks for a PIN, enter it. The other bit of advice I can give is that this confusion should be temporary. I've seen comments by people in other countries like Canada that already went through the transition to chip cards, and they indicate that there was confusion at first, but within a year or so people got used to dipping cards instead of swiping them.
I also made a flow chart of how the card payment process is currently working in the US. Without a chip card, things are fairly straight forward with not to many complications. But now, with the introduction of chip cards, sporadic merchant acceptance, and complications from debit cards, things are a lot more complicated.
So the biggest point of confusion for customers seems to be what they're supposed to do with the chip cards. Either they never use the chip, or they're never sure if they're supposed to use the chip or swipe, and seem to always do the wrong thing first. The crux of this problem is that while many places have chip readers, they don't all have the chip reader enabled. There are a variety of reasons for this, but for retailers with customer-facing terminals, it generally boils down to the software part isn't ready yet. Most of these retailers have point of sale systems that integrate payment handling with the rest of their systems, and so those systems need to be upgraded to support EMV transactions. Not only do the software changes have to be made, they also have to be certified, and there are backlogs in getting that completed.
I think most of that confusion can be avoided just by paying attention to the screen. With only a couple of exceptions that I've run into, if the screen says "insert", then the chip reader is enabled and I insert the card and the transaction is completed. If it doesn't, then I swipe. The more problematic case when this didn't work for me was at Vons, the brand used by Safeway in Southern California. There, I've run into terminals that say "swipe or insert", even though they don't have EMV enabled, and in one case I saw that prompt on a terminal that didn't have a card reader at all. What made this frustrating is that when I did insert, nothing happened. At another place where the terminal prompted to insert even though the chip reader didn't work, I got an error and was prompted to swipe, which is a more reasonable behavior since it at least instructs the customer what to do.
The other option would be to swipe first, then insert if prompted. This will work since a properly programmed EMV terminal will detect the card has a chip (there's a code included in the magnetic stripe that indicates this) and instruct the customer to insert the chip instead. The problem with doing this is that it exposes the customer to having the magnetic stripe on their card read and copied by a compromised terminal.
The second point of confusion seems to be signature versus PIN. Most US-issued cards are, at least for now, keeping things the same as they were before the arrival of EMV. Credit cards require a signature, while debit cards can either require a signature if run as "credit" or a PIN if run as "debit". The source of confusion seems to be primarily debit cards; I'll get to those in a moment.
Credit cards don't seem too bad; all of the major card issuers are issuing Chip and Signature cards so the customer is asked to sign in the vast majority of cases, just like they did with magnetic stripe credit cards, so there's not much change. Some do support PIN as well, for those places that can't handle a PIN. I haven't heard of any places like that in the US, though the PIN could be asked for at places like train ticket kiosks and self-service gas pumps in Europe. Barclaycard US does a good job of describing this on their web site:
In most cases, you’ll then be prompted to sign for your transaction. But at self-service terminals like ticket kiosks and some gas pumps, you may need to enter your 4-digit PIN.A handful of US banks are issuing Chip and PIN cards, meaning that the card is configured to prefer PIN over signature. Ones I know of include Target's REDcard, Santander Bank, First Niagara Bank, United Nations Federal Credit Union, and First Tech Federal Credit Union. While I don't have any first-hand experience with them, their websites do emphasize that the customer should expect to be prompted for their PIN in most cases, such as this example from First Niagara:
First Niagara is committed to preventing fraud and fraud losses by requiring a PIN on most credit and debit card transactions performed in person. While some financial institutions are not requiring a PIN, we have taken this additional step to ensure our customer's card information is as secure as possible. If a PIN is not requested, you may be asked to sign a receipt, as you do today.It seems like the biggest point of confusion, or at least complication, related to this in the US comes from merchants not expecting Chip and PIN credit cards. I've heard reports of cashiers canceling the transaction when prompted for a PIN; presumably these merchants normally just process debit cards as "credit" so they aren't used to seeing a PIN prompt, and think "that's not right, we don't do debit". Chalk that up to poor training, since the right way to do this is to ask the customer to enter their PIN. The bigger problem is restaurants. As long as they continue with the model of the server taking the card away from the table to process the card in "the back", Chip and PIN cards will be quite a hassle since the customer will need to follow the server to enter their PIN. The right way to do this is to shift to "pay at the table" where the cashier brings a handheld portable credit card terminal to the table to allow the customer to pay, or use a tabletop kiosk. This has the additional advantages of removing the opportunity to have the card details copied while the card is out of the customer's sight, as well as the opportunity to fraudulently increase the amount of the tip after the customer has left the restaurant. Alternatively, restaurants could shift to the model of having customers pay at a cashier's station by the restaurant's exit, though I don't think many places will make this change as it tends to be associated more with lower-end, diner-type restaurants like Denny's.
One thing to keep in mind about the problem with Chip and PIN cards for merchants that aren't expecting them is that it's not limited to the handful of smaller banks issuing them. Visitors from many other countries will be using Chip and PIN cards. Before this wasn't an issue since when a Chip and PIN card was swiped in the US, it was treated just like an American card and the customer would be asked to sign. But as American merchants begin dipping these cards in the chip reader, the customer will be prompted to enter a PIN just as they would in their home country.
But the big problem is debit cards. US law requires that debit cards offer merchants the choice of routing transactions over at least two different unaffiliated networks. In practice, this commonly ended up giving the customer a choice of having their card processed as "credit" (signature) or "debit" (PIN), though there were exceptions. Restaurants typically would process only as credit to avoid the hassle of dealing with getting the customer's PIN, and some stores such as WinCo, Costco, and ARCO chose to keep costs down by accepting only (or primarily) debit cards.
Not only is this routing requirement unique to the US, it's compounded by the lack of a single national dominant debit processing network like Interac in Canada or EFTPOS in Australia and New Zealand. So it took a while for the industry to agree on a standard on how to get this to work with EMV, and as a result many of the first stores to implement EMV could only process EMV debit cards as "credit". This resulted in customers thinking their new EMV chip debit cards were less secure than their old magnetic-stripe only cards, since instead of being asked for a PIN, they were instead being asked to sign, or even do nothing at all since many retailers aren't required to collect a signature for small purchases. But now that retailers have EMV debit working, things have swung the other way. Some merchants, notably Kroger, have taken advantage of the switch to EMV and have taken away the "credit" or "debit" choice from customers using debit cards. While credit cards will be processed as they always have, debit cards at these merchants are now processed only as "debit" and a PIN is required. This is causing problems for a whole other set of customers who are used to selecting "credit" and signing with their debit cards, and either don't know or don't want to have to enter their PIN.
I don't want to dwell too much on yet another area of confusion, and that is knowing how to use card in the chip reader. Customers have gotten used to ATMs and self service machines where they insert the card into a reader, not unlike a chip reader, but instead of leaving it in the reader, they insert and remove it quickly in one motion. So the first time a customer attempts to use a chip reader, they may attempt the same thing, inserting and removing the card right away. However, the card needs to be left in the reader in order for the chip to do its thing, so this insert and remove motion doesn't work. Similarly, customers may not push the card all the way into the reader, even though they do leave it in. Fortunately, it seems like this is more of a problem of simply getting used to doing something different. I can imagine similar things happened (swiping too fast or too slow, or swiping the card such that the magnetic stripe doesn't even come in contact with the reader) when customers began swiping their own cards, rather than the cashier doing it.
So what do we have? Customers who don't know whether to dip or swipe. Cashiers who have never heard of credit card PINs. Customers not having the expected choice of "credit" or "debit" for debit cards. And very few people who even seem to know why these chip cards exist in the first place.
Or, to put it another way, Chip and Confusion.
Sunday, January 31, 2016
A Response to Cambridge's Video on Chip and PIN Fraud
Frequently, I see people referring to this video from Cambridge University explaining several Chip and PIN fraud possibilities as evidence that Chip and PIN is broken. I would like to take this opportunity to post my thoughts on this video and explain how, in the context of the current rollout of EMV in the United States, this isn't necessarily a huge deal.
The first thing to keep in mind is that, as I wrote previously, the United States is mostly transitioning to Chip and Signature, rather than Chip and PIN. Since my last post, a couple more banks and credit unions have come out with Chip and PIN credit cards, but the majority of EMV credit cards in the United States remain Chip and Signature, and one of the issuers that was Chip and PIN when I wrote that post has changed to Chip and Signature. Whether issuers transition to Chip and PIN in the US at some point in the future remains to be seen.
The attacks described in the video fall into three basic types, and I'll go over them one by one:
The first attack describes tampering with the card reader such that the flow of information in the link between the card reader and the card itself is intercepted, allowing someone to read off the card details and PIN. This certainly is a possible attack, but has been mitigated in a couple of ways. The first is to encrypt the PIN before sending it to the card. This means that the attacker wouldn't be able to read the PIN. The second is to have the PIN verified, not by the card itself, but by the bank that issued the card. This sort of over-the-network PIN verification is always encrypted, so the attacker would not have access to it. This is also how magnetic stripe debit card PINs in the US have been verified for many years. There are still cards and terminals out there that support unencrypted PIN verification by the card, so the attack possibility remains, but keep in mind that this still is only a disclosure of the PIN, and not the private keys on the card that would be needed to manufacture a clone of a chip card.
In the United States, this attack is mostly irrelevant. With nearly all US-issued cards being signature-preferring, if they support PIN at all, the PIN would rarely be needed by the customer and thus there is no PIN to capture. In the case of debit cards, which require a PIN when run as "debit" and may use a PIN when run as "credit", the PIN is always encrypted and sent over the network to be verified by the bank. It doesn't make sense to me for an attacker in the US to focus on PIN collection in this manner, since most transactions would not use a PIN in the first place so there would be nothing to capture.
The second attack uses a device between the card and the terminal that makes the terminal think the PIN was accepted by the card while the card thinks its doing a Chip and Signature transaction. This allows an attacker to use a stolen card without knowing the actual PIN, since the card thinks it's performing a signature transaction, while the intermediary chip returns a "correct PIN" response to the terminal in all cases. The problem is that there is nothing that verifies that the card and the terminal have the same view of the transaction. Fortunately, an improved method of authenticating that the card itself is legitimate, called "Combined Data Authentication" or "CDA", includes a way for the terminal or payment processing network to detect this inconsistency. As noted by SecurityWeek, CDA prevents this sort of attack.
Like the first attack, attack also doesn't seem to make much sense in the United States. With the majority of cards being issued as Chip and Signature instead of Chip and PIN, the attacker doesn't need to perform this attack to use a stolen card without knowing the PIN. Instead the attacker simply forges a signature on the receipt or PIN pad.
The third attack uses a terminal that displays a small transaction amount to the user while processing a large transaction amount. I don't really consider this a Chip and PIN attack at all, since I don't see why this attack couldn't be done with a magnetic stripe or Chip and Signature card. The solution here is to get a receipt, since the receipt would either show the large transaction amount and be immediately noticed by the cardholder, or the receipt would show the small transaction amount and thus would differ from the processed transaction amount, providing evidence that would allow the cardholder to more successfully dispute the transaction with their bank.
Ultimately, there's not a lot a cardholder can do to reduce the risk from these attacks. The first two aren't immediately relevant in the US since few US issuers are issuing Chip and PIN cards anyway. We can only hope that if they do start to, they take advantage of the latest enhancements to EMV technology, avoiding unencrypted PINs and using CDA. As for the third, that's really about good cardholder practices and doesn't have anything to do with Chip and PIN specifically.
The first thing to keep in mind is that, as I wrote previously, the United States is mostly transitioning to Chip and Signature, rather than Chip and PIN. Since my last post, a couple more banks and credit unions have come out with Chip and PIN credit cards, but the majority of EMV credit cards in the United States remain Chip and Signature, and one of the issuers that was Chip and PIN when I wrote that post has changed to Chip and Signature. Whether issuers transition to Chip and PIN in the US at some point in the future remains to be seen.
The attacks described in the video fall into three basic types, and I'll go over them one by one:
The first attack describes tampering with the card reader such that the flow of information in the link between the card reader and the card itself is intercepted, allowing someone to read off the card details and PIN. This certainly is a possible attack, but has been mitigated in a couple of ways. The first is to encrypt the PIN before sending it to the card. This means that the attacker wouldn't be able to read the PIN. The second is to have the PIN verified, not by the card itself, but by the bank that issued the card. This sort of over-the-network PIN verification is always encrypted, so the attacker would not have access to it. This is also how magnetic stripe debit card PINs in the US have been verified for many years. There are still cards and terminals out there that support unencrypted PIN verification by the card, so the attack possibility remains, but keep in mind that this still is only a disclosure of the PIN, and not the private keys on the card that would be needed to manufacture a clone of a chip card.
In the United States, this attack is mostly irrelevant. With nearly all US-issued cards being signature-preferring, if they support PIN at all, the PIN would rarely be needed by the customer and thus there is no PIN to capture. In the case of debit cards, which require a PIN when run as "debit" and may use a PIN when run as "credit", the PIN is always encrypted and sent over the network to be verified by the bank. It doesn't make sense to me for an attacker in the US to focus on PIN collection in this manner, since most transactions would not use a PIN in the first place so there would be nothing to capture.
The second attack uses a device between the card and the terminal that makes the terminal think the PIN was accepted by the card while the card thinks its doing a Chip and Signature transaction. This allows an attacker to use a stolen card without knowing the actual PIN, since the card thinks it's performing a signature transaction, while the intermediary chip returns a "correct PIN" response to the terminal in all cases. The problem is that there is nothing that verifies that the card and the terminal have the same view of the transaction. Fortunately, an improved method of authenticating that the card itself is legitimate, called "Combined Data Authentication" or "CDA", includes a way for the terminal or payment processing network to detect this inconsistency. As noted by SecurityWeek, CDA prevents this sort of attack.
Like the first attack, attack also doesn't seem to make much sense in the United States. With the majority of cards being issued as Chip and Signature instead of Chip and PIN, the attacker doesn't need to perform this attack to use a stolen card without knowing the PIN. Instead the attacker simply forges a signature on the receipt or PIN pad.
The third attack uses a terminal that displays a small transaction amount to the user while processing a large transaction amount. I don't really consider this a Chip and PIN attack at all, since I don't see why this attack couldn't be done with a magnetic stripe or Chip and Signature card. The solution here is to get a receipt, since the receipt would either show the large transaction amount and be immediately noticed by the cardholder, or the receipt would show the small transaction amount and thus would differ from the processed transaction amount, providing evidence that would allow the cardholder to more successfully dispute the transaction with their bank.
Ultimately, there's not a lot a cardholder can do to reduce the risk from these attacks. The first two aren't immediately relevant in the US since few US issuers are issuing Chip and PIN cards anyway. We can only hope that if they do start to, they take advantage of the latest enhancements to EMV technology, avoiding unencrypted PINs and using CDA. As for the third, that's really about good cardholder practices and doesn't have anything to do with Chip and PIN specifically.
Tuesday, January 05, 2016
Why Larry Ellison Doesn't Need Island Air Anymore
Let's travel back in time. All the way back to January 2013. Larry Elison, CEO of Oracle, had recently spent a bunch of money buying the island of Lanai and wanted to make sure visitors would still be able to get to the two Four Seasons hotels on the island. Island Air was in bad shape, with not a lot of money and Dash 8-100s that were running out of cycles and working on replacing them with worn out ex-American Eagle ATR 72s. While technically possible, jet service to the island had never been a fiscally sound thing to do (I remember Aloha advertising it at one point and Hawaiian ran a triangle route with load restricted DC-9s between Honolulu, Molokai, and Lanai) so Hawaiian 717s were unlikely to show up anytime soon. Mokulele's tiny 9-seat Cessna Caravans were likely the type of experience he wanted for the guests of his high end resorts.
So buying Island Air made some sense. The ATRs, while not a large jet, would at least provide the familiar experience of flying a regional airliner on the short interisland hop. Trying to position itself as the #2 airline probably didn't seem like a bad idea either after the failure of the much-loved Aloha and much-despised Go, a position in which Island Air pretty much was in whether they wanted it or not. A lower cost/lower fare turboprop alternative to the mainline jets had been tried before, but there was the potential to be more successful with just one big competitor (Hawaiian) rather than two (Aloha and Hawaiian). But Island Air was never seemingly able to shake the poor reputation they developed when they didn't have enough Dash 8s left to fly the schedule and once the ATRs arrived couldn't keep them flying either, resulting in delays and cancelled flights.
So Hawaiian smelled an opportunity. Go was gone, Island Air had a poor reputation, and Mokulele was too small to be relevant. They bought some ATR 42s from Europe, contracted Empire to fly them, and reentered the Molokai and Lanai markets they hadn't been able to viably serve since retiring the Dash 7. Almost immediately, freed from the obligation of providing the only regional airliner sized service to the island, Island Air dropped service to Molokai to focus on Ellison's Lanai. But with Island Air continuing to lose money and Hawaiian's ATRs not seemingly going anywhere and able to bring guests to the resorts, it makes sense for him to stop pouring money into the airline and let someone else figure out what to do with it.
So buying Island Air made some sense. The ATRs, while not a large jet, would at least provide the familiar experience of flying a regional airliner on the short interisland hop. Trying to position itself as the #2 airline probably didn't seem like a bad idea either after the failure of the much-loved Aloha and much-despised Go, a position in which Island Air pretty much was in whether they wanted it or not. A lower cost/lower fare turboprop alternative to the mainline jets had been tried before, but there was the potential to be more successful with just one big competitor (Hawaiian) rather than two (Aloha and Hawaiian). But Island Air was never seemingly able to shake the poor reputation they developed when they didn't have enough Dash 8s left to fly the schedule and once the ATRs arrived couldn't keep them flying either, resulting in delays and cancelled flights.
So Hawaiian smelled an opportunity. Go was gone, Island Air had a poor reputation, and Mokulele was too small to be relevant. They bought some ATR 42s from Europe, contracted Empire to fly them, and reentered the Molokai and Lanai markets they hadn't been able to viably serve since retiring the Dash 7. Almost immediately, freed from the obligation of providing the only regional airliner sized service to the island, Island Air dropped service to Molokai to focus on Ellison's Lanai. But with Island Air continuing to lose money and Hawaiian's ATRs not seemingly going anywhere and able to bring guests to the resorts, it makes sense for him to stop pouring money into the airline and let someone else figure out what to do with it.
Sunday, March 22, 2015
EMV in the United States: The Story So Far
A friend of my parents with his own business was asking them about chip cards and contactless. Since I've babbled on about it with them before (mostly as a result of my following the very long, ongoing US EMV Card thread on FlyerTalk), they ask if I could explain the difference. I realized I was writing quite a lot and figured I might as well post it on my blog.
The magnetic stripe credit cards we use today aren't very secure. The magnetic stripe doesn't change, so what criminals do is is get a device that copies the information off the magnetic stripe, and then writes that information onto another card. This process is called cloning. The name printed on the cloned card likely matches the criminal's ID (which is itself likely a fake ID), so that if a merchant asks for ID, the name printed on the card will match the name printed on the ID, and the photo on the ID will be a photo of the criminal himself, so everything will look good to the cashier (assuming they don't look too closely at the cardholder name printed on the receipt, which would come from the magnetic stripe data copied from the original card).
For one example of a credit card cloning setup, see these pictures of a fake New York City taxi, and note in the last one two credit card swipe machines, one real one to process the fare, and another one to read the magnetic stripe data off the card and store it to clone later.
Another easy way would be to target a waiter in a restaurant, since they often take credit cards away from the customer's table and swipe them somewhere out of customers' view, which would make it easy for them to swipe it through a second reader to clone the data. I'll come back to this later and show how Chip and PIN can lead to a solution to this problem.
The problem with the magnetic stripe is that it never changes. Every time you swipe the card, the same information gets transmitted to the card issuing bank. And they don't even have to get the physical card. In several of the credit card breaches in the past few years including Target and Home Depot, card information was stolen right out of the merchant's point of sale computer systems.
So, the fix is to come up with a way to have some of the information on the credit card change each time you use it. Fortunately, there is, and it's called a smart card. All a smart card is is a plastic, credit card sized card with a small embedded computer, and an exposed metal pad that allows the card to make contact with a reader of some sort. Some people have smart cards issued by their employer that they used to log into their computers (including the US Government's CAC and PIV cards). I've also seen laundry machines that used smart cards instead of taking coins. A special credit card machine was used to load money onto the card from a credit or debit card. And now credit cards that are actually smart cards exist.
Actually, they're nothing new. The first smart card payment card was a Carte Blanche card deployed in France in 1986. In the 1990s, Europay, MasterCard, and Visa collaborated to develop a standard, first released in 1995, called EMV (which stands for Europay, MasterCard, Visa). Today, EMV is the standard for payment cards worldwide, and in addition to MasterCard (which absorbed Europay) and Visa, the organization that oversees the standard now includes American Express, Discover, Japan's JCB, and China UnionPay.
What an EMV credit card does, in addition to storing the card number and other information we're used to, is generate a unique code per transaction called a cryptogram. The cryptogram is what's called a digital signature that verifies the transaction details. Change any of the details about the transaction, and the cryptogram won't match. Since the private key used to generate the cryptogram can't be removed from the card, this proves that the correct original card was used. It also means that if account information is taken from a merchant's computers, it's not useful since they can't change any of the transaction details without invalidating the cryptogram.
But, there's a catch. EMV cards still have magnetic stripes, because not every merchant has EMV-capable credit card terminals. And right now, what is the one huge market, with a high rate of credit card use, that doesn't have EMV?
The United States of America.
EMV is standard across Europe. Across Asia. Across Latin America. Canada has it. Mexico has it. But the United States is behind. Why?
For one thing, ever since we moved from imprinting the embossed numbers on carbon paper to the magnetic stripe in the first place, transactions are authorized in real time. Over time, banks have implemented more complex fraud detection algorithms, so they have other ways of detecting suspected fraud. In other countries, the cost of having a payment terminal make a telephone call to the bank every time a card was swiped was prohibitive, so other ways of attempting to see if the transaction was legitimate or not were needed. Thus, the use of a PIN, a number the cardholder could enter into a payment terminal, and could be authenticated by the card itself, rather than the bank. Then, at the end of the business day (or whatever time was convenient), only one phone call was needed to transmit all of the day's credit card transactions to the bank.
Combine that with just how big and profitable, the US credit card industry is. We have so many people running so many credit and debit card transactions every day, that even with the fairly small cut that the credit card issuers and payment networks (Visa, MasterCard, etc) take, the amount of money they lost due to fraudulent transactions was actually rather small. In 2010, losses due to credit card fraud were reported as 4.46 cents for every $100 in credit and debit card transactions worldwide. So it wasn't worth the effort and expense to migrate the US to EMV, even as fraud in the US increased as it decreased elsewhere. Thieves abroad were able to steal and sell credit card details that, while they couldn't be used in their home country, could be used in the US.
There also wasn't a big consumer demand for more secure credit cards. Federal law limits cardholder liability for fraudulent transactions to $50, and competitive pressures resulted in virtually all issuers now offering $0 cardholder liability on their cards.
So what happened?
Target got hacked. It wasn't the first credit card data breach that happened, but it got a lot of publicity because so many people were affected. And after that, the breaches just kept on coming. Albertson's. Staples. PF Chang's. Kmart. Jimmy John's. Neiman Marcus. Michael's. The UPS Store. Diary Queen. Goodwill. JP Morgan Chase. And let's not forget Home Depot, the biggest of them all with 56 million credit and debit cards compromised, compared to 40 million at Target. But starting with the Target breach and coming yet again every time another breach was reported, people started asking if there was something better that could be done. Could we make our credit cards more secure?
The answer was staring us in the face. From across the Atlantic, the Pacific, and across our northern and southern borders. Every American who had to stand in line to buy a train ticket in Paris because the kiosk wouldn't accept their credit card, who had to pay cash for a train ticket in The Netherlands because they only take Chip and PIN credit cards, who had to make sure they got gas for their rental car at an attended gas stations in Europe because the pay at the pump machines only took chip cards, who had to wait for a European cashier to find a pen so they could sign the receipt, who had to argue with a merchant that barely spoke English that Visa required them to accept their chipless credit card knew the answer.
EMV.
EMV wasn't completely unheard of in the United States. The United Nations Federal Credit Union (whom, as you might suspect from the name, has a fair number of members who travel overseas) was the first US financial institution to issue an EMV credit card, in 2010. The four big payment networks (Visa, MasterCard, American Express, and Discover), had set a date of October 2015 for a liability shift (I'll get to that in a bit). Some people probably thought the date would be pushed back. But after the Target breach and the "can we make this more secure?" questions seriously started to be asked, that date started looking a lot more firm.
So what is this liability shift? It has to do with who is liable for fraudulent credit card transactions. Normally, the issuer of the credit card holds that liability. The liability shift incentivizes a migration to EMV by shifting liability to the weakest link in the chain. Really, only one thing changes, but it's the key: If an EMV card is used in a magnetic stripe terminal, the merchant assumes liability for any fraudulent transactions. Thus, the card issuer is incentivized to replace their magnetic stripe only cards with EMV cards, in order to avail themselves of the opportunity to shift some liability away from themselves. Meanwhile, the merchant is incentivized to replace their magnetic stripe only credit card terminals with ones that can use EMV, so that they can shift that liability away from themselves and right back to the issuing bank. And since fraud goes down since there's one less way to do it, the bank still wins because they lose less to credit card fraud.
So in 2014, EMV migration started seriously happening in the US. The major card issuers, and some of the smaller ones, started migrating their credit card products to EMV. Issuers with a presence in other countries (like American Express, Capital One, and Citibank) had been issuing EMV cards in those countries for years, but by 2014 started offering EMV in the US as well. At one extreme, American Express now claims that all of its card products are now offered with EMV, including cards that they no longer take new applications for, like Zync. At the other extreme are banks like Capital One, which was late to start and currently offer it only on the Venture and VentureOne cards (but have been offering EMV cards in Canada for years). But its happening, with more and more cards being converted. One of the most recent is Chase's United MileagePlus Club and Explorer cards, which have only started being offered so recently that they don't show up with chips on Chase's web site yet (but I've seen pictures of actual cards, so I know they exist) and not all phone reps will know about it if people call to ask to get a chipped version.
But issuing EMV cards isn't enough. Merchants have to take them, and not continue to rely on the magnetic stripe. The magnetic stripe on an EMV card still has unchanging data and still can be cloned. And if a merchant is processing transactions with magnetic stripes, the situation hasn't improved. The banks will have spent a bunch of money to send out new cards (which are themselves more expensive; it should seem obvious that a piece of plastic with a tiny computer embedded in it would cost more than one without) but fraud won't go down. Thus, the liability shift to get merchants to upgrade terminals on their end, and to do it now rather than waiting for their current terminals to wear out and be replaced in a few years.
But what prevents an EMV card (whether authentic or one whose magnetic stripe has been cloned) from being used with a magnetic stripe terminal anyway, since nearly all EMV-capable terminals (basically, anything that's not an unattended kiosk in a country that made the migration to EMV years ago) have magnetic stripe readers too? The EMV specification accounts for that. Included on the magnetic stripe is something called the Service Code, and included in that is an indicator that the card has an EMV chip. A non-EMV terminal wouldn't recognize that and just ignore it and process the transaction normally, but an EMV-capable terminal would see the Service Code indication that it's an EMV card, stop the transaction, and prompt the user to insert the card into the chip reader. If the customer is presenting a card that doesn't have a chip, but the terminal is prompting them to insert the card into the chip reader, the merchant can be pretty confident that their customer is a criminal attempting to use a cloned credit card.
So in order for everyone to see the benefits of reducing credit card fraud, we need to see lots of merchants upgrade their terminals. When the majority of merchants have EMV terminals, and the majority of cards are EMV, criminals will have a hard time using cloned credit cards since not many places will accept them, and swiping in general will become the exception rather than the norm.
Where else have we seen this type of scenario? Vaccine herd immunity.
So, that's great. Fraud will go down, credit cards will be easier to use overseas again, everyone will be happy. End of story, right?
Nope.
There's a couple problems. The first I think will resolve itself soon enough. Lots of stores, especially big chain stores, have EMV capable terminals. But they haven't turned them on yet and still force you to swipe. The one big exception is Walmart (including Sam's Club), which has enabled EMV. I think the problem is that the big chain stores have complex custom point of sale systems that need to be modified to support EMV, compared to smaller merchants whose credit card terminals aren't connected to anything but a phone line or an Internet connection. So for them, migration is just getting a new terminal and asking their acquirer to enable EMV on their account. The larger merchants will get there, and many of them have said they're working on it. I think a problem is some peculiarities introduced by US debit cards to allow the transaction to route over either the credit or debit networks, but I have no reason to believe that won't get sorted out soon.
The second problem is more complicated.
The media is lying to you.
You've probably seen or heard stories about how US banks are now issuing "Chip and PIN" cards, and how you use the card will soon change. But like so many things, the devil is in the details, and the mainstream media gets it wrong.
EMV defines at least two ways for a credit card holder to prove who they are, signature or a PIN (and there are a few variations on how the PIN is handled, but that's more detail than I need to get into here). These are called Cardholder Verification Methods, or CVMs. And you've likely used both of these methods with non-EMV cards. If you've ever used your debit (as opposed to credit) card at a store, you were probably asked "credit or debit?" The labels are badly chosen, and either way the money comes right out of your bank account, but the difference is that if you choose "credit", your transaction is processed over Visa or MasterCard's credit card network and processed like a credit card, where you sign a receipt for the purchase. Or you can choose "debit", where the transaction is processed over an interbank network like STAR, Pulse, Cirrus, or NYCE, you enter the PIN number you'd use to withdraw cash from an ATM with the same card, and you don't have to sign. Oh and as an interesting side note, prior to migrating to EMV, Australian banks issued swipe and PIN credit cards.
So the EMV standard supports both. The banks that issue EMV credit cards decide which CVMs they want to support, and program that information into the chip. Credit card terminal manufacturers do as well. Typically, a manned terminal will support both, since it has a number pad (needed to allow the cashier to enter the payment amount) and thus can accomodate PIN entry, as well as a printer to print the receipt, which allows the merchant to print a second copy of the receipt and collect a signature. A convenient setup is to have an external PIN pad placed on the customer side of the counter, to allow them to enter their PIN without the merchant having to hand over the full payment terminal. These PIN pads can have built in card readers as well, allowing the customer to insert or swipe their own card rather than having to hand it to the cashier. They might also have the necessary hardware to support contactless payments (I'll get to those eventually) too. Make them a little fancier and you have the terminals you've been using for years at big chain stores where you sign or enter the PIN on a digital pad using an electronic pen. Look carefully at the bottom, and you might see a card slot, but unless you're at Walmart or Sam's Club, it probably won't work. At some places, like Target, it might even be covered up.
But, we have a problem. Not all terminals support both. In particular, those pesky European train ticket kiosks and pay at the pump gas stations. Since those countries tend to be primarily Chip and PIN, they assume that the cards will support PIN as well.
And this is where the big lie comes in.
You probably aren't getting a Chip and PIN card. You're probably getting a Chip and Signature card.
So what's the difference?
Remember how I said the issuer decides what CVMs they support, and programs that information into the card. Well, the way that typically works is that the terminal reads the list from the card and chooses the first one that works for it. So the convention is that the highest priority CVM for purchases (cash advances are always first, and are pretty much always PIN) defines whether the card is Chip and PIN or Chip and Signature. European and Canadian cards are normally Chip and PIN, since they put PIN above signature. But nearly all US cards are Chip and Signature. Not all hope is lost, since the US isn't the only country where Chip and Signature is normal; Singapore is another. And there are a few Chip and PIN cards being issued in the US.
But Chip and PIN or Chip and Signature really only refer to the highest priority option. I suspect that all PIN cards put Signature somewhere on their list. But not all Signature cards have support for PIN. Barclaycard US (I note US since they're a subsidiary of a British bank that would do this differently) is one of the best, since their cards, including Arrival+ and the HawaiianMiles cards, as their cards not only does it support PIN, but all the variations on how the PIN can be handled (USAA and SunTrust Bank also fall into this category), so they've got the best chance of acceptance worldwide. Next are banks like Wells Fargo, Citibank, and Bank of America (though BofA reps deny their cards support PIN for purchases, they actually do), which support some but not all PIN modes, so there's still a chance of not finding a matching CVM. Finally, there are issuers like American Express, Capital One, and Chase, which don't support PIN for purchases at all for their US-issued cards. MasterCard is a bigger advocate of PIN than Visa (which is heavily promoting Chip and Signature in the US), so there's a better chance that a MasterCard will support PIN of some sort.
But there is one thing that will help. Visa is pushing to ban PIN-only kiosks, but it's yet to be seen if they'll really be successful. What they're doing is trying to get the PIN-only kiosks to be modified to support another CVM I haven't mentioned yet called "No CVM". This is what it sounds like, where the card tells the terminal not to perform cardholder verification. This is also what happens when you use a kiosk in the US and you just swipe your card and don't sign anything (being asked for your zip code is really something else called address verification--online purchases do this too when they ask for your billing address separate from a shipping address--and is a source of as much annoyance to foreign visitors to the US as not having a PIN-capable card is to Americans overseas).
But even then we still have a problem, and that is merchants who are reluctant to accept signature transactions. They may be required to accept all valid cards (Chip and PIN, Chip and Signature, or magnetic stripe), and some bank customer service reps would outright tell their customers this when they would call to enquire about EMV cards (Capital One was notorious for this), but try explaining that merchant in rural Bulgaria who doesn't speak much English. And merchants are frequently selective about what rules they follow with respect to credit card acceptance. I still see merchants with signs that state an extra fee for credit card purchases; although they're no longer prohibited by Visa and MasterCard, they are still prohibited by state laws in California and some other states. And people have reported merchants in Australia not wanting to take Chip and Signature cards there, after that country converted to Chip and PIN last year, even though they're explicitly told that foreign issued cards may still be signature and those are still valid. The UK is an interesting case, since even though it's Chip and PIN, banks issue Chip and Signature cards to customers with certain disabilities, and thus refusal to accept a Chip and Signature card means the merchant risks running afoul of British laws prohibiting discrimination against disabled persons.
But none of that is a big deal if you're not much of an international traveller, since most cards issued in the US are Chip and Signature, and Chip and Signature is the least change from our current swipe and sign model. And some cards support PIN in one form or another, increasing the chances that the card will work abroad.
But what if you are a frequent enough international traveller that you want to avoid the hassle of being stuck with a Chip and Signature card in a Chip and PIN country. Or you feel, as I do, that a signature is pretty worthless as a form of cardholder verification (either the card itself is stolen, which has the signature written on the back for the thief to copy, or the card is cloned in which case they can make up whatever signature they want to put on the back of the card and on the receipt).
Fortunately, there are options out there. The United Nations Federal Credit Union card mentioned earlier as having the first US-issued EMV credit card is Chip and PIN. The Harvard Alumni card is also Chip and PIN, as is the Diner's Club card from BMO/Harris Bank, which unfortunately isn't currently accepting new applications. First Tech Federal Credit Union is preparing to switch from Visa to MasterCard, and it appears that the new MasterCards will be Chip and PIN. There's also a couple of wildcards: Walmart has stated a preference for Chip and PIN, and while the current Walmart and Sam's Club issued cards are Chip and Signature, they are supposed to start issuing Chip and PIN versions this year. Another wildcard is Target, which also claims to be coming out with a new Chip and PIN REDcard MasterCard, though as it hasn't been released yet, it remains to be seen whether this will truly be Chip and PIN or if the term is being used generically to refer to EMV chip cards.
However, it looks like Chip and PIN may itself have a few problems in the US. Some merchants might not acquire customer-facing PIN pads, which would make it difficult (though not impossible) to use a Chip and PIN card since the customer would have to get access to the payment terminal normally used by the cashier, likely by either handing the card across the counter to the customer, or the customer walking around behind the counter.
A bigger problem is restaurants. Currently, many restaurants use a model where the server takes the customer's card away from the table to process the payment somewhere else. With Chip and Signature cards, this works no differently than today since a receipt is printed and the customer signs it, no different than if it was swiped. But if the card is Chip and PIN, the card terminal is some distance away from the customer. With the current model, the customer would end up having to follow the server to the payment terminal to enter their PIN.
The other option would be for restaurants to change the way they work. One is to adopt a model where the customer pays a cashier near the restaurant's entrance. Some places do this, but they're typically more casual restaurants like Denny's, so many restaurants might not want to change to this model for fear of being seen as less service oriented or moving downscale.
However, there is another solution that's already available, and yet again we can look to Europe and Canada to see it in use. There, in many restaurants, when it comes time to pay, instead of the server taking the credit card away from the customer, the server has a portable wireless terminal where the chip card can be read (and non-chip cards can be swiped) right at the customer's table. The server hands the terminal to the customer to enter any tip (which has the bonus of eliminating tip fraud where the server changes the tip amount after the fact) and enter their PIN. For a Chip and Signature card, all that changes is instead of entering a PIN, they sign the receipt that gets printed on the terminal's built-in printer. So not only have we solved the PIN problem, we've eliminated tip fraud and removed the opportunity for a card's magnetic stripe to be cloned out of sight of the customer. It remains to be seen if American restaurants will adopt this technology though.
My current thinking is, for someone who doesn't travel internationally (or mainly to Chip and Signature countries like Singapore), any card issued today in the US is fine. But if they do travel to Chip and PIN countries, or prefer the added security of a Chip and PIN card, they might want to investigate a Chip and PIN card to have in addition to a Chip and Signature card; at this point I'd hesitate to have only a Chip and PIN card in the US until we see how restaurants are going to handle them.
So, one question that people might ask is, since the US is so late in making the transition to EMV, why not skip EMV chip cards entirely and go straight to mobile payments?
A good question. The simple answer is that, while it may seem like everyone has a smart phone, that's not really true, lots of older ones and even some still on the market (such as the iPhone 5S) don't have the necessary hardware to support contactless payments, and even a dumb phone is expensive to produce compared to a chipped credit card. Plus, phones have batteries that can run out.
But contactless doesn't have to mean just phones, though it seems like mobile payments (and Apple Pay in particular) is the driving force to get people in the US interested in contactless payments. In many other countries, it's common for credit cards to have the contactless capabilities built right into the card itself, so that people can just tap their cards, rather than inserting the card into the chip reader. The technology is available in the US, but despite advertising, never became terribly popular and so it's much less common for US-issued cards to have them. But they are out there, and with interest in Apple Pay, cards with built in contactless as well as other mobile phone payment systems like Google Wallet will also become more accepted as merchants enable support for Apple Pay.
Which is because, as it turns out, Apple Pay is EMV! Specifically, it uses the same protocols as defined in the EMV specification for contactless cards to communicate with the the terminal. It also supports another form that is only used in the US where the data sent is similar to the magnetic stripe data. All this is transparent to the user, though. It's why Apple Pay works in countries where contactless credit cards are more commonly used, even though Apple Pay hasn't been formally rolled out in those countries.
Contactless EMV in general seems equally secure to contact EMV. One concern that may have hindered contactless acceptance in the US is a fear that people would be able to wirelessly steal your credit card number without even knowing it. This doesn't seem to have become an issue in countries where contactless is more common, and as with the risk of card information being taken from merchants' computer systems, they still wouldn't be able to generate a valid cryptogram thus making the information of limited use. Issuers and merchants have also typically limited the transaction amount allowed for contactless transactions, requiring either a card insertion or PIN for higher value transactions anyway.
A second factor that may have limited contactless popularity in the US is that many merchants are able to waive collecting a signature for lower value transactions, often those under $50. This makes swiping a magnetic stripe card as fast as tapping a contactless one, compared to inserting a chip card and entering a PIN, since PIN waivers for low value contact EMV transactions seem rare to nonexistant. For example, at Walmart, a customer using a Chip and PIN card will always be prompted to enter their PIN, while a customer using a Chip and Signature card will only be asked to sign if the transaction amount is above the store's threshold.
Apple Pay takes contactless security a bit further with two things. One is the use of the fingerprint sensor to authenticate the cardholder. PINs, while better at authenticating a customer than a signature, can still be observed and copied, but copying a fingerprint is rather more difficult.
The second thing Apple Pay does is implement tokenization, a process where the phone actually generates a unique card number and stores and uses that, rather than the actual number printed on the card. This unique number is translated in the payment network to link it back to the cardholder's actual account, and setting this piece up is why not all cards work with Apple Pay; the issuing bank needs to have tokenization support working on their end. Tokenization is part of the EMV specification and isn't unique to Apple Pay, so it's likely we'll see this spread to other forms of payment, possibly including contact EMV cards.
So, after all that, we've solved credit card fraud, once and for all, right?
Nope.
EMV addresses what's called card-present fraud (where the card itself is present at the time of the transaction), but does little for card-not-present fraud, which today tends to mean Internet transactions. Various things have been tried, but nothing that has had the broad base of consumer acceptance that EMV has. That's another topic for another day.
The magnetic stripe credit cards we use today aren't very secure. The magnetic stripe doesn't change, so what criminals do is is get a device that copies the information off the magnetic stripe, and then writes that information onto another card. This process is called cloning. The name printed on the cloned card likely matches the criminal's ID (which is itself likely a fake ID), so that if a merchant asks for ID, the name printed on the card will match the name printed on the ID, and the photo on the ID will be a photo of the criminal himself, so everything will look good to the cashier (assuming they don't look too closely at the cardholder name printed on the receipt, which would come from the magnetic stripe data copied from the original card).
For one example of a credit card cloning setup, see these pictures of a fake New York City taxi, and note in the last one two credit card swipe machines, one real one to process the fare, and another one to read the magnetic stripe data off the card and store it to clone later.
Another easy way would be to target a waiter in a restaurant, since they often take credit cards away from the customer's table and swipe them somewhere out of customers' view, which would make it easy for them to swipe it through a second reader to clone the data. I'll come back to this later and show how Chip and PIN can lead to a solution to this problem.
The problem with the magnetic stripe is that it never changes. Every time you swipe the card, the same information gets transmitted to the card issuing bank. And they don't even have to get the physical card. In several of the credit card breaches in the past few years including Target and Home Depot, card information was stolen right out of the merchant's point of sale computer systems.
So, the fix is to come up with a way to have some of the information on the credit card change each time you use it. Fortunately, there is, and it's called a smart card. All a smart card is is a plastic, credit card sized card with a small embedded computer, and an exposed metal pad that allows the card to make contact with a reader of some sort. Some people have smart cards issued by their employer that they used to log into their computers (including the US Government's CAC and PIV cards). I've also seen laundry machines that used smart cards instead of taking coins. A special credit card machine was used to load money onto the card from a credit or debit card. And now credit cards that are actually smart cards exist.
Actually, they're nothing new. The first smart card payment card was a Carte Blanche card deployed in France in 1986. In the 1990s, Europay, MasterCard, and Visa collaborated to develop a standard, first released in 1995, called EMV (which stands for Europay, MasterCard, Visa). Today, EMV is the standard for payment cards worldwide, and in addition to MasterCard (which absorbed Europay) and Visa, the organization that oversees the standard now includes American Express, Discover, Japan's JCB, and China UnionPay.
What an EMV credit card does, in addition to storing the card number and other information we're used to, is generate a unique code per transaction called a cryptogram. The cryptogram is what's called a digital signature that verifies the transaction details. Change any of the details about the transaction, and the cryptogram won't match. Since the private key used to generate the cryptogram can't be removed from the card, this proves that the correct original card was used. It also means that if account information is taken from a merchant's computers, it's not useful since they can't change any of the transaction details without invalidating the cryptogram.
But, there's a catch. EMV cards still have magnetic stripes, because not every merchant has EMV-capable credit card terminals. And right now, what is the one huge market, with a high rate of credit card use, that doesn't have EMV?
The United States of America.
EMV is standard across Europe. Across Asia. Across Latin America. Canada has it. Mexico has it. But the United States is behind. Why?
For one thing, ever since we moved from imprinting the embossed numbers on carbon paper to the magnetic stripe in the first place, transactions are authorized in real time. Over time, banks have implemented more complex fraud detection algorithms, so they have other ways of detecting suspected fraud. In other countries, the cost of having a payment terminal make a telephone call to the bank every time a card was swiped was prohibitive, so other ways of attempting to see if the transaction was legitimate or not were needed. Thus, the use of a PIN, a number the cardholder could enter into a payment terminal, and could be authenticated by the card itself, rather than the bank. Then, at the end of the business day (or whatever time was convenient), only one phone call was needed to transmit all of the day's credit card transactions to the bank.
Combine that with just how big and profitable, the US credit card industry is. We have so many people running so many credit and debit card transactions every day, that even with the fairly small cut that the credit card issuers and payment networks (Visa, MasterCard, etc) take, the amount of money they lost due to fraudulent transactions was actually rather small. In 2010, losses due to credit card fraud were reported as 4.46 cents for every $100 in credit and debit card transactions worldwide. So it wasn't worth the effort and expense to migrate the US to EMV, even as fraud in the US increased as it decreased elsewhere. Thieves abroad were able to steal and sell credit card details that, while they couldn't be used in their home country, could be used in the US.
There also wasn't a big consumer demand for more secure credit cards. Federal law limits cardholder liability for fraudulent transactions to $50, and competitive pressures resulted in virtually all issuers now offering $0 cardholder liability on their cards.
So what happened?
Target got hacked. It wasn't the first credit card data breach that happened, but it got a lot of publicity because so many people were affected. And after that, the breaches just kept on coming. Albertson's. Staples. PF Chang's. Kmart. Jimmy John's. Neiman Marcus. Michael's. The UPS Store. Diary Queen. Goodwill. JP Morgan Chase. And let's not forget Home Depot, the biggest of them all with 56 million credit and debit cards compromised, compared to 40 million at Target. But starting with the Target breach and coming yet again every time another breach was reported, people started asking if there was something better that could be done. Could we make our credit cards more secure?
The answer was staring us in the face. From across the Atlantic, the Pacific, and across our northern and southern borders. Every American who had to stand in line to buy a train ticket in Paris because the kiosk wouldn't accept their credit card, who had to pay cash for a train ticket in The Netherlands because they only take Chip and PIN credit cards, who had to make sure they got gas for their rental car at an attended gas stations in Europe because the pay at the pump machines only took chip cards, who had to wait for a European cashier to find a pen so they could sign the receipt, who had to argue with a merchant that barely spoke English that Visa required them to accept their chipless credit card knew the answer.
EMV.
EMV wasn't completely unheard of in the United States. The United Nations Federal Credit Union (whom, as you might suspect from the name, has a fair number of members who travel overseas) was the first US financial institution to issue an EMV credit card, in 2010. The four big payment networks (Visa, MasterCard, American Express, and Discover), had set a date of October 2015 for a liability shift (I'll get to that in a bit). Some people probably thought the date would be pushed back. But after the Target breach and the "can we make this more secure?" questions seriously started to be asked, that date started looking a lot more firm.
So what is this liability shift? It has to do with who is liable for fraudulent credit card transactions. Normally, the issuer of the credit card holds that liability. The liability shift incentivizes a migration to EMV by shifting liability to the weakest link in the chain. Really, only one thing changes, but it's the key: If an EMV card is used in a magnetic stripe terminal, the merchant assumes liability for any fraudulent transactions. Thus, the card issuer is incentivized to replace their magnetic stripe only cards with EMV cards, in order to avail themselves of the opportunity to shift some liability away from themselves. Meanwhile, the merchant is incentivized to replace their magnetic stripe only credit card terminals with ones that can use EMV, so that they can shift that liability away from themselves and right back to the issuing bank. And since fraud goes down since there's one less way to do it, the bank still wins because they lose less to credit card fraud.
So in 2014, EMV migration started seriously happening in the US. The major card issuers, and some of the smaller ones, started migrating their credit card products to EMV. Issuers with a presence in other countries (like American Express, Capital One, and Citibank) had been issuing EMV cards in those countries for years, but by 2014 started offering EMV in the US as well. At one extreme, American Express now claims that all of its card products are now offered with EMV, including cards that they no longer take new applications for, like Zync. At the other extreme are banks like Capital One, which was late to start and currently offer it only on the Venture and VentureOne cards (but have been offering EMV cards in Canada for years). But its happening, with more and more cards being converted. One of the most recent is Chase's United MileagePlus Club and Explorer cards, which have only started being offered so recently that they don't show up with chips on Chase's web site yet (but I've seen pictures of actual cards, so I know they exist) and not all phone reps will know about it if people call to ask to get a chipped version.
But issuing EMV cards isn't enough. Merchants have to take them, and not continue to rely on the magnetic stripe. The magnetic stripe on an EMV card still has unchanging data and still can be cloned. And if a merchant is processing transactions with magnetic stripes, the situation hasn't improved. The banks will have spent a bunch of money to send out new cards (which are themselves more expensive; it should seem obvious that a piece of plastic with a tiny computer embedded in it would cost more than one without) but fraud won't go down. Thus, the liability shift to get merchants to upgrade terminals on their end, and to do it now rather than waiting for their current terminals to wear out and be replaced in a few years.
But what prevents an EMV card (whether authentic or one whose magnetic stripe has been cloned) from being used with a magnetic stripe terminal anyway, since nearly all EMV-capable terminals (basically, anything that's not an unattended kiosk in a country that made the migration to EMV years ago) have magnetic stripe readers too? The EMV specification accounts for that. Included on the magnetic stripe is something called the Service Code, and included in that is an indicator that the card has an EMV chip. A non-EMV terminal wouldn't recognize that and just ignore it and process the transaction normally, but an EMV-capable terminal would see the Service Code indication that it's an EMV card, stop the transaction, and prompt the user to insert the card into the chip reader. If the customer is presenting a card that doesn't have a chip, but the terminal is prompting them to insert the card into the chip reader, the merchant can be pretty confident that their customer is a criminal attempting to use a cloned credit card.
So in order for everyone to see the benefits of reducing credit card fraud, we need to see lots of merchants upgrade their terminals. When the majority of merchants have EMV terminals, and the majority of cards are EMV, criminals will have a hard time using cloned credit cards since not many places will accept them, and swiping in general will become the exception rather than the norm.
Where else have we seen this type of scenario? Vaccine herd immunity.
So, that's great. Fraud will go down, credit cards will be easier to use overseas again, everyone will be happy. End of story, right?
Nope.
There's a couple problems. The first I think will resolve itself soon enough. Lots of stores, especially big chain stores, have EMV capable terminals. But they haven't turned them on yet and still force you to swipe. The one big exception is Walmart (including Sam's Club), which has enabled EMV. I think the problem is that the big chain stores have complex custom point of sale systems that need to be modified to support EMV, compared to smaller merchants whose credit card terminals aren't connected to anything but a phone line or an Internet connection. So for them, migration is just getting a new terminal and asking their acquirer to enable EMV on their account. The larger merchants will get there, and many of them have said they're working on it. I think a problem is some peculiarities introduced by US debit cards to allow the transaction to route over either the credit or debit networks, but I have no reason to believe that won't get sorted out soon.
The second problem is more complicated.
The media is lying to you.
You've probably seen or heard stories about how US banks are now issuing "Chip and PIN" cards, and how you use the card will soon change. But like so many things, the devil is in the details, and the mainstream media gets it wrong.
EMV defines at least two ways for a credit card holder to prove who they are, signature or a PIN (and there are a few variations on how the PIN is handled, but that's more detail than I need to get into here). These are called Cardholder Verification Methods, or CVMs. And you've likely used both of these methods with non-EMV cards. If you've ever used your debit (as opposed to credit) card at a store, you were probably asked "credit or debit?" The labels are badly chosen, and either way the money comes right out of your bank account, but the difference is that if you choose "credit", your transaction is processed over Visa or MasterCard's credit card network and processed like a credit card, where you sign a receipt for the purchase. Or you can choose "debit", where the transaction is processed over an interbank network like STAR, Pulse, Cirrus, or NYCE, you enter the PIN number you'd use to withdraw cash from an ATM with the same card, and you don't have to sign. Oh and as an interesting side note, prior to migrating to EMV, Australian banks issued swipe and PIN credit cards.
So the EMV standard supports both. The banks that issue EMV credit cards decide which CVMs they want to support, and program that information into the chip. Credit card terminal manufacturers do as well. Typically, a manned terminal will support both, since it has a number pad (needed to allow the cashier to enter the payment amount) and thus can accomodate PIN entry, as well as a printer to print the receipt, which allows the merchant to print a second copy of the receipt and collect a signature. A convenient setup is to have an external PIN pad placed on the customer side of the counter, to allow them to enter their PIN without the merchant having to hand over the full payment terminal. These PIN pads can have built in card readers as well, allowing the customer to insert or swipe their own card rather than having to hand it to the cashier. They might also have the necessary hardware to support contactless payments (I'll get to those eventually) too. Make them a little fancier and you have the terminals you've been using for years at big chain stores where you sign or enter the PIN on a digital pad using an electronic pen. Look carefully at the bottom, and you might see a card slot, but unless you're at Walmart or Sam's Club, it probably won't work. At some places, like Target, it might even be covered up.
But, we have a problem. Not all terminals support both. In particular, those pesky European train ticket kiosks and pay at the pump gas stations. Since those countries tend to be primarily Chip and PIN, they assume that the cards will support PIN as well.
And this is where the big lie comes in.
You probably aren't getting a Chip and PIN card. You're probably getting a Chip and Signature card.
So what's the difference?
Remember how I said the issuer decides what CVMs they support, and programs that information into the card. Well, the way that typically works is that the terminal reads the list from the card and chooses the first one that works for it. So the convention is that the highest priority CVM for purchases (cash advances are always first, and are pretty much always PIN) defines whether the card is Chip and PIN or Chip and Signature. European and Canadian cards are normally Chip and PIN, since they put PIN above signature. But nearly all US cards are Chip and Signature. Not all hope is lost, since the US isn't the only country where Chip and Signature is normal; Singapore is another. And there are a few Chip and PIN cards being issued in the US.
But Chip and PIN or Chip and Signature really only refer to the highest priority option. I suspect that all PIN cards put Signature somewhere on their list. But not all Signature cards have support for PIN. Barclaycard US (I note US since they're a subsidiary of a British bank that would do this differently) is one of the best, since their cards, including Arrival+ and the HawaiianMiles cards, as their cards not only does it support PIN, but all the variations on how the PIN can be handled (USAA and SunTrust Bank also fall into this category), so they've got the best chance of acceptance worldwide. Next are banks like Wells Fargo, Citibank, and Bank of America (though BofA reps deny their cards support PIN for purchases, they actually do), which support some but not all PIN modes, so there's still a chance of not finding a matching CVM. Finally, there are issuers like American Express, Capital One, and Chase, which don't support PIN for purchases at all for their US-issued cards. MasterCard is a bigger advocate of PIN than Visa (which is heavily promoting Chip and Signature in the US), so there's a better chance that a MasterCard will support PIN of some sort.
But there is one thing that will help. Visa is pushing to ban PIN-only kiosks, but it's yet to be seen if they'll really be successful. What they're doing is trying to get the PIN-only kiosks to be modified to support another CVM I haven't mentioned yet called "No CVM". This is what it sounds like, where the card tells the terminal not to perform cardholder verification. This is also what happens when you use a kiosk in the US and you just swipe your card and don't sign anything (being asked for your zip code is really something else called address verification--online purchases do this too when they ask for your billing address separate from a shipping address--and is a source of as much annoyance to foreign visitors to the US as not having a PIN-capable card is to Americans overseas).
But even then we still have a problem, and that is merchants who are reluctant to accept signature transactions. They may be required to accept all valid cards (Chip and PIN, Chip and Signature, or magnetic stripe), and some bank customer service reps would outright tell their customers this when they would call to enquire about EMV cards (Capital One was notorious for this), but try explaining that merchant in rural Bulgaria who doesn't speak much English. And merchants are frequently selective about what rules they follow with respect to credit card acceptance. I still see merchants with signs that state an extra fee for credit card purchases; although they're no longer prohibited by Visa and MasterCard, they are still prohibited by state laws in California and some other states. And people have reported merchants in Australia not wanting to take Chip and Signature cards there, after that country converted to Chip and PIN last year, even though they're explicitly told that foreign issued cards may still be signature and those are still valid. The UK is an interesting case, since even though it's Chip and PIN, banks issue Chip and Signature cards to customers with certain disabilities, and thus refusal to accept a Chip and Signature card means the merchant risks running afoul of British laws prohibiting discrimination against disabled persons.
But none of that is a big deal if you're not much of an international traveller, since most cards issued in the US are Chip and Signature, and Chip and Signature is the least change from our current swipe and sign model. And some cards support PIN in one form or another, increasing the chances that the card will work abroad.
But what if you are a frequent enough international traveller that you want to avoid the hassle of being stuck with a Chip and Signature card in a Chip and PIN country. Or you feel, as I do, that a signature is pretty worthless as a form of cardholder verification (either the card itself is stolen, which has the signature written on the back for the thief to copy, or the card is cloned in which case they can make up whatever signature they want to put on the back of the card and on the receipt).
Fortunately, there are options out there. The United Nations Federal Credit Union card mentioned earlier as having the first US-issued EMV credit card is Chip and PIN. The Harvard Alumni card is also Chip and PIN, as is the Diner's Club card from BMO/Harris Bank, which unfortunately isn't currently accepting new applications. First Tech Federal Credit Union is preparing to switch from Visa to MasterCard, and it appears that the new MasterCards will be Chip and PIN. There's also a couple of wildcards: Walmart has stated a preference for Chip and PIN, and while the current Walmart and Sam's Club issued cards are Chip and Signature, they are supposed to start issuing Chip and PIN versions this year. Another wildcard is Target, which also claims to be coming out with a new Chip and PIN REDcard MasterCard, though as it hasn't been released yet, it remains to be seen whether this will truly be Chip and PIN or if the term is being used generically to refer to EMV chip cards.
However, it looks like Chip and PIN may itself have a few problems in the US. Some merchants might not acquire customer-facing PIN pads, which would make it difficult (though not impossible) to use a Chip and PIN card since the customer would have to get access to the payment terminal normally used by the cashier, likely by either handing the card across the counter to the customer, or the customer walking around behind the counter.
A bigger problem is restaurants. Currently, many restaurants use a model where the server takes the customer's card away from the table to process the payment somewhere else. With Chip and Signature cards, this works no differently than today since a receipt is printed and the customer signs it, no different than if it was swiped. But if the card is Chip and PIN, the card terminal is some distance away from the customer. With the current model, the customer would end up having to follow the server to the payment terminal to enter their PIN.
The other option would be for restaurants to change the way they work. One is to adopt a model where the customer pays a cashier near the restaurant's entrance. Some places do this, but they're typically more casual restaurants like Denny's, so many restaurants might not want to change to this model for fear of being seen as less service oriented or moving downscale.
However, there is another solution that's already available, and yet again we can look to Europe and Canada to see it in use. There, in many restaurants, when it comes time to pay, instead of the server taking the credit card away from the customer, the server has a portable wireless terminal where the chip card can be read (and non-chip cards can be swiped) right at the customer's table. The server hands the terminal to the customer to enter any tip (which has the bonus of eliminating tip fraud where the server changes the tip amount after the fact) and enter their PIN. For a Chip and Signature card, all that changes is instead of entering a PIN, they sign the receipt that gets printed on the terminal's built-in printer. So not only have we solved the PIN problem, we've eliminated tip fraud and removed the opportunity for a card's magnetic stripe to be cloned out of sight of the customer. It remains to be seen if American restaurants will adopt this technology though.
My current thinking is, for someone who doesn't travel internationally (or mainly to Chip and Signature countries like Singapore), any card issued today in the US is fine. But if they do travel to Chip and PIN countries, or prefer the added security of a Chip and PIN card, they might want to investigate a Chip and PIN card to have in addition to a Chip and Signature card; at this point I'd hesitate to have only a Chip and PIN card in the US until we see how restaurants are going to handle them.
So, one question that people might ask is, since the US is so late in making the transition to EMV, why not skip EMV chip cards entirely and go straight to mobile payments?
A good question. The simple answer is that, while it may seem like everyone has a smart phone, that's not really true, lots of older ones and even some still on the market (such as the iPhone 5S) don't have the necessary hardware to support contactless payments, and even a dumb phone is expensive to produce compared to a chipped credit card. Plus, phones have batteries that can run out.
But contactless doesn't have to mean just phones, though it seems like mobile payments (and Apple Pay in particular) is the driving force to get people in the US interested in contactless payments. In many other countries, it's common for credit cards to have the contactless capabilities built right into the card itself, so that people can just tap their cards, rather than inserting the card into the chip reader. The technology is available in the US, but despite advertising, never became terribly popular and so it's much less common for US-issued cards to have them. But they are out there, and with interest in Apple Pay, cards with built in contactless as well as other mobile phone payment systems like Google Wallet will also become more accepted as merchants enable support for Apple Pay.
Which is because, as it turns out, Apple Pay is EMV! Specifically, it uses the same protocols as defined in the EMV specification for contactless cards to communicate with the the terminal. It also supports another form that is only used in the US where the data sent is similar to the magnetic stripe data. All this is transparent to the user, though. It's why Apple Pay works in countries where contactless credit cards are more commonly used, even though Apple Pay hasn't been formally rolled out in those countries.
Contactless EMV in general seems equally secure to contact EMV. One concern that may have hindered contactless acceptance in the US is a fear that people would be able to wirelessly steal your credit card number without even knowing it. This doesn't seem to have become an issue in countries where contactless is more common, and as with the risk of card information being taken from merchants' computer systems, they still wouldn't be able to generate a valid cryptogram thus making the information of limited use. Issuers and merchants have also typically limited the transaction amount allowed for contactless transactions, requiring either a card insertion or PIN for higher value transactions anyway.
A second factor that may have limited contactless popularity in the US is that many merchants are able to waive collecting a signature for lower value transactions, often those under $50. This makes swiping a magnetic stripe card as fast as tapping a contactless one, compared to inserting a chip card and entering a PIN, since PIN waivers for low value contact EMV transactions seem rare to nonexistant. For example, at Walmart, a customer using a Chip and PIN card will always be prompted to enter their PIN, while a customer using a Chip and Signature card will only be asked to sign if the transaction amount is above the store's threshold.
Apple Pay takes contactless security a bit further with two things. One is the use of the fingerprint sensor to authenticate the cardholder. PINs, while better at authenticating a customer than a signature, can still be observed and copied, but copying a fingerprint is rather more difficult.
The second thing Apple Pay does is implement tokenization, a process where the phone actually generates a unique card number and stores and uses that, rather than the actual number printed on the card. This unique number is translated in the payment network to link it back to the cardholder's actual account, and setting this piece up is why not all cards work with Apple Pay; the issuing bank needs to have tokenization support working on their end. Tokenization is part of the EMV specification and isn't unique to Apple Pay, so it's likely we'll see this spread to other forms of payment, possibly including contact EMV cards.
So, after all that, we've solved credit card fraud, once and for all, right?
Nope.
EMV addresses what's called card-present fraud (where the card itself is present at the time of the transaction), but does little for card-not-present fraud, which today tends to mean Internet transactions. Various things have been tried, but nothing that has had the broad base of consumer acceptance that EMV has. That's another topic for another day.
Friday, July 12, 2013
TSA Needs a Checkpoint Randomizer?
Saw a news article from yesterday discussing the TSA's interest in using an electronic randomizer to randomly assign passengers to checkpoint security lanes.
The idea that they need to get proposals on whole systems to do this. They're really overthinking the problem here. They don't want any sort of indication of positive negative, for example the colors red or green. I'm not sure why they want to assign a binary result, anyway. Do they think airports only have two security lanes?
All you need to do is assign each checkpoint a number, and write a really simple program to randomly choose a number and display it. Here's my web-based implementation. It shouldn't be terribly difficult to write an iOS version and send out iPod Touches to airports to run it.
The idea that they need to get proposals on whole systems to do this. They're really overthinking the problem here. They don't want any sort of indication of positive negative, for example the colors red or green. I'm not sure why they want to assign a binary result, anyway. Do they think airports only have two security lanes?
All you need to do is assign each checkpoint a number, and write a really simple program to randomly choose a number and display it. Here's my web-based implementation. It shouldn't be terribly difficult to write an iOS version and send out iPod Touches to airports to run it.
Friday, January 13, 2012
Creating a Self-Signed SSL Certificate for Multiple Domains
This morning's adventure was trying to figure out how to generate a self-signed SSL certificate for multiple domains using OpenSSL. I found lots of discussions online, but they all didn't quite work. There were a few different ways to get a Certificate Signing Request with the SubjectAltName fields correct, but the signed certificate itself didn't have them. Finally, I got something that worked.
Credit where credit is due: The final steps that worked were based on this message from the openssl-users list and the command to generate the certificate from this page in the Linode Library.
First, save the following in a config file, for this example I'll call it example.conf and it will be for various similar domains:
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = .
serial = $dir/serial
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certs = $dir/certs
certificate = $certs/cacert.pem
private_key = $dir/private/cakey.pem
default_days = 365
default_md = sha1
preserve = no
email_in_dn = no
nameopt = default_ca
certopt = default_ca
policy = policy_match
copy_extensions = copy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 2048 # Size of keys
default_keyfile = example.key # name of generated keys
default_md = sha1 # message digest algorithm
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
req_extensions = v3_req
x509_extensions = v3_req
[ req_distinguished_name ]
# Variable name Prompt string
#---------------------- ----------------------------------
0.organizationName = Organization Name (company)
organizationalUnitName = Organizational Unit Name (department, division)
emailAddress = Email Address
emailAddress_max = 40
localityName = Locality Name (city, district)
stateOrProvinceName = State or Province Name (full name)
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
commonName = Common Name (hostname, IP, or your name)
commonName_max = 64
# Default values for the above, for consistency and less typing.
# Variable name Value
#------------------------------ ------------------------------
commonName_default = www.example.com
0.organizationName_default = Example Company
localityName_default = Honolulu
stateOrProvinceName_default = Hawaii
countryName_default = US
emailAddress_default = webmaster@example.com
[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Some CAs do not yet support subjectAltName in CSRs.
# Instead the additional names are form entries on web
# pages where one requests the certificate...
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.example.com
DNS.2 = www2.example.com
DNS.3 = www.example.net
DNS.4 = example.com
[ server ]
# Make a cert with nsCertType set to "server"
basicConstraints=CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
[ client ]
# Make a cert with nsCertType set to "client"
basicConstraints=CA:FALSE
nsCertType = client
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
Before saving the file, some changes will need to be made to be specific to your site. The one critical change is to change the [alt_names] section to be relevant to your domain, since these needed to be specified in the configuration file rather than being requested later. If you need more or fewer DNS names you can add or remove lines. One thing to note is that the first time I tried this, Firefox didn't like the URL when I tried to connect using the domain name listed in the commonName field, so I went ahead and added it to the alt_names section as well.
You may also want to change the default keyfile names and other defaults to save yourself some typing later, especially if you're only going to be generating one certificate.
Once you have the configuration file the way you like it, you're ready to generate the key and certificate. We'll be doing it in just one step, without saving the intermediate certificate signing request:
$ openssl req -new -x509 -days 365 -nodes -out example.crt -keyout example.key -config example.conf
You'll be promoted for various certificate parameters; if you didn't change the defaults to what you want, you will need to enter them when prompted, otherwise you can just hit Enter at each prompt to accept the default specified in the configuration file. The certificate will be good for one year, if you want to change it, you can alter the number of days specified in the command line (or change the default in the config file).
Once this is done, you'll see two new files: example.key (which contains the private key) and example.crt (which contains the public certificate). Do whatever it is to need to do with them for your application.
Credit where credit is due: The final steps that worked were based on this message from the openssl-users list and the command to generate the certificate from this page in the Linode Library.
First, save the following in a config file, for this example I'll call it example.conf and it will be for various similar domains:
[ ca ]
default_ca = CA_default
[ CA_default ]
dir = .
serial = $dir/serial
database = $dir/index.txt
new_certs_dir = $dir/newcerts
certs = $dir/certs
certificate = $certs/cacert.pem
private_key = $dir/private/cakey.pem
default_days = 365
default_md = sha1
preserve = no
email_in_dn = no
nameopt = default_ca
certopt = default_ca
policy = policy_match
copy_extensions = copy
[ policy_match ]
countryName = match
stateOrProvinceName = match
organizationName = match
organizationalUnitName = optional
commonName = supplied
emailAddress = optional
[ req ]
default_bits = 2048 # Size of keys
default_keyfile = example.key # name of generated keys
default_md = sha1 # message digest algorithm
string_mask = nombstr # permitted characters
distinguished_name = req_distinguished_name
req_extensions = v3_req
x509_extensions = v3_req
[ req_distinguished_name ]
# Variable name Prompt string
#---------------------- ----------------------------------
0.organizationName = Organization Name (company)
organizationalUnitName = Organizational Unit Name (department, division)
emailAddress = Email Address
emailAddress_max = 40
localityName = Locality Name (city, district)
stateOrProvinceName = State or Province Name (full name)
countryName = Country Name (2 letter code)
countryName_min = 2
countryName_max = 2
commonName = Common Name (hostname, IP, or your name)
commonName_max = 64
# Default values for the above, for consistency and less typing.
# Variable name Value
#------------------------------ ------------------------------
commonName_default = www.example.com
0.organizationName_default = Example Company
localityName_default = Honolulu
stateOrProvinceName_default = Hawaii
countryName_default = US
emailAddress_default = webmaster@example.com
[ v3_ca ]
basicConstraints = CA:TRUE
subjectKeyIdentifier = hash
authorityKeyIdentifier = keyid:always,issuer:always
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, digitalSignature, keyEncipherment
# Some CAs do not yet support subjectAltName in CSRs.
# Instead the additional names are form entries on web
# pages where one requests the certificate...
subjectAltName = @alt_names
[alt_names]
DNS.1 = www.example.com
DNS.2 = www2.example.com
DNS.3 = www.example.net
DNS.4 = example.com
[ server ]
# Make a cert with nsCertType set to "server"
basicConstraints=CA:FALSE
nsCertType = server
nsComment = "OpenSSL Generated Server Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
[ client ]
# Make a cert with nsCertType set to "client"
basicConstraints=CA:FALSE
nsCertType = client
nsComment = "OpenSSL Generated Client Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always
You may also want to change the default keyfile names and other defaults to save yourself some typing later, especially if you're only going to be generating one certificate.
Once you have the configuration file the way you like it, you're ready to generate the key and certificate. We'll be doing it in just one step, without saving the intermediate certificate signing request:
$ openssl req -new -x509 -days 365 -nodes -out example.crt -keyout example.key -config example.conf
You'll be promoted for various certificate parameters; if you didn't change the defaults to what you want, you will need to enter them when prompted, otherwise you can just hit Enter at each prompt to accept the default specified in the configuration file. The certificate will be good for one year, if you want to change it, you can alter the number of days specified in the command line (or change the default in the config file).
Once this is done, you'll see two new files: example.key (which contains the private key) and example.crt (which contains the public certificate). Do whatever it is to need to do with them for your application.
Wednesday, November 16, 2011
Using a Scientific Linux/CentOS/RHEL 6 Server for Time Machine
I recently tried to setup a Scientific Linux 6 server as a backup volume for Time Machine. I based my steps on these instructions for Ubuntu, but I thought there was enough differences that I thought it was worth posting what worked for me. I used Scientific Linux 6, but it should work just as well for CentOS 6 and Red Hat Enterprise Linux 6.
A few assumptions made in these instructions, you will want to replace them as appropriate:
- The user's username is "user".
- The Linux server has a hostname of "linux.example.com". If you don't have a hostname in DNS, you can use the server's IP address instead.
First, we need to setup the server:
1. Install the EPEL repository. I already had it on the machine, but if it's not yet installed, read and follow the instructions at http://fedoraproject.org/wiki/EPEL.
2. Install netatalk from the EPEL repository:
# yum install netatalk
# yum install netatalk
3. Add the following line to the end of /etc/netatalk/afpd.conf:
- -transall -uamlist uams_randnum.so,uams_dhx.so -nosavepassword -advertise_ssh
4. Create the TimeMachine directory in the user's home directory or wherever you want it:
$ mkdir /home/user/TimeMachine
5. Add the following two lines to the end of /etc/netatalk/AppleVolumes.default. Note that I commented out the ~ line that was already present since I didn't want to enable home directory access; I just want to use this for Time Machine:
#~
/home/user/TimeMachine TimeMachine allow:user cnidscheme:dbd options:userdots,upriv
6. Configure netatalk to be started when the system boots:
# chkconfig netatalk on
7. Start netatalk:
# service netatalk start
8. Open the AFP port in the firewall. Go to System, Administration, Firewall. Click Other Ports, Add, then scroll down until you find Port 548, Protocol tcp, Service afpovertcp. Select it and click OK. Repeat for Port 548, Protocol udp, Service aftpovertcp. Click Apply, then close the Firewall Configuration window.
Now, on your Mac:
1. Verify that you can connect to the server. From the Finder's Go menu, choose Connect to Server. Enter the server address afp://linux.example.com and click Connect. You should be prompted for a username and password.
2. Configure Time Machine to allow you to use network volumes for Time Machine. Enter the following command in Terminal.app:
$ defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1
3. Go to System Preferences, select Time Machine. Enable Time Machine and select your mounted TimeMachine volume. You will be prompted for a username and password that Time Machine will use to connect when it's performing the backup.
Friday, March 18, 2011
Why AT&T Should Give Me a 93% Discount on U-Verse Internet
So, I recently moved. At my new house, I signed up for AT&T U-Verse TV and Internet. So, what happens this week, before I've even received my first bill? DSLReports and Engadget break the news that AT&T will begin imposing a 250 gigabyte per month cap on U-Verse Internet service. This already has me reconsidering my options.
I have the U-Verse Max plan, which offers download speeds of 12 megabits per second. I even did the math in AT&T's favor, and used a non-leap year February as the definition of a month, being 28 days. Now we need to do one more division:
Switching to DSL (I've heard a lot of good things about DSLExtreme) would be my likely choice, as I've had some pretty bad experiences with Time Warner Cable's Internet offerings. Plus, from what I understand, DSL and U-Verse run over the same copper pair, so I'd also have to change my TV provider. Time Warner Cable isn't all that attractive, and I had some bad experiences with the DirecTV customer service people before deciding on U-Verse. But that's really beside the point, and not why I'm breaking out the Blogger account for the first time in almost a year.
No, I want to lay out why AT&T should be giving me an 93% discount on my U-Verse service. It all boils down to simple math:
I have the U-Verse Max plan, which offers download speeds of 12 megabits per second. I even did the math in AT&T's favor, and used a non-leap year February as the definition of a month, being 28 days. Now we need to do one more division:
In other words, the bandwidth caps allow me to use just 7% of the theoretical maximum amount of Internet usage I could have in a month. And that doesn't account for the 1.5 megabits per second upload speed. So if I can only get 7% of what I signed up for, I should only pay 7% of what I was paying for before. In other words, a 93% discount.Since the current charge for U-Verse Max is $45/month, that means I'll be paying just $3.15/month if I were to get the discount. Oh, and the folks with the $65/month Max Turbo plan, which offers 24 megabits per second? They'll barely get 4% of what they signed up for. It actually makes Max Turbo the an even better deal, at a mere $2.60/month.
Figuring out how long it would take at 12 megabits per second to consume the 250 gigabyte per month limit is left as an exercise to the reader. It's simple middle school algebra.
Tuesday, April 06, 2010
Spirit Airlines Hates Its Customers
Spirit Airlines likes to charge low fares. Really low fares. Absurdly low fares. So low, that they don't cover the cost of hauling the passenger from the gate to the end of the runway. How low? Try $9. But that's apparently not low enough. Yesterday, they announced new, even lower fares. But where do you go from $9?
Of course, if you think you're really going to get to fly somewhere on an airplane for one measly penny, you'd be quite mistaken. For if there's one thing Sprit likes more than really low fares, this is it:
Fees.
Here are a few of them:
- Want to check a bag? $19 if you pay online, $25 at the airport.
- How about another bag? $25. After August 1st, it will be $45.
- Get thirsty on board the plane? $2-3
- Want to pick your seat before you check in? $7. For the middle seat.
- Rather pre-reserve a window or aisle seat? $12. $20 for the emergency exit row.
- Oh, and you actually want that $9 fare? You'll have to join their $9 Fare Club, which costs $39.95 per year.
But all of that isn't new. And much of it is being copied by other airlines, some not exactly known for having low fares in the first place. That one-penny fare also doesn't include fuel. You pay for the seat, but there's an extra fee to actually move it anywhere.
But, buried in that press release about the one-penny fare (which I'm sure Spirit was hoping would get most of the attention), was yet another new fee.
- Want to carry-on your own luggage? Free. If it fits under the seat in front of you.
- $20. If you're a member of the $9 Fare Club and you pay in advance.
- Otherwise, it's $30.
- Or $45 if you wait to pay at the gate.
That's right. For the privilege of hauling your bag through the security checkpoint by yourself (ensuring that all liquids are in 100mL containers or less in a 1-quart zip top plastic bag outside your luggage), dragging it all through the airport terminals and down the jet bridge, and hoisting it in to the overhead bin all by yourself (ok, so you might get another passenger or a flight attendant to help you with that last bit), you have to pay Spirit Airlines a fee.
I want people to pay me to do things themselves. Imagine having to tip the bellman at a hotel for not bringing your luggage to your room, or tipping the valet to park your car yourself. That's what this is.
At the same time, they're lowering the fee for the first checked bag. $15 on domestic flights and $20 on international flights; $10 more if you're not a $9 Fare Club member. So it's actually cheaper to check a bag then not. The airline is charging you more if you do something yourself than if they do it for you.
Does that make any sense? It's like if, at the gas station, the prices at the full service pumps cost less than at the self service pumps.
Actually, yes it does make sense. Spirit's COO lays it out in the press release:
“In addition to lowering fares even further, this will reduce the number of carry-on bags, which will improve inflight safety and efficiency by speeding up the boarding and deplaning process, all of which ultimately improve the overall customer experience,” says Spirit’s Chief Operating Officer Ken McKenzie. “Bring less; pay less. It’s simple.”So, they want to reduce the number of carry-on bags. So if you charge people to do it, they won't. Simple enough.
Or is it? We have to ask the question: Why are people bringing on so many carry-on bags?
I've already answered that question. Scroll back up. I'll wait.
Ok, I'll tell you again:
- Want to check a bag? $19 if you pay online, $25 at the airport.
- How about another bag? $25. After August 1st, it will be $45.
As I predicted when American Airlines started charging for that first checked bag almost two years ago, when asked to pay a fee to check their bags, many customers will choose instead to carry them on. How do we know this is happening? Ask the flight attendants, who will tell you that passengers have been carrying on more since the airlines started charging to check bags.
So, doesn't that mean that the problem of too-many carry-ons is really the airlines' fault in the first place?
Yes.
And does it also mean that they could solve the problem by simply not charging that fee?
Yes.
But instead of reversing the move that caused the problem in the first place, Sprit has decided to solve the problem by charging yet another fee. It may work too, but not in the way Spirit is hoping.
Fewer passengers on board mean fewer carry ons, regardless of whether or not they check the bags.
So why would the company choose the customer-unfriendly option in the first place, that has the possibility of hurting its business even more?
I can draw only one conclusion:
Spirit Airlines hates its customers.
Subscribe to:
Posts (Atom)