You are not logged in.
Do you know the console mode password login?
First it says "Username:". Then you type the username. Then you type enter. Then it says "Password:". Then you type the password, which isn't shown on screen.
Sometimes after you press enter after typing the username, it's slow, and I already start typing the password but instead of being not printed, the first few letters are instead shown in the terminal.
Imagine my username were bob and my password swordfish. Sometimes I type too fast and then I get the following output on the screen:
Username: bob
swPassword:
And then it says "incorrect login" because it only registered "ordfish" as the password.
The insecure thing is that the first letters of the password are visible!
Why is the computer not fast enough to immediatly register the letters I type as password after I press enter? A human on a keyboard is supposed to be much slower than even the dumbest 1MHz computer...
Offline
Isn't that because your backgrounded daemons are still starting, and all at the same time too?
What does not kill you will hurt a lot.
Offline
It happens to me as well, even long after the computer is finished booting.
Offline
I think this is indeed a security measure.
Its slowed on purpose so a machine needs more time, when it tries to crack a password.
Last edited by Bestiapeluda (2008-04-07 18:46:52)
Offline
This happens here on the first trial. Sometimes the computer runs slowly when I'm doing something in that background and I start typing the password in a virtual terminal even before it asks for the password.
So it doesn't have to be the second trial. The only solutions is to be more attentive and make sure it asks for the password before you start typing it in.
Offline
It happens to me as well, even long after the computer is finished booting.
I see this too.
If you have your system automatically login (via. mingetty, kdm...), and then maybe locking the session, you will get similar security minus that lag, and you can start into a running x session too.
Offline
I think this is indeed a security measure.
Its slowed on purpose so a machine needs more time, when it tries to crack a password.
If you type the wrong password, it waits a few seconds before you can retry. I think that's the security measure you mean. That's a fine measure.
But if I press enter after typing the username (not the password, so unrelated to the above security measure), that it then may show the first few keypresses on screen instead of accepting them as password is not very secure imho, as well as being somewhat annoying.
Offline
But if I press enter after typing the username (not the password, so unrelated to the above security measure), that it then may show the first few keypresses on screen instead of accepting them as password is not very secure imho, as well as being somewhat annoying.
While I don't know if the wait in there is hardcoded or it's just due to slowness (I should look at agetty sources, shouldn't be too hard to find this out), I think you just should be a bit patient.
The issue has nothing to do with security: you are not supposed to enter the password at some random time, but only *when you are prompted for it*. You start entering it when you *anticipate that you will be prompted*. To me, it seems more like patience/comfort/practicality issue than security.
Not to sound too negative, it of course used to happen to me as well... well not anymore, since I switched to qingy which fills in the username automatically
Offline
A big kick, but it seems like this (important) issue has been forgotten.
I use laptop-mode on my laptop, which spins down the hd after so many minutes of inactivity. When I need to enter the password when this is the case, i.e. login or sudo, it reproduces the password echoing issue discussed here.
After a few months of witnessing this, I have noticed that the initial command lets the hd spin up again, e.g. sudo <cmd>, and that the moment between entering the echoless password and being able to safely enter it is equal to the spin up delay. When not using laptop-mode, this issue does not occur.
As I use this laptop for presentations, it is a real security threat when several characters of your password are visible.
I can't find any relating bug reports and no forum posts, except for this one. The keywords regarding this issue are very ambiguous, however.
The problem is not a bug of laptop-mode, as it seems to occur with heavy load too. We therefore need a change in the way functions that require passwords are processed, e.g. some sort of symbol that prevents input echo on that terminal until the security kicks in.
Edit:
Found a bug report at last: https://bugzilla.kernel.org/show_bug.cgi?id=21272
Last edited by Firestone (2010-11-05 10:20:00)
Offline
This is an old thread but we'll keep it open for now.
Firestone, i'm not sure that kernel bugzilla report is valid, since this seems more a GNU than a linux problem.
It's not an Arch discussion at least and hard to categorize, so moving to Kernel & Hardware Issues.
ᶘ ᵒᴥᵒᶅ
Offline
I've just found a solution at
http://www.linuxnix.com/2010/03/how-to- … login.html
just edit "/etc/ssh/sshd_conf" file.
uncoment line #UseDNS yes
and change it to UseDNS no
regards
Offline