security and online banking

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

Hey all!

My bank has this system for internet banking.
It works with the chip in my bankcard.
The card is placed in a device at home.
On the login screen there will be a code which have to be typed in in
the device.
Than the device will ask me my PIN code.
These two combined will produce a number.
The number is than typed in in the login screen.
I can <presumably> securely do my banking.

Probably this is a proven system, and there are a few things I like to know.

1. how does this all work on the "other side". (how is my PIN code
safeguarded for example)
2. whats the name of this kind of method
3. isnt this vulnerable to a man in the middle attack
4. how save is it actually?

Thanks all!
Greets, Ruud

Re: security and online banking

On Thursday 14 January 2010 00:00 in, somebody
identifying as wrote...

Quoted text here. Click to load it

It isn't.  Your PIN code is only used by the device in combination with
the code you must enter into the device in order to calculate the
access key.  This access key will be different every time, and thus you
will be getting a different code to enter into the device with every
time.  It's a kind of variable hash system.

Quoted text here. Click to load it

No idea.

I don't think so, since the code you must enter to log in is unique and
can only be verified by the bank's server for its validity.  The only
possible "man in the middle" attack would be if someone were sniffing
your connection, but presumably (and hopefully) the whole thing passes
over https, so it'll be encrypted.

Quoted text here. Click to load it

I would imagine that it's pretty safe.  Yet, you never know, of
course. ;-)

(registered GNU/Linux user #223157)

Re: security and online banking

Quoted text here. Click to load it

Schneier on Security
A blog covering security and security technology.
Hacking Two-Factor Authentication

These are my opinions, not necessarily my employer's.  I hate spam.

Re: security and online banking

Quoted text here. Click to load it

Ahh. Look up "Secure keys" and RSA. There are dozens of slightly
different schemes for doing this, but most of them boil down to the
bank verifying that they are, indeed, the bank by providing a
timestamp signed with their public key (that signature is what you see

Quoted text here. Click to load it

Right. Your PIN code unlocks access to a private key in your device.

Quoted text here. Click to load it

Right. The timestamp provided by the bank, ideally along with a public
key provided by the bank in their transmission as well, is used to
sign a signal to send back to the bank. They can unencrypt it with
their private key, and verify that your signature on their timestamp
in fact matches your assigned public key. This way, you and the bank
are only sending information back and forth to each other that is
authenticated with the public keys, and generated with the private
keys, in a way that prevents anyone else from authenticating it or
tapping it.

Quoted text here. Click to load it

The bank never sees it. It's processed in your little key, locally.
Your PIN just *unlocks* the private key, ideally. I think that, to
reset the code, you actually have to take the key to the bank and put
it in a device there.

Quoted text here. Click to load it

A lot of clever people have spent a lot of thought on these things.
I'd worry more about some jerkwad stealing your credit card or debit
card numbers.

Re: security and online banking

On Thu, 14 Jan 2010 02:59:58 -0800 (PST), Nico Kadel-Garcia wrote:

Quoted text here. Click to load it

Not to mention the criminals writing malware to get around those things.

Quoted text here. Click to load it

Or if running Micro$oft, malware making withdraws while you are
connected to the bank. Malware even masks the transaction from
web page.

Re: security and online banking

Nico Kadel-Garcia wrote:

Quoted text here. Click to load it

I don't think they will be using any sort of public key system for this for
three reasons:

1 - implementing public-key encryption and decryption needs more processing
power than they would want to put on a chip-and-pin card.

2 - public key would only be useful if the system is both encrypting and
decrypting. An entire block of encrypted data would have to be input to the
handheld device by the user and perhaps copied back. With RSA, this would be
well over 100 digits. I believe there are other public key systems that are
better but not enough to make this practical.

3 - public key techniques aren't needed for this job.

I'd be pretty certain they do something like the following:

The chip-and-pin card contains a symmetric block encryption engine and a
unique secret key which is also known to the bank. For example, AES might be
used with a key and block size of 128 bits or more. (Or they might use
triple-DES. Google for details.)

The card requires a PIN to be entered before the encryption engine and
secret key can be used.

The bank sends a challenge of some number of digits which the user types
into the handheld device. Enough digits are used to make it unlikely that
the same challenge would ever be sent twice.

The device pads this to the encryption block size (e.g. with zeroes) and
asks the card to encrypt the block.

The device then shows digits from known positions in the result - enough to
make it unlikely that they could all be guessed correctly by an attacker.

The user sends these back to the bank.

The bank does the same process using the secret key that it also knows and
compares the digits. If they match, the bank knows that the user has the
card and they must have input the correct PIN to unlock it. This is a form
of two-factor authentication - the user has something (the card) and knows
something (the PIN).

It doesn't really protect against a man-in-the-middle attack. For example,
the user could connect to a malicious website instead of the bank's one and
think they are paying their phone bill. The malicious website connects to
the real bank website and requests to transfer all the money in the account
to Russia. When the bank sends the challenge, the malicious website shows
this to the user and relays their response to the bank.

There could only be protection against this if the challenge said something
to the user about the transaction that the bank thinks they are authorising.
That would make the challenge too complex for the user to copy reliably.

Instead, the bank can use a fallback system such as calling or texting the
user with details of the amount and/or destination of their money (if it's
something unusual) and having them authorise this either by answering the
message or inputting a code in the message to the website.

Steve Hayes, South Wales, UK
----Remove colours from reply address----

Re: security and online banking

Quoted text here. Click to load it

actually quite a bit of work was done on that in the 90s, as part of the
x9a10 financial transaction standard working group (had been given the
requirement to preserve the integrity of the financial infrastructure
for *ALL* retail payments).

we had been asked to consult with small client/server startup that
wanted to do payment transactions on their server ... the startup
had also invented this technology called SSL they wanted to use.

we had been called in to consult with a small client/server startup that
wanted to do payment transactions on their server ... the startup had
also invented this technology called SSL they wanted to use. Part of the
effort was deploying something called a "payment gateway" (we
periodically claim is the original SOA) ... misc. past posts

the effort is now frequently called "electronic commerce". given the
ease that crooks can harvest account numbers and use them for fraudulent
transactions ... I drew up a list of things required for commerce
servers enabled for payment transactions ... like all individuals
involved in any way needed to have FBI background checks (type required
of individuals in sensitive positions at financial institutions).  part
of this was that long term numbers claim that insiders are involved in
70% of such events.

related comments about current paradigm in threads about "naked

somewhat as the result of the work on "electronic commerce", in the
mid-90s we were invited to participate in the x9a10 financial standard
working group. as part of that activity there was detailed end-to-end
threat & vulnerability studies done of different kinds & modes of retail
payments. the *ALL* was things like point-of-sale, attended, unattended,
credit, debit, stored-value, gift card, contact, contactless, internet,
wireless, transit turnstyle, aka *ALL* (as well as most online banking
transactions). The transit industry had requirement that the operation
be able to be performed in the limited power (of contactless) and
elapsed time (small subsecond) of transit turnstyle ... and also be very

I had semi-facetiously joked that I would take a $500 milspec part and
aggresively cost reduce by 2-3 orders of magnitude while improving on
the security (while also being able to satisfy the transit turnstyle
contactless power and elapsed time requirements ... as well as cost

In any case, x9a10 slightly tweaked the paradigm for x9.59 standard

and also eliminated the requirement for hiding the account number and
transaction detail.

Now, the largest use of SSL in the world today is the previous work
related to "electronic commerce" for transaction encryption as part of
hiding account number and transaction detail ...  however, x9.59
standard eliminates the need to hide that information ... and so would
also eliminate the major use of SSL in the world today.

40+yrs virtualization experience (since Jan68), online at home since Mar1970

Re: security and online banking

[ Fascinating history ]

Hee-hee I love this group: actually seeing the people involved in
developing a technology writing on their role is wonderful.

And for a more detailed analysis on one of the most popular security
key technology, look at . As the
article points out, man-in-the-middle isn't the big risk, "Man in the
Browser" attacks are.

Re: security and online banking

in mid-90s ... there were various presentations by dial-up online
banking organizations. the consumer banking organization were talking
about moving to the internet (& using SSL) ... a major reason was that
it offloading the enormous customer support costs for (serial-port)
dialup modems to the internet service providers (presentations about
some operations having libraries having greater than 60 different
software drivers for their dialup banking software, and large customer
call center support costs). side-issue was that the ISPs could amortise
all of that support across a much larger market ... rather than just
dialup online banking (and as it turns out, the much larger internet
market, prompted vendors to work out lots of the serial-port dial-up
modem problems and started including tested support in original product
... instead of it being an aftermarket problem).

however, the cash-management, commercial/business dialup online banking
operations said that they would never move to internet (even if they got
128-bit SSL instead of 40-bit SSL) ... because of a long list of threats
of vulnerabilities; nearly every possibly kind of exploit that has
occured in the past 15 yrs was already on their list in the mid-90s (as
reasons for not moving to the internet).

40+yrs virtualization experience (since Jan68), online at home since Mar1970

Re: security and online banking

Steve Hayes wrote:
Quoted text here. Click to load it

This is exactly what I thought would be the simplest method.
The only thing more simple is drug someone down and hit them on the head
with a wrench till they give their PIN :-) [yes xkcd rules :-)]
Good to hear that its all quite save, as long as the normal precautions
are obeyed. (like keeping a watchful eye out for people with drugs and
wrenches :-)

Quoted text here. Click to load it

Re: security and online banking

Quoted text here. Click to load it

old posts (in sci.crypt) driving down to visit the company that makes
the devices (halfway between amsterdam and brussels) ... and then
driving on down to brussels for EU FINREAD standards meeting Internet banking PKI/Digital signature doesn't work

finread URL reference in the above has gone 404, but wayback
machine can be your friend /

finread from the later part of the 90s was to address significant
portion of the things that the cash management/commercial dialup online
banking operations highlighted as major vulnerabilities ... including
whole slew of end-point compromises of PC (in some sense ...
countermeasure was to move the end-point to the finread device).

finread got caught up in the disaster of some hardware token deployments
from the period and the resulting widely spread opinion in the financial
industry that chipcards weren't practical in the consumer market.

the deployment disasters turned out not to be with the actual hardware
tokens ... but with the card acceptor devices (card readers) that were
given way as part of the programs. it appeared that they got a lot of
obsolete serial-port devices (for the give-away) and ran into the
enormous customer support issues/problems that had earlier motivated
dial-up online banking to move to the internet (apparently the financial
institutional knowledge about serial-port support problems had
evaporated in the few short years between move of online banking from
proprietary dial-up to the internet ... and the smartcard deployment

40+yrs virtualization experience (since Jan68), online at home since Mar1970

Site Timeline