From: "Goswin von Brederlow" <goswin-...@web.de>
Nicolas François <nicolas.franc...@centraliens.net> writes:
On Mon, Jul 20, 2009 at 02:01:27PM -0500, tallg...@austin.rr.com wrote:
I think that you're confusing the requirement that unknown user names
not be logged, because they might be a user's password with the
non-existent requirement that all unknown user names be treated like
"root" and not prompted for a password.
No, I was not mentioning the case where an user types her password
instead
of her username.
If you still think you're right, I'd like to see the source for the
requirement. I've been through a number of formal evaluations as the
vendor lead (IBM) and we never had that requirement under any evaluation
scheme.
I cannot point you to any source of requirements, except mine:
1. root's password should not be transmitted on insecure lines
=> The password should not be prompted if login is on an insecure
line
and login thinks the user might be root.
2. root can mistype her username
=> Any invalid user might be a mistyped "root"
You can run some heuristic:
1) if user exists and is not root then it is probably not mistyped
2) if user is similar to root (like rot) then assume mistyped
3) assume normal user otherwise
What do you do when "rot", "roto", "rott", et alia, exist? Again, you're
leaking user name information and leaving the system open to a (slightly
more limited) User Enumeration attack. In a real evaluation, which is the
claimed justification for this behavior, you don't get to slack off on one
requirement to make up for another.
If root mistypes his user name as kfgerjhfgsdgfvedj I think then we
can blame root itself. Same if root allows a user rot to be created
and then mistypes his name. In the end the user name is clearly
visible. Watch what you type.
The user name in only visible to the user and anyone sniffing the
connection. Since the user knows what they've typed, that leaves packet
sniffers. Conveniently the problem at hand is one of a legitimate root user
entering their password and having it sniffed. This leaves two choices --
1). You prevent the packet sniffer from knowing, with certainty, that they
have the correct root password, by denying access, regardless of the
password.
2). You prevent the packet sniffer from having an opportunity to sniff the
packet by refusing the connection. While this satisfies Nicholas'
requirement, it fails on Human Factors because users tend to type their name
and password in very quick succession. Which now results in the password
being in the "user name" location in the sign on dialog.
In either instance, the layered security of the system protects itself --
unless the attacker has access to a secure TTY, they can get a million root
passwords and they will still be denied access.
3. login should not leak information about the valid usernames on the
system.
=> The user should be prompted a password whether the username is
valid
or not.
We all know there is a root user already so no information is leaked. :)
Not at all -- there are protection profiles where the privileged user must
have the ability to change their name. In those profiles, the name of the
super-user is considered to be privileged information, and having it be
public by making it "root" violates the profile.
I do not think those requirements can be satisfied at the same time.
But near enough.
Well ... I think what's being described is Security Through Obscurity. I'd
still like to see a protection profile which requires the described
behavior. As it stands, the alternatives all permit a User Enumeration
attack of some form or another.
-- Julie.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
