VeriSign To Offer Passwords On Bank Card

Billosaur writes "Imagine the PayPal security tool embedded on a credit card. VeriSign is announcing that a deal is in the works to provide credit cards with one-time-use passwords. By placing the technology directly on the card, it becomes more convenient and provides an extra layer of security for online credit-card transactions. A cardholder would type in their information as normal and then would be prompted to enter the passcode displayed on the card. This means a user would need to have the physical card in hand in order to use it, thus thwarting identity thieves who steal credit card information but do not possess the card itself. VeriSign said it expects to announce a major bank using its cards in May."

Comments

Password request...

[minotaurcomputing]

Dear VeriSign,
Can I put in a request for the password 12345 before anyone else does?
-m

Re:Password request...

[EveryNickIsTaken]

Neither. You should recognize the movie reference.

securid?

[192939495969798999]

Wouldn't this basically be a version of SecurID? Why don't banks just roll out SecurID to everyone and get the same net effect?

Re:securid?

[Lachryma]

Exactly like SecurID, but without a separate token to lose and juggle for each account. It's right on the card.

while the concept is interesting

[jimstapleton]

How long is the cycle on the card? And how do they keep it from going out of sync? My watch loses about a second every day (ok, it's a cheap watch), but nonetheless, the only way it and the server can work is if the key is based on time. If that is the case, then they card's clock has to stay sync'd with the server's clock... Wouldn't that be a problem?

Re:while the concept is interesting

[daeg]

The server knows the last few values and the next few values -- any selected from a reasonable amount of time are generally permitted. Higher security requirements can lower the time window. But given a time code that changes once every 5 minutes, and a server that permits the current and previous/next two, that's a 25 minute window. So even an inaccurate clock that loses a second a day is good for almost 2 years without a clock sync.

You could even build the terminals such they sync the clock. Many terminals run on always-on connections now, so running something like ntp on them is feasible. You could use the clock skew to detect attempted fraud, too -- if you know the clock in a particular card loses 2.4 seconds a day from historical data, and the number of days between the last purchase * 2.4 seconds doesn't equal the real time, something is wrong -- possibly a forged card. It's easy to duplicate a magnetic strip, I'd bet it's harder to forge an purposely-inaccurate clock that varies from card-to-card.

As an aside, I hope the electronics are recyclable and the credit card companies actively solicit returns of them. It'd be nice if the cover/numbers of the card were simply an overlay that could be replaced, along with the clear protective coating. Replace the front panel, sync the clock, put the new data on the magnetic strip, coat it, and wham, new card without wasting the electronic components.

Power?

[airos4]

So as I understand it from the article, there'll be some sort of "device" in a corner of the card, with a "display window" that shows the randomized password? How's it powered? How's it controlled? What happens when the battery in my credit card is dead?

Re:Two Factor Dynamic Login Verification

[Red Flayer]

I've got one of these for international banking. The case is about 5 mm thick, could easily thinner except for usability concerns for something designed to be a keychain. Solar powered, but could just as easily be mechanically recharged a la some of the watches on the market. It generates an 8-digit password from some time-based algorithm; when submitted to the bank, the bank server checks the password against all possible passwords possible for the previous short period of time.

Re:Oh great...

[Red Flayer]

So I memorized my credit card account number for nothing...

Oh great... so I memorized your credit card account number for nothing...

Well..

[Anonymous Coward]

my password is 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0. Oops!

Durability

[eimsand]

My immediate concern is durability. Credit cards take a lot of punishment. I probably replace my credit card once a year because the magnetic strip has become damaged and no longer readable. All the same, magnetic strips have shown great durability for putting up with a fair amount of punishment. I'm not sure I can visualize an LCD screen thin enough to be incorporated into a card that will withstand 175+ lbs of pressure for hours at a time. And that doesn't even consider the circuitry involved in generating the passcode.

Already done

[brunes69]

RSA has been issuing SecureID keyfobs with this technology for at least 10 years. Hundreds of thousads, of not millions, exist worldwide. While I am sure they had issues like this in the past they would have long since sorted it out. SecureID keyfobs are one of the standard pilliars in the seucirty chain - encompassing the "something you have".

Usually you have to type in your password (the "something you know") along with the current number on the keyfob ("something you have"), in order to successfully authenticate with a SecureID system. They're very common in government; basically they make stealing passwords muuch less useful, since the hacker would need to steal both the password AND the keyfob - and if someone loses their keyfob they would be issued a new one and the original deactivated, so there is a small window of opportunity there as well.

Frankly it is about time someone pressured the banks into issuing this technology. I have wished I needed a keyfob for online banking and CC transactions for YEARS. The initial expense of the rollout would be quickly offset by the savings in fraud I suspect.

Verisign's Jumping The Shark

[mpapet]

This technology has been around for some time actually. If there are any smart card developers hanging about, they might point you in the right direction.

As someone with intimate knowledge of bank card costs and the infrastructure required to support a new bank card, the likelihood of this happening is slim to none. "Impossible!" you say. Please consider the following.

1. The cost of producing these cards is extremely high relative to the plastic most users have. On order of 10x.

2. The costs of integrating a new kind of card into banking/CRM infrastructure is another huge cost center.

3. The banks can't shift the costs of this new-fangled card off to the merchants. FYI: The merchants shift the cost of accepting bank cards and paying for fraudulent transactions to all consumers.

The project will be a nice idea that they can use as an example to regulators that they are "enhancing customer security." but is destined for the shelf.

What's needed here is an OSS banking system, not the one we currently have.

The cycle is INFINITELY long.

[raehl]

I'm surprised that you have 6 replies to your post that are all wrong.

The cards don't generate the keys based on time. The keys are generated much the same way random numbers are generated in a computer.

The way this works:

You pick a number (seed) and a function that produces a pseudo-random output (the authentication key) based on an input. You program the same seed and function into both the card and the server.

When you go to log in, you have your credit card use the seed and function to generate a key (key1). You send key1 to the server. The server then takes the seed and function it has on record and also generates key1. If the outputs match, which they should, congratulations, you've authenticated.

Each time you request a key from the card, the card uses the last key generated as the input to the function to generate the next key. Each time you successfully authenticate, the server stores the key you authenticated with and the next time you try and authenticate it feeds that key into the function to generate the next key. Since both the card and the server know the last key they authenticated with and the function to compute the next key, they can both compute the next key.

Seed->run function->key 1
key 1->function->key 2
key 2->function->key 3

Etc, etc. The card and the server continue to generate the same keys to compare - so getting a new key is not based on TIME, but on how many authentications you've attempted.

In practice, the server generally accepts the next key, AND some number of keys after that. So, if the last time you authenticated with key315, the next time you authenticate the server will check the key you present against not only key316, but also key317,318,319,320, etc. If the key you present matches any of those, it will accept your authentication and store that key as the 'last' key. This is to make the system more usable - in this case, you could generate 4 keys and not use them before your card would be too far out of sync with the server to succesfully authenticate.

Re:The cycle is INFINITELY long.

[fwr]

You are describing another synchronous token system, everyone else is describing a more familiar synchronous token system. Both are valid and existing technologies. There are also asynchronous token systems. TFA says:

"VeriSign was expected to announce a deal Tuesday with Innovative Card Technologies Inc."

and

"That code constantly changes, meaning the customer needs to have possession of the card to access the account."

Now, ICT says this:

"InCard has embedded an operating system into the card - the press of a button on the card activatesa battery, circuit, and chip, which sends an algorithm-generated passcode to an embedded display. Each time the button is pressed, another passcode is generated. This passcode is good for only one use during a limited time, thus proving possession of the card and guarding against electronic fraud."

and:

"OTP generated with OATH or custom algorithm"

This certainly sounds like a counter based synchronous system, but is it? How can it be "good for only one use during a limited time" if time is not a factor? What would stop you from generating a code, writing that down, and using it days or weeks later. I'm not pointing this out to question the security of the device, as I believe they would still be secure (just don't generate codes and write them down where they can be stolen along with your card number!). I'm pointing it out because it leaves one to question whether this is truely a counter based synchronous system.

OATH's definition of a OTP token is the industry standard:

"OTP (One Time Passwords) authentication (commonly used today) can be divided in two
types; synchronous (based on a transformation of a common shared secret and a moving
value that is synchronous on both the server side and the client side. This method is what
usually is referred to as OTP) and challenge-response (in which a server generates a
challenge value that will be transformed by the client based on a secret shared between
the client and the server)."

They call asynchronous authentication challenge-response, it it's all the same. The OATH Reference Model does say this:

"OATH has endorsed a new OTP algorithm standard called HMAC-based OTP [HOTP],
based on the HMAC SHA-1 algorithm. It is an event-based OTP algorithm, in which a
counter value is used in the OTP calculation and incremented on the client and server
after each use. The algorithm has been submitted to the IETF for standardization as an
Informational RFC. Areas of future work include possible extensions to the current HOTP
algorithm, such as:
  Time-based OTP algorithm variant
  Counter-based re-synchronization method for clients that can send the count value to
the server along with the OTP value
  Composite shared secrets (e.g., based on user PIN or other deterministic data for
computing the shared secret)
  Addition of a data field for computing OTP values
Additionally, OATH will also look to promote standardization of other low cost
authentication technologies, specifically targeted towards consumer usage scenarios.
Some of the areas that OATH is investigating include scratch-cards and methods
derived from battleship or bingo cards."

So it certainly looks like your guess that we are talking about a counter based system rather than a time based system is accurate. However, it's still a guess; until more information is available we just won't know. Did Verisign specify their own algorithm that is time based as ICT says they can support (the alternative algorithm, not necessarily anything that requires a clock)?

Re:CVV?

[jmn2519]

Because the number will change every minute or so. Just like the FOB from paypal. Basically what they are doing is taking that FOB with the LCD and changing the form factor to be a credit card (complete with mag stripe). Someone could steal your CVV or trick you into giving it to them. That becomes a lot more difficult with these one time passwords when the number changes all the time.