Hi Thierry,

...

I made an accout with name "jürgen", password "jürgen" and the home directory is named "jürgen" too (for testing purpose only).

Without tdm i.e. from a console I can login without any problems, but TDM-Login says "wrong password"

How is your keyboard setup (in TDE)?

When I install, TDE defaults to US keyboard and I have to install the swiss keyboard (Trinity Control Center -> Regional & Accessibility -> Keyboard Layout). Of course you probably have it in German...

AFAIK is this setting for the user when logged in and not for TDM to login.

In tdm I set the language to german as well, but this only effects the messages shown.

Console keyboard is probably controled by your distribution's settings.

Yes.

I don't advise using accented letters in passwords and filenames (although I do use @, but I know where it is on the US keyboard). But you can set a provisory password, change the keyboard, then the password.

AFAIK only user names starting with a number are really forbitten and the user name is not the problem. It seems, that tdm dosn't like the Umlaut in the password.

Fine regards Rolf

Actually I tried, and it seems there is nome bug:

a) Created a new user names dödö with kuser - no problem

b) Tried to switch user: login failed, whatever password I give (name is shown as "dödö", maybe that's a clue for someone)

c) Created a new user dodo, with pasword 123456 - works

d) changed password for dökülä - login failed

Both new user login as text outside TDE

So there is some problem with accented caracters in TDE login (which of course is, in my opinion, a really secondary problem as you just have not to use these there, but there is indeed a problem).

Mostly, kuser should not accept names or passwords that it won't accept later.

Thierry

On Saturday 18 August 2018 12.52:31 E. Liddell wrote:

On Sat, 18 Aug 2018 10:48:19 +0200

Thierry de Coulon tcoulon@decoulon.ch wrote:

...

b) Tried to switch user: login failed, whatever password I give (name is shown as "dödö", maybe that's a clue for someone)

Well, that part looks like a classic codepage hiccup--what's the system locale?

E. Liddell

System locale is en_GB.UTF8 and TDE locale is US English

Thierry

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On 2018/08/19 08:53 AM, J Leslie Turriff wrote:

On 2018-08-18 03:48:19 Thierry de Coulon wrote:

...

Mostly, kuser should not accept names or passwords that it won't accept later.

Thierry

I agree; this looks like a consistency error.

Leslie

Hi all, if this is something that can be reproduced consistently on a new user account, it means it is a bug. Please report it to bugzilla and add exact instructions to reproduce it :-) Cheers Michele

Am Samstag 18 August 2018 schrieb Rolf Schmidt:

AFAIK only user names starting  with a number are really forbitten and the user name is not the problem. It seems, that tdm dosn't like the Umlaut in the password.

Yes. It's certain characters in the password. I had this problem long ago with a password containing the character '§'. tdm just wouldn't start regardless of the language setting (for tdm) but always break the login process. (Forgive me for not reporting then).

Just checked again: '§', 'Ä', 'ß', '€' don't work -- maybe everything that is utf8 or not ascii?!

Just changing that single character "solved" it, meaning it is a bug as tdm should be able to process every password that was configured in a console session.

M2C

Kind regards, Stefan

Am Donnerstag 23 August 2018 schrieb Michele Calgaro:

Bugzilla report created. https://bugs.pearsoncomputing.net/show_bug.cgi?id=2961

Cheers Michele

Thank you, Michele. Next time I'll try to be quicker ;-)

Stefan

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

On 2018/08/24 03:49 AM, Rolf Schmidt wrote:

Am 23.08.2018 um 13:42 schrieb Michele Calgaro:

...

Bugzilla report created. https://bugs.pearsoncomputing.net/show_bug.cgi?id=2961

Thank you, but I would ask, if tdm passes the login data to pam and pam makes the mistake?

AFAIK pam handles Umlaute correct, as you can see with a console login.

With kde3 there was a pam module for login with kdm - I used it years ago.

Fine regards Rolf

At this moment I have no idea of what is going on behind the scene. When we look at the bug, we will know better :-) Cheers Michele

On Monday 03 December 2018 09:12:48 Thierry de Coulon wrote:

On Monday 03 December 2018 16.18:37 Michele Calgaro wrote:

...

The problem with login when the password has special characters (accents, umlaut....) has not been fixed in R14.0.6-dev and R14.1.0-dev. https://bugs.pearsoncomputing.net/show_bug.cgi?id=2961

I have made a rule to *not* use accents, special characters or spaces in *nix (passwords, filenames and so). Once you've got used to this life is easier (I do use @ in password though).

This sort of things also brings problems when you copy between different OSes.

Thierry

N.B. Just so I don't hijack this thread, I have changed the heading a little. If readers have quality complaints, please direct them to the usual places.

I gave up on accents, special characters, etc., a long time ago, for filenames, etc., in *nix systems. As the spelling of my surname, in some German instances, contains an umlaut (long since lost), and as there are some who may want to preserve such items, I avoided comment. However, the trouble it causes in *nix systems, or in transferring files among different systems, is not worth it.

For passwords, however, (and NOT login names), I totally disagree. All those quirky characters help to protect your security from script kiddies with password crackers. The difference between brute-force cracking a passwords of, say, 10 characters, varies between something like 2 hours and 20 million years, when the only difference is using all those "extra characters".

I read all this somewhere, and don't have any direct practical experience of password cracking; except once, about 20 years ago now, when my own password got cracked - after which, I set myself to learn Linux and make for myself a more secure system. So don't try to pin my down on my authority for this statement; but if I must, I will look up some references on password security just to prove my point that I am an insufferable pedant.

Most *nix systems, so far as I know, don't have problems with "extra characters" for passwords (but I haven't tried umlauts). I did note that Q4OS, though, would not allow me to use extra characters on its first installation; I never got farther than that, and looked for something else, and hope that this isn't a sign of things to come (i.e., less secure passwords).

Bill