Schneier on Security
A blog covering security and security technology.
« Hacking a Teleprompter |
| Cyberattacks Against NASA »
December 4, 2008
Credit Card with One-Time Password Generator
This is a nifty little device: a credit card with an onboard one-time password generator. The idea is that the user enters his PIN every time he makes an online purchase, and enters the one-time code on the screen into the webform. The article doesn't say if the code is time-based or just sequence-based, but in either case the credit card company will be able to verify it remotely.
The idea is that this cuts down on card-not-present credit card fraud.
The efficacy of this countermeasure depends a lot on how much these new credit cards cost versus the amount of this type of fraud that happens, but in general it seems like a really good idea. Certainly better than that three-digit code printed on the back of cards these days.
According to the article, Visa will be testing this card in 2009 in the UK.
EDITED TO ADD (12/6): Several commenters point out that banks in the Netherlands have had a similar system for years.
Posted on December 4, 2008 at 6:17 AM
• 71 Comments
To receive these entries once a month by e-mail, sign up for the Crypto-Gram Newsletter.
If this catches on, then it seems to me we might find other uses for it.
If you assume that the owner of the card has the card, then this is a weak proof of identity.
Yes, I know that you can't assume that. But it's not *quite* as silly as it sounds -- it is what the credit card company does every time they honour a transaction, after all.
Ive never understood how adding 3 more digits to a 16-digit number makes it more secure in the first place. Is this so that if you only managed to steal a copy of the FRONT of a credit card, then you don't reduce the length of the staff of Ra by the right amount and dig in the wrong room? Talk about movie-plot threat!
Where do I sign up?
Seriously though I thpought Amex had tried a similar sort of Online OTP system and they had stoped it for some reason.
To be honest anything that stops a replay attack is good, but realy it ought to protect against MITM as well which it obviously does not from the description.
So part of the way there but not quite the whole journey...
One thing I forgot,
If the only thing you ever type in is the pin it will not be long (certainly a lot lot less than the three year battery life) before it will be very easy to identify the four digits of your PIN.
Which lets face it is not good at all...
Those are EMUE cards (http://www.emue.com/devices001.html) with an event-driven sequential OTP.
This type of system is the norm from some of the major Dutch banks now. It's required to login to their online web sites and to make transfers or pay bills. You stick your debt card with a smart chip on it in to a small calculator-looking gizmo. See URL for a picture of one.
"Ive never understood how adding 3 more digits to a 16-digit number makes it more secure in the first place."
Maybe in the olden days they used those machines that take a copy of the raised letters on the front of the card more. Actually it might increase security slightly if the CCV is never stored in databases, but is still required for the first use of a credit card. By the way, how are amazon & paypal able to get away with storing credit card details? Isn't that against VISA's conditions?
"If the only thing you ever type in is the pin it will not be long (certainly a lot lot less than the three year battery life) before it will be very easy to identify the four digits of your PIN."
But you will only get three guesses... which you can do at a cash machine anyway if you have the card...
@Clive - I'm not so sure. I use a similar card for work. Its about credit card sized and contains numbers which I have to press to enter my pin, in order to get the OTP to access work systems.
Looking at the card now I can't see any indication of the pin I enter after 3 years of use.
Its really a protection for businesses accepting credit cards rather than for the consumers themselves.
Businesses which accept credit cards for purchases are allowed to store the 16 digit credit card number from the front of the card, but they are not allowed to store the CVV2 number from the back of the card. Some companies likely do it anyways, but being caught has extreme financial penalties.
Businesses may also require that a CVV2 be presented during the actual purchase process, either by having the card swiped, or through validation by the credit card numbers during an online transaction.
If business 1 stores a user's 16 digit credit card number and the data is eventually compromised from their database, business 2 which requires CVV2 numbers can be sure that they will not accept those stolen card numbers. This protects them against chargebacks when the card owner discovers the theft of their number.
One fringe benefit is that as consumers become more familiar with using a token as a second factor, they should become less obstructive to them in the corporate world, where even something as simple as RSA SecurID causes far more confusion than it should for the average end user (and double that again for the CEO).
If i use any of the extra security features on my master card. I become liable for all fraud. So I don't opt in to any of them....
@ Nick P,
"Looking at the card now I can't see any indication of the pin I enter after 3 years of use."
How big are your fingernails?
I had a Nokia phone with plastic keys for two years before I upgraded with no sign of wear on the keys. My other half lost her mobile phone and I had my old Nokia unlocked so she could use it for Pre-Pay. Within six months her fingernails had started to leave groves on the keys (likewise the keys on her PC Keyboard show groves and mine does not).
Of secondary concern is screen printing, provided they screen print the number from the underneth of a clear plastic film with suitable properties then there should (apart from fingernails) be no signs of wear. However if they screen print on top of the plastic then I suspect that the printing will start to show signs of wear reasonably quickly.
Is it going to make contesting charges more difficult? Should a vulnerability be found by the Bad Guys™, and they happen to be smart, they could use it discretely enough so that banks could claim that it's still secure, and victims would be called fraudsters, just like victims of car theft have been denied insurance claims because electronic car keys are PerfectlySecure®.
I assume you get a new card after three years. Isn't that about how often your card expires anyway?
In any case, it sounds like what we used for our VPN at my old job, and I found it a bit tricky. Those were time-based OTPs, but it always seemed like you had to try 2-3 times because you missed the window for that particular password. Average users might find that a bit frustrating, plus I don't want to be the person trying to explain why I got my time-based OTP wrong to the average cashier (i.e. because I just missed the window). I hope they're sequential for that reason.
"If i use any of the extra security features on my master card. I become liable for all fraud. So I don't opt in to any of them...."
Admitadly the "what's in it for me" factor does come into play, it was one of the things that killed off the first major attempt to sort out online CC transactions (Anybody remember EVM's Secure Electronic Transactions and the thousand odd pages of ASN1 etc documentation?)
However as seen with Chip-n-Spin the payment card industry has a way of enforcing liability on the customers.
The solution was thought up by the bods over at Cambridge labs where you put a Man In The Middle Device that recorde the communications with your card.
All the system has to do is use a transaction number with each OTP issued, if the transaction number is out of step with the OTP issued then something is wrong.
Also If the OTP/ transaction number is printed on the sales slip etc, and keep them or you write them down with the sum and merchant info (just like we used to do in our cheque book stubs ) then if the OTP is broken then it becomes clear immediatly after the first illicit transaction. Likewise the CC company cannot fiddle it either as the transaction number would again be out of step with that on your card.
Not 100% foolproof but getting there...
My cc company sends cell phone text messages and emails alerts and codes to me. I always thought it would be a good idea for purchases (at least large ones) if they would text one time PINs (for in person transactions) or email/text one time PINs for Internet purchases.
Not perfect, but it would require the perpetrator to have the card holder's cell phone or email password. An extra layer so lost cards are not so easy to use. (It will never fail, however, that cell phones are in the purse with the card.)
@: "Not 100% foolproof but getting there"
As we see with entities like the TSA, trying to be 100% foolproof is too expensive and cumbersome and often a waste.
Now, I'm probably in a minority here that I would rather them do too much than too little, but that doesn't mean I don't disagree with them.
I did a graphical analysis in my Master's thesis outlining cost/benefit of security vs convenience. Both extremes are far too expensive, for different reasons, but the area between them is more reasonable if good priorities are made.
My best analogy is that controls are like speed limits. If too strict, you never get anywhere. If too lax, you are more likely to get hurt on the way. Need a balance that gets you where you need to be at an acceptable speed with acceptable safety.
@Anonymous at December 4, 2008 8:43 AM
Sorry, that was HJohn.
How will this hold up in my wallet? On most of my cards you can't read the signature anymore because the strip has worn off and I just have the 3-digit number memorized for each card.
I've even had to get new cards because the mag strip was so bent/worn out that it took several swipes to work normally.
Sure, I could keep this card around the house and only use it for purchases online, but then it just means another credit card.
This is like the systems used by several banks in the Netherlands, except in this case they combine the bank-card and the code generation device in one. For my bank, the system centers around Digipass, marketed by Vasco. Other banks use other code generators, but the general idea is the same.
Several banks are now cooperating in a system called iDeal, which allows customers to use this system (which is typically only used for online banking) for online purchases. It is very successful, and can be used on almost all Dutch online stores.
Something that I thought was very good, that I saw in France, was disposable credit card numbers. Each time you want to make an online purchase, you get a new credit card number from your bank which you can then use to make the purchase. You don't have to worry about the number getting stolen, as it is made invalid as soon as the transaction is over.
Does this LCD resits the ISO 10373-1 dynamic bending test?
A keyboard with a 2x5 layout to type over the - difficult to remember - one-time code on the screen?
The BofA device is not a credit card, but a separate "one-time pad" for authenticating on-line transactions, only, or so it appears. They also offer the ability to get a code via a text message to your registered cell phone.
Benefits to users: increased security (which is important even if the Bank would cover some losses w/o the extra authentication), increased limits on transfers to unrelated accounts ($10K instead of $1K).
Downside: The device costs $20 (but cell method is free). Also, if a hacker finds a way around the authentication, you will have an even harder time disputing a transaction with the bank. And if you lose the device or your cell phone, you're up the creek for on-line activity for a while.
As a customer, I am not yet convinced...
@Martin and Mailman
I agree with the logic of you both. I also believe one time passwords or one time credit card numbers may not be worth the costs (money, convenience, hassle, etc.). It will also introduce a new set of risks with which we are hitherto unaware of the full impact. We'll likely hear more stories about people who were out of cell range when they needed their credit card for an emergency (or problems with their password or changing credit card numbers in a similar situation) than we will of fraud.
I believe, overall, a reasonable migration to the transaction level would be a benefit with minimal consequence. Yesterday, for the first time in a long time, a cashier asked me for my photo ID to make sure the credit card was mine (I was delighted and think this should be more frequent). Similarly, I receive a daily email of transactions made in the last 24 hours, which would tell me quickly if there was fraud (it can also be set to text the same, convenient during travel).
In short, I think we can do a few more small but reasonable things to ensure transactions are appropriate without incurring massive costs in technology and inconvenience to do so.
re disposable credit card numbers in France:
We do have those in the US as well. My SO can generate one-time use numbers with a maximum spending limit on one of his accounts. Paypal offers this as well, but oddly enough, they require that you install some Windows software, so I can't use it. (Whereas whichever bank he's using generates them within the browser.)
I'm not sure how I feel about this. On one hand, I was recently a victim of credit card fraud. (I believe my card number, including ccv, was stolen when I used the card to pay at a local restaurant.) A system like this would have saved me a lot of stress and time. However, I understand and agree with the concerns addressed by other comments.
As for the card getting damaged, and preventing fraud in the case where the card itself is stolen, I know some companies use separate key fobs to generate the number, rather than putting it directly on the card. Paypal offers one, but only for logging into your account, not for making online purchases with your debit or credit card. Of course, if you have multiple cards, then I guess you end up with a pile of fobs..
This sounds a lot like SecurID... is that really the model?
I remain unimpressed by credit/debit card security measures. This can all be done properly with PKI and modern mobile phones.
You have a key pair associated with your bank account. The bank keeps your public key and you keep your private key (encrypted with a PIN) plus your public key (signed by the bank) on your trusted portable device (e.g. phone). The bank's public key is certified by some banking CA.
When you pay for goods in a shop, the shop sends a bill to your phone (via bluetooth of whatever the latest fad is) e.g. "$30 to be given to Walmart". This is digitally signed by the store with a trust path leading back to some retail CA that your phone trusts (so you know it's not the guy in the queue behind you sending it). You digitally sign the bill (entering your PIN on your trusted device) and send it back to the shop, along with your bank's details. If they have net access they send the signed bill to your bank, which checks your balance and responds with an approved/rejected (digitally signed by the bank). If the shop doesn't have net access, your phone can also tell the shop your account's offline transaction limit (signed by the bank), guaranteeing your signed bill. The shop can then take digitally signed bills to the bank "manually" e.g. at the end of the week.
Paying for goods online is done in exactly the same way. The website presents you with a bill (digitally signed by the online store) which your computer send to your phone for signing.
With the right software on the phone this would be no less fiddly than chip&pin. Why isn't it like this?
Wow, that's really awful!
Currently, I can cut & paste all credit card data from a text file on my encryted hard disk. Now I must have the actual physical card and type? How last-millenium is that?
And I want to be able to send all card data by (encrypted) email, e.g. to help out if someone forget their credit card and wants to use mine.
@VirtualChap: "Currently, I can cut & paste all credit card data from a text file on my encryted hard disk. Now I must have the actual physical card and type? How last-millenium is that?"
That's how I feel about it. For everything important, I have encryption software and I max out all my passwords in length and content (as well as create jibberish for the [not-so-secret] questions). I even have one password that is 128 characters long of jibberish (if I don't have to type it, no different than a 8 character from my perspective). Then I run across websites that disable pasting into the password account and now things like the card.
The rule of unintended consequences, even for things that have commendable intentions.
I've been thinking about this for years, glad someone has done something about it.
I actually rather liked the idea of having your card sign your bill too - that way there was no question about the amount.
Anyways, if the physical card is required, and you have a 5 digit pin, there's a lot of possible permutations of those digits. As long as there's a sufficiently effective lockout rule, they wont guess it in time, even with wear and tear.
@Virtualchap: Actually having a shared secret like a credit card number is last-millenium. hashing, signing, and public key encryption are the new deal.
@Bob: Thats actually a really neat idea. However, there's something to be said for dedicated security devices. I personally am not a fan of trusting my accounting to a device that I download untrusted programs onto. They're supposed to be sandboxed... but physically separated devices are an even stronger sandbox.
This OTP is such a great idea!
Used to be that the smartchip was going to be the second factor rather than just having a card, but that was just a pain. you will have to install the dongle read the chip then get both authentications. With this, SO EASY! But like everyone else say, the forseeable cost in up keep of these cards are going to cost the consumers. I doubt these cards will be free for the masses. VISA/AMEX/MS will card to distribute these and tag a "Enhenced Security Protection" label to market the masses. Secure Computing (with pin pad) tokens range from 25-50 a piece, wonder how much these cost with small form factor and thinner LCD screens.
Probably inital cost = $75-$100 to consumers. And with thinner batteries, it will last no longer than 2 yrs. (RSA or Secure Computing is around 3-5 yrs)
Where can I sign up?
@bh: On the other hand, they might make it really cheap. After all, their whole goal is to loosen consumer pursestrings. The better they do that, the more they recoup in intrest.
"I remain unimpressed by credit/debit card security measures. This can all be done properly with PKI and modern mobile phones."
Oh dear where do I start...
PKI is not a good idea for many reasons and you can find most of them on this blog on one page or another.
Secondly you are making an assumption that your phone is safe from being cracked or attacked via man in the middle techniques.
When you look at the Private?Public key, how do you know the Private key is not compromised by the software generating it?
And finaly as noted above there is the "what's in it for me" problem.
As an idea it looks superficialy good but the devil is in the details and as EVM found out with SET it may not be worth the trouble...
@Nick, @Pliko - "How will this hold up in my wallet?"
For those who are concerned about wear and tear on the card, may I suggest the following?
I use one for all my primary cards. In addition, some rough testing at a security conference indicates the the thick metal shell (about 1mm) going completely around the card also acts as an effective shield against unexpected reading of RFID cards.
The inside space is thick enough to hold about eight cards.
Jeroen is correct. The current system in use by Rabobank Netherlands is branded the "Random Reader" (Google for more info), and is a Digipass. You first enter your debitcard, type your PIN code, and then choose between log in (to the website) or signing (of transactions). For login, it immediately gives a 8-digit code, which is based on account number and time (unverified sources claim that 30 codes are during about a minute). For signing, the website gives 1 to 3 additional codes (more codes if the amount of money to transfer is higher), which you enter. The result is a 8-digit signing code.
I'm not sure when they moved to this type of device. I have mine for about 8 years now. Before that I'm told they had a digipass that was different for each person (it did not have a card reader).
However, most banks in the Netherlands move away from this system in favour of one-time passwords that are sent by SMS to the cell phone that you registered with your bank account.
* PKI is currently weak (because certificates are managed by humans via ordinary email).
* I don't carry a cell phone most of the time, and don't want to.
* No current cell phone has the smarts to do this, so that would be an infrastructure change.
* The mugger would take my cell phone too.
* Wireless communication between the POS and the cell phone is easier to listen/impersonate than anything we use currently, unless the crypto is done exactly right (and what are the odds?)
Crypto is not magic, sorry.
re disposable CC numbers:
Citibank has a service called "Virtual Account Numbers" that does the same thing. You log into their site (or use a download able applet), generate a number (with limit an expiration date if desired). It works veyr well, and I consequently use my Citibank Card for all online purchases.
It would be much cooler if the card itself could handle that, but that would be too much to hope for.
Alas, I think Citi patented virtual account numbers, and consequently they are the only bank in the US doing it.
This would have saved my stepson a lot of trouble this past week. His newly issued debit card with PIN and chip was compromised at the teller machine of a major Canadian bank - not a "grey" machine. Seems there were several dozen cards compromised at this one teller machine, so a one time password would have been of great value in this case.
To the best of my knowledge, all "disposable" CC number implementations use Orbiscom's system on the backend ( http://www.orbiscom.com/ ) - That includes Citi's virtual account numbers, MBNA's ShopSafe and whatever Discover and Paypal call their systems. Amex used to offer the same service but, for reasons unknown to me, stopped.
I've been using an Orbiscom system for almost a decade now and am very happy with it. I think MBNA has advertised that they have never had a fraudulent charge via their disposable CC number system.
The only things that have been a problem for me are:
(a) merchants with broken systems that do not capture authorizations but effectively double-charge you and just never complete the first charge - those require you specify 2x the credit limit in order to make the charge go through.
(b) the banks' fraud-detection systems do not take into account if the number used is a disposable number. Thus I will occasionally get a charge denied and a phone call from the bank requiring that I call back at their main number and verify certain information (zip code, last couple of charges on the card, etc) which is all information available to anyone who knows my username/password which I just used to generate the disposable number in the first place.
How about something like the RSA keys used for VPN?
Get a credit card, and get the RSA key, so you still enter your password, AND then the changing key.
Yes, change is good for the verification code. It will cut down a large percentage of attack vectors known today, but it doesn't address all and could increase the shift away from remote theft to more personal attacks.
@shadowfirebird: But it's not *quite* as silly as it sounds -- it is what the credit card company does every time they honour a transaction, after all.
No, the credit card company assumes that it is a person authorized by the account owner.
It would be more reasonable to have a separate number generator card that you kept at home. You don't need it if you are presenting the card in person. If your credit card is lost/stolen, the thief can't use it online/phoned without the random number generator.
My company has used something similar called a Cryptocard to remotely log into the servers. It's fantastic because we don't need to worry about our real passwords being stolen by the guy looking over our shoulder at the coffee shop or anything like that. Credit cards seem like a great application for this technology!
It also depends on whether they have implemented the silicone on the card well, or whether its another faux-security device ...
Pretty sad, really.
Putting the PIN entry device on the trusted processor: good idea, although they're not the first to do it.
Using a one-time password without transaction binding: we already knew how to do better than that at least 15 years ago. Why is VISA still fielding such weak protocols in the twenty-first century?
> * PKI is currently weak (because certificates are managed by humans via ordinary email).
Perhaps true, but you don't need a full PKI for this. The only relevant relationship is between bank and account holder. The bank could (for example) install a signed cert on your phone in your local branch office.
> * I don't carry a cell phone most of the time, and don't want to.
Fair enough; I share your concern. But, it could also be done on a PDA, or custom hardware made from similar components (but greatly cut down to reduce costs). The cellphone is just a ubiquitous, highly portable computing platform.
> * No current cell phone has the smarts to do this, so that would be an infrastructure change.
I don't believe this is true at all. Many modern cellphones are essentially full fledged computers with configureable software (typically Java MIDlets) and processors (e.g. 237 MHz ARM9) which, while not nearly as powerful as a modern desktop PC, can execute their end of a cryptographic protocol in a tiny fraction of a second. It is fairly common now for even mid-range phones to support SSL web browsing, and some have a PasswordSafe-like facility for caching e-banking passwords for use by the browser.
> * The mugger would take my cell phone too.
A well-designed protocol would have forward secrecy, and bind your PIN (or better, since cellphones allow text entry, your password) into the message. Stealing the cert alone would then be useless, and should not even allow cryptanalysis of old captured messages.
Optionally you could also locally encrypt the cert with a (stretched) password, but if such a feature exists it must discourage re-use of the same password used in transactions.
Of course, the mugger could take you prisoner and coerce the password from you. It is essentially impossible for a two-factor system to completely prevent this, although there are ways to mitigate the effects to some degree.
> * Wireless communication between the POS and the cell phone is easier to listen/impersonate than anything we use currently, unless the crypto is done exactly right (and what are the odds?)
I agree that wireless comms make everything more dangerous. However, a properly designed system shouldn't even trust the merchant, and if you assume the merchant may be a thief, then over-the-air eavesdroppers are really somewhat irrelevant. So even with the likelihood of implementation flaws, it will still be far better than what we have.
But yes, I'd be happier with IrDA than RF wireless, and happier still with a wired connection. One other possibility, now that phone displays are getting to QVGA resolution and above, and with phone camera scans of 2-D barcodes becoming a common method of data entry, is 2-D barcode display on the phone screen. Picture a merchant "reader" that has a c. 2 cm wide slot with a small LCD screen below, and a camera above. Insert your phone, and via a series of 2-D barcodes it can hold a structured two-way conversation with the reader optically -- enabling a strong cryptographic protocol and physical infrastructure assembled from existing cellphones, MIDlet software, and merchant terminals that could be quickly hacked together from phone components. Local eavesdropping essentially impossible, bandwidth adequate to do the transaction in a fraction of a second, and the phone owner gets physical control over which terminal he is communicating with.
I don't see any extra security since the OTP generation is 'attached' to the card. If you are carrying a hardware token that generates OTP separately, it makes sense. The attacker only gets his hand on the card and will still not be able generate the OTP unless he has also stolen the hardware token.
Looks interesting. But usability will be a key issue especially when you have to enter a pin each time you make a purchase (forgotten pins, token going out of sync etc). It is important to keep in mind the profile of an average user who doesn't understand the intricacies.
If the goal is to address card-not-present credit card fraud then they can as well do with out the pin as mentioned in one of the comments. It is clear that this cannot be a solution to lost/stolen cards.
It's handy for online shopping.
It's also handy for what seems to be the fastest growing risk in this area - having a merchant database full of CC#s stolen. IMO the CCV2 system already works well against that threat, however.
So you saying all we need is for every consumer to carry a new appliance that they don't need today (and would have to go out of their way to acquire - at least the software), and remember a new password that they don't need to today, and for every merchant to buy some equipment they don't have today, and maybe invent a new secure key exchange system. All of which would have minimal benefit to the consumer?
Visa (the first credit card in today's sense) was of enoumous benefit to consumers, merchants, and member banks alike, and it very nearly didn't happen. The representatives from the member banks had already decided that it wasn't worth their effort, and we wouldn't have had credit cards (for another decade at least) except for a clever bit of social egineering by Dee Hock.
Infrastructure changes are hard.
"So you saying all we need is for every consumer to carry a new appliance that they don't need today (and would have to go out of their way to acquire - at least the software), and remember a new password that they don't need to today, and for every merchant to buy some equipment they don't have today, and maybe invent a new secure key exchange system. All of which would have minimal benefit to the consumer?"
All we need is for some consumers to add a new piece of software to the phones they already have, remember the same password they already use for their online banking, and for some popular merchants to buy new equipment.
It's not all-or-nothing, there's no "new secure key exchange system" to invent, and it's plausibly marketable to consumers as a "cool new way to pay using your phone".
I thought of this in 2005 - but nobody listened or heard me? its based on the securid concept that we use for VPN access.
It will be interesting to see who pays for this security feature. You (Bruce) have said many times that companies don't protect our data because they have no financial incentive to do so. (Or no financial dis-incentive if they fail to protect it.) This seems like the opposite. If memory serves, I'm only on the hook for $50 of fraudulent use if I report a theft within 30 (or 60) days. So it behooves the credit card company to take steps to stop fraud. And yet, somehow I imagine they will advertise it as, "Protect your online transactions. Only $9.95 per month . . ."
If I'm going to be making an online transaction I'd much rather use something based on Information Cards. (http://en.wikipedia.org/wiki/Information_Card)
That way, the vendor could get a secure approval from the credit card company without my even having to send the credit card number. Much better than constantly regenerating auth codes. The best protection for the card is not sending the number in the first place.
@andyinsdca, @dmc, @a.,
The traditional RSA SecurID, first introduced in 1987, was -- and is -- sold in a format similar to a credit card in two dimensions, but considerably thicker in the 3rd. The Visa card is similar, but a true credit card.
Although RSA today sells AES-based SecurID authenticators in many different formats -- hw; sw; some card or key shaped; some with buttons for PIN input; some with options for binding transaction data -- the SecurID 1100 display card, http://tinyurl.com/5o98re, introduced earlier this year, is the first SecurID that is actually credit card size in 3D.
It is also, notably, the first SecurID that is event-driven (which means you hit a button to get an OTP) rather than time-synched (continuously generating a series of OTPs.)
The 1100 design is also relatively simple: one button, and a small LCD-like screen on the CC displays the OTP. The Product Manager at RSA, for which I do some consulting, told me that for this form-factor, the current limitations in the chips available led his team to opt for AES event-synch. For him, it wasn't such a big deal. For others, time-synch defines SecurID, so even some at RSA were shocked.
RSA, as you might expect, has been testing miniature versions of its core tech for years, but only this year felt it could deliver a SecurID in the CC format that could withstand heavy use. I know they rejected several CC OTP-token designs already in the market. As the tech mix evolves, the PM told me, RSA will offer additional goodies for the 1100: a keypad for a PIN, an option for transaction-binding, even time-synch. Visa and others jumped ahead, as we see. Time will tell who got the timing and the price/performance mix right.
"offer additional goodies for the 1100:... ...an option for transaction-binding... ...Visa and others jumped ahead, as we see."
Transaction-binding with a PIN is where it's destined to go from the security perspective.
But and it's a big but, with CC's the law and behaviour of the CC companies is bound to make it a tourtuous journy at best.
It is the law of "unintended consiquences" comming into play over CC legislation that will stop increased CC security dead in it's tracks if history is anything to go by.
The customer (CC Holder) should and usually does ask "what's in it for me" and with the law the way it currently is, it is not in the card holders direct interest to have anything other than an easily repudiated security mechanisum.
However this lack of effective security does increase the cost of using CC's which ultimatly will be paid for by consumers (the law only protects the CC holder from the CC company not from the mearchant putting up prices etc to cover losses the CC company passes on to them).
After SET my money would be on the CC remaining the same as long as the law allows the card holder to easily say "this is not my transaction".
SecurID isn't the only solution on the market. ActivIdentity and Vasco offer the same solutions (Entrust, Verisign, etc. are OEM-version of the vendors above).
Concerning the article, Blizzard (maker of WoW) started to offer OTP-tokens for its players to minimize effect of stolen password accounts.
My original comment was not just about "whats in it for me". But also about security. If I am liable for every weakness in implementation on there part where is the incentive for them to do the security right. If there new system is so good, why do i foot the bill when it fails?
That tells me its not all that secure. Or soon won't be.
"whats in it for me"
Comment is a carry over from a post I made further up.
It's a comment not about individuals but the "generic consumers" short sightedness on security.
It is one of the things often quoted as being the major cause of failier for SET.
And boils down to, why should the consumer put up with increased security when there is no advantage in it for them (ie they loss easy repudiation). So security is usualy portraid as having upsides for the card issuers and downsides for the card holders and merchants.
Which is possibly why Chip-n-Spin has been foisted on the public it has only downsides for cardholders no ups, some ups and downs for merchants and only ups for the card issuers.
Basicaly the card issuers have used it to get around the Consumer Credit Protection legisation in the UK as they have removed the "credit asspect". To ensure they get their way, although having issued cards that are portraid as "credit cards" they are usually "debit cards" as well. And the card issuers ensure that most merchants only take debit by the fees they charge them and the default action of the card terminals (which as a consumer you find you cann't override)...
And the card issuers complain they don't know why consumer organisations take them to court...
The OTP is attached to the card but (in the stuff dutch banks use anyway) require the cards PIN to operate. So the system basically proves the presence of the correct card as well as the presence of someone knowing the PIN.
For transaction signing the Rabobank system the total amount of the transactions as a second input number on transactions over 500 euro. This proves the correctness of the amount transfered as well.
So for any significant amount you won't get anywhere without both the card and the PIN. Short of the old fashioned gun-to-the-head approach the only feasible attack I can see is hijacking the browser to change account numbers when transactions are submitted while displaying requested account numbers. While not impossible this is limited to redirecting money the account owner is transfering anyway.
I really like the OTP over sending text messages, largely because it does not involve adding another communication channel. It gets worse when its a wireless communication towards a device that often lost or stolen anyway.
"I really like the OTP over sending text messages, largely because it does not involve adding another communication channel."
Completely disagree. OTP's do not do much to stop man in the middle attacks or really any sort of attack where the browser is compromised. If you have a compromised system, what good is an additional security feature if you then have to enter it into that very same compromised system?
Until these banks and credit card companies start offering true out of band authentication, I won't be impressed in the slightest.
@ "What's in it for me?" for the consumer, there needs to be more functionality than just security. So why not make the OTP card work as a universal login credential? Save the customer time and allow them to secure their other online accounts using the same OTP card. These quasi single sign-on tools are popping up everywhere (I know it's not true single sign-on so stop).
There are OTP cards from Nagra ID Security that has a Common Criteria EAL Level 5+ chip in it. Applications such as ewallet can be implemented outside of the factory.
The customer (CC Holder) should and usually does ask "what's in it for me" and with the law the way it currently is, it is not in the card holders direct interest to have anything other than an easily repudiated security mechanisum.
Why not just use one of the disconnected Mobile OTP Generators like FiveBarGate to generate your OTP for you purchase. Everyone has a mobile phone, so it would be really easy to distribute to the end user and much less expensive?
Mobile also presents other security risks, it might be easy, but with the jump in Mobile malware there could be problems. Really the best way is using OTP for the password and using challenge response e-signing for transactions. This would stop MITM attacks and other attacks making it much safer, and easier to use compared to digital certs
What is the language used in OTP ?
why ECI terminal show as 912 respond code.. it is a error or genuine ?
Schneier.com is a personal website. Opinions expressed are not necessarily those of Co3 Systems, Inc.