10 Oct
2014
10 Oct
'14
11:51 a.m.
On 10/10/14 11:31, Gilles Massen wrote:
There *is* certainly a good dose of incompetence. But internally, banks
are communicating pretty clearly to their employees that signing stick
and smartcards should no longer be actively supported... although they
don't (yet) make it as clear to their customers... (I got this info from
one branch manager at Spuerkeess...)
Call me a cynic but you are overestimating the capabilities of a bank :)
They might not be very competent in their day-to-day business. But once
there is a bigger amount at play, you can be sure that they *will* do
the effort of finding resources who can pull such a stunt off...
You didn't try hard enough :)
Gilles
I think it will break before it bends...
Alain
On 10/10/2014 11:06 AM, Alain Knaff wrote:
Well, the past years are full of examples where the security model from
banks is more about pushing risks to customers rather than providing
better security (or simple and almost free security measures like DNSSEC
would have been implemented) ...
Exactly... This reminds me of the old days when banks would force users
to use Windows... only so they could claim that the user had a virus if
ever their homebanking system malfunctioned :-)
But keep
in mind that the tokens rely obviously on a weaker security
model (although you may not care)
*We* (the users) do care, but unfortunately *the banks* do not care... Or how else is it possible that one major
Luxembourgish bank took one
year and a half to fix a simple typo in a config file, which prevented
the card & stick from working?
...although I would link that to pure and simple incompetence :/ and are far less flexible. You can use
the stick / cards for your own x509 authentication, sign emails... while
the Token is only useful in situations a provider/LuxTrust agreed to. If
However, this "flexibility" may come back and bite you.
Indeed, the way how banks use the Card and/or Stick carries one major
security risk due to their wrapper written in JNI: this wrapper
completely bypasses Java's security framework, and allows banks to sign
any document in the user's name without the user's knowledge. In a
situation where the bank's and the user's interests are not perfectly
aligned (such as when the user is suing the bank over bad investment
counseling), this is a *major* problem, because the bank could forge any
document "signed" by the user in order to damage his case, and bolster
their own case. This said, I completely agree - that kind of
implementation is just wrong.
Well the issue above is about the stick, rather than the token. As you
said, the token doesn't allow you to sign, so if anybody produced a
signature supposedly made using the token, it would be pretty obvious
that it was fake :-)
So, if you are in *any* kind of disagreement with
your bank, better use
the token, rather than the stick.
Yes. And if you want better security you can still have one token per
application. Not exactly userfriendly, but as long as they are free... So the
token is much like an iPhone :)
Well, at least it doesn't bend... :-)