9 Oct
2014
9 Oct
'14
10:12 a.m.
Hello,
After a long time without using my LuxTrust signing stick, now that the
banks are forcing us to use the LuxTrust technologies, I am strugling
again with this issue.
I have tried two different set ups:
1.- Ubuntu 14.04 32-bits.
2.- Debian Jessie 64-bit.
I am using the latest Firefox (32.0.3) and the latest version of Oracle
Java 7 (should I upgrade to 8?).
In both cases the Gemalto PIN changer recognises the stick and I am able
to change the PIN.
In the 64-bit system I needed to to this in order to fix the Java issues
at the S-Net login page:
http://michel.weimerskirch.net/blog/2014/06/17/fix-for-luxtrust-login-on-sn…
However, the list of the sticks is void in Firefox and therefore I can
not log in.
Puzzlingly, I have not problem within an old 32-bit Windows XP
VirtualBox installed in the Debian system...
Any suggestions?
Best regards,
Miro
--
http://prosciens.com
9 Oct
9 Oct
6:30 p.m.
On 09/10/14 12:12, Miro Moman wrote:
Any suggestions?
Yes ;)
I know this is the simply way out, but just order one of the free
Tokens. It works on any platform and even though you need to take your
token everywhere (whereas the code-card I could simply keep in memory)
you won't need to have a smartcard reader everywhere you're planning on
doing some webbanking.
Best regards,
David
10 Oct
10 Oct
7:51 a.m.
On 09/10/14 20:30, David Raison wrote:
On 09/10/14 12:12, Miro Moman wrote:
Wise decision.
And usually, the code card still works when the banks screw up and fail
their deployment of a new version of Lustrust wrapper.
As most people out there have the token rather than the card or USB
stick, banks pay more attention to keep the token working, whereas for
the card or stick they are not at all in a hurry to fix problems.
For all practical purposes, consider that the smartcard and USB stick
are no longer supported, except for niche applications (such as some
internal stuff at the Lux. government).
Regards,
Alain
Any suggestions?
Yes ;)
I know this is the simply way out, but just order one of the free
Tokens. It works on any platform and even though you need to take your
token everywhere (whereas the code-card I could simply keep in memory)
you won't need to have a smartcard reader everywhere you're planning on
doing some webbanking.
Best regards,
David 
8:55 a.m.
On 10/10/2014 09:51 AM, Alain Knaff wrote:
For all practical purposes, consider that the smartcard and USB stick
are no longer supported, except for niche applications (such as some
internal stuff at the Lux. government).
For webbanking and general simplification of life, yes. (not as if there
were any alternatives...)
But keep in mind that the tokens rely obviously on a weaker security
model (although you may not care) 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
only there were a proper Linux support for the sticks...
So the token is much like an iPhone :)
best,
Gilles
--
Fondation RESTENA - DNS-LU
6, rue Coudenhove-Kalergi
L-1359 Luxembourg
tel: (+352) 424409
fax: (+352) 422473
9:06 a.m.
On 10/10/14 10:55, Gilles Massen wrote:
On 10/10/2014 09:51 AM, Alain Knaff wrote:
*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?
For all practical purposes, consider that the smartcard and USB stick
are no longer supported, except for niche applications (such as some
internal stuff at the Lux. government).
For webbanking and general simplification of life, yes. (not as if there
were any alternatives...)
But keep in mind that the tokens rely obviously on a weaker security
model (although you may not care) 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.
So, if you are in *any* kind of disagreement with your bank, better use
the token, rather than the stick.
only there were a proper Linux support for the
sticks...
So the token is much like an iPhone :)
Well, at least it doesn't bend... :-)
best,
Gilles
Regards,
Alain
9:31 a.m.
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) ...
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.
You didn't try hard enough :)
Gilles
--
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. 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... :-)
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... :-)
6:34 p.m.
OK, now the token is working everywhere and the stick is working only in
a Windows virtual machine.
I still do not understand why the stick is working perfectly in the
Windows VM within a Linux host and yet it is not working at all in that
very same Linux host...
On 10/10/2014 01:51 PM, Alain Knaff wrote:
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
_______________________________________________
Lilux-help mailing list
Lilux-help(a)lilux.lu
https://www.lilux.lu/mailman/listinfo/lilux-help
--
http://prosciens.com
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... :-)
4042
days inactive
4043
days old
7 comments
4 participants
participants (4)
-
Alain Knaff -
David Raison -
Gilles Massen -
Miro Moman