On 10/10/2014 11:06 AM, Alain Knaff wrote:
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...
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) ...
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.
Call me a cynic but you are overestimating the capabilities of a bank :)
This said, I completely agree - that kind of implementation is just wrong.
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... :-)
You didn't try hard enough :)
Gilles
--