RE: Unrespected Password Problem

Hi all,
 
On this mail I'll give some more feedback on our actual problem, so to not
lead to wrong conclusions.

First of all, the case where the user typed in 3 times a wrong password, we
could not yet reproduce. I'll try to send a consultant to the customer asap,
to clarify this. The customer insist's on this issue, and sends me
printscreens, and all that, but I cannot confirm for sure. And the
consultant that wen't last time, he didn't see that case really, but the
other one. Where the user changed the username after the second failure, and
succeeded login in with that second account, but saw the first username on
the terminal window, and on our application first screen.

So here's my feedback on that second case (changin usernames) :
 
The problem wasn't a security issue at all, but a bug (anoying but not so
critical) in the "ilogin" application. What happens is that "ilogin" sets
the REMOTEUSER variable on the Linux server, with the original username, the
one defined as default in the shortcut, or the first one you set if there
was no default user, and not with the user that finally logged in.
 
I found out, because I could finally reproduce it here, against Fedora Core
4, and there I saw that the Linux user was Ok. (with a "who" from another
session). But the database conection user, was wrong. And that was because
in our programs we use REMOTEUSER if it's set, as the Connection and
Application user. If it's not set, we use the "SELECT user FROM
table_with_one_row". We use the REMOTEUSER because when we run a program
from cli-java or from GASD (in Genero) the Application Server always
connects to the database with the same user, which is the user that runs the
daemon. But we need the real username, which we obtain with REMOTEUSER, when
the user authenticates with HTTP Auth, or any other Auth system we choose.
 
So, the bug can be divided into 2 problems :
 
- upon "ilogin" the internal variable @USER is wrongly set. It always shows
as the original (default) user. This is shown on the ilogin terminal window
and confuses the user. This is not critical, and most of the times we don't
even show the terminal window, in fact we only activated it for debugging
issues.
 
- the major problem is that probably that same @USER variable is the one
that ilogin uses to set the server REMOTEUSER variable. This is only done
with Linux servers, on Unix servers it doesn't populate that variable at
all, as in fact it's not a remote user, but a user from the same server it's
authenticating the login. So I guess, it shouldn't be populated on Linux, as
it's not on Unix, and also the @USER should be populated with the actual
user that logged in.
 
I hope this give's some light upon my previous mail.
 
Florencia
 
-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre
de Florencia Vitale
Enviado el: Jueves, 16 de Febrero de 2006 11:39
Para: [email protected]
Asunto: RE: [fourjs-users] Unrespected Password Problem



Hi Jennifer,


Well, yes, it happened to a customer of us, too.
 
If you search for a thread with subject "Ilogin Authentication problem"
you'll see what I posted. But I got no real answer from fourjs. After
several tests here, in my environment, I found that the username was wrong
on the window header, but the real user had logged in.
 
Then the customer insisted that that was not their case, and they showed me
that not changing the user, but putting the wrong password 3 times, lets the
user log in, with that username, as it's then showed in the firt screen of
out application where we show the username obtained from the database
engine.
 
But after Oliver's answer (see last mail of my thread) I've tried to solve
this issue with our local support. No solution yet !!!
 
Florencia

-----Mensaje original-----
De: [email protected] [mailto:[email protected]] En nombre
de Jennifer Yu
Enviado el: Miércoles, 15 de Febrero de 2006 18:22
Para: [email protected]
Asunto: [fourjs-users] Unrespected Password Problem


Hi All,
 
Has anybody come across the problem where a user may type in any password
and still log onto the Windows Front End?  We noticed this issue in January
2006, but did not have this problem in the previous years of using this
product.  Our wtksrv files have not been modified.  Telnet connection to the
system still checks if the entered password matches what is saved for the
user.
 
Hopefully a solution exists since it is a security problem.
 
Regards,
Jennifer