CDE Screen Lock: No Incorrect Password Entry Notification

[evilmike]

The following is a description of a problem we are currently attempting to solve in our environment involving the error/status reporting during a CDE screen lock.

When the screen is locked in CDE either via the lock icon or inactivity timeout, there is no notification to the user entering his or her password of entry progress.

For example, no asterisk (*) for each character, nothing. The cursor does not move.

In addition, an unsuccessful password entry does not provide the user with any feedback (such as "Password incorrect." or anything like that).

I have searched for configuration files to enable/disable either of these two features, but have not found anything yet.

Successful password entries display an appropriate dialog box requiring confirmation giving information about last successful/unsuccessful logins. The syslog also logs screenlock deactivations with the same unsucc/succ messages. Unsuccessful attempts to break the screenlock cause the "DTSESSION: pamauthenticate status=9" error messages. If the number of unsucc screen unlock attempts deactivates the user, a dialog prompt is displayed with the "Account Disabled" message.

The systems in question run HPUX 11.11 in trusted-mode. In our environment, passwords have to be a specific length, so any "so another user doesn't look over a shoulder and know how many characters are entered" excuse for not displaying password entry progress is not applicable to our environment.

Session logins accurately provide character entry feedback.

Is this a problem with our configuration/installation, something we're overlooking, or "expected/desired" behavior from CDE/PAM/dtsession?

[evilmike]

Maybe I should put this is the system administration thread instead?

[Dennis Handly]

>Maybe I should put this is the system administration thread instead?

Just post a reply to this thread asking to move this thread:
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1141096

[evilmike]

Thanks for the information. Hopefully this problem can get more attention in a different thread.

[evilmike]

... err different forum.

[melvyn burnard]

it is pointless moving it to another sub-forum inside the HP-UX forum, it will get the same visibility

[Robert-Jan Goossens]

Hi,

Could you post your HPUX version and your installed CDE patches.

# swlist -l patch | grep -i cde

Regards,
Robert-Jan

[evilmike]

Thanks for your interest.

HPUX 11.11

Latest CDE patches:

PHSS_33325
PHSS_34101

We are on a lengthy "watch-and-wait" cycle for patch implementation at our site. I was unable to find a CDE patch that addresses the (possible) problem. If a patch is suggested, I would like to know what item in the patch notes addresses this (possible) problem.

At this point I am not sure if what we are experiencing is a problem or expected CDE behavior. Should you see "*******" as you type your password after a screenlock (locked by "dtsession" instead of "dtscreen" - using either the blank or transparent screen lock)? Shouldn't there be more informational messages for failed attempts?

[Robert-Jan Goossens]

---
If you try to log in to CDE you are refused at the loginmask (dtgreet) and
informed by a separate window that the user or password are wrong:

"Login incorrect; please try again"
---

above message should be printed on the screen afeter a failed login.

Could you run following script and look for Error messages?

# /usr/contrib/bin/X11/dr_dt

[A. Clay Stephenson]

This is not Windows. UNIX (whether within a GUI or not) almost never echoes anything including *'s when passwords are entered. One thing that is not so obvious is that the root password will unlock any user's CDE session --- and entering the root password does not alter the UID of the session owner.

[evilmike]

To respond to both of you:

1.) The problem is not with login ("dtgreet"), the problem is after login and during the normal session either an automatic screenlock (screensaver) or a user-initiated screenlock (screensaver).

2.) Yes, I know this is not Windows. That being said, almost everything in UNIX is configurable or there is the ability to implement a workaround. Part of the problem is also the lack of any incorrect password entry notification.

While I appreciate the response, comments such as "this is not Windows" are inappropriate replies to a specific technical question. (Just because someone is new to the forums and asking a question does not mean they are inexperienced in the realm of HP-UX or UNIX in general).

Thanks.

[A. Clay Stephenson]

In any event, you seem to be expecting or want Windows-like behavior from a UNIX login and UNIX has never echoed anything at a password prompt --- and this is not configurable unless you count writing a new login as a configurable option. UNIX logins set the terminal device to noecho when reading passwords and absolutely nothing is output to the terminal device as each character is entered. This also means that any bystanders have very little to indicate even the length of the plaintext password. Part of the reason that you don't see *'s or any other obscuring characters is historical. UNIX (unless special steps are taken) normally doesn't read character by character but waits until a linefeed is detected.

[Dennis Handly]

>1) the problem is during the normal session either an automatic screenlock

As Clay said, the root password should unlock it too.

I use xpadlock and all I get is no obvious input box and then a beep on a bad password

[evilmike]

Yes, I am aware that root password can unlock a CDE screenlock.

And no, I am not wanting Windows-like behavior. I have been working with HP-UX for more than 10 years and I understand the way password entry works. That being said, the original point of this post was ask if this was common behavior, and if not, some speculation as to what may be wrong.

Since the echo'ing of character entry is a minor thing to implement, along with the ability to configure many items within CDE, I thought there may be a configuration option to enable feedback to the end-user. I was not sure if the behavior I was seeing was due to CDE configuration, incorrect PAM version or settings, or what would be considered normal behavior.

While I appreciate you taking the time to respond, a response of "That is the expected behavior of CDE" or "There are no options that I am aware of" would have been more helpful.

In fact, your response sounds to me like arrogance mixed with technical insecurity. If you don't know the answer or don't have questions to ask to gain more insight into the problem, then there is no need to respond.

Don't confuse lack of posts or lack of forum points for inexperience or technical ability, especially if you don't have the technical acumen to understand a problem or provide sound advice.

As in there is no actionable advice in this thread, it can be closed.

Thanks.

[V. Nyga]

Hi,

as Dennis mentioned, when audio is aktivated for an user, then he'll hear a beep after a false passwd. That the only feedback I know.

Volkmar