Re: Small Bug
"Guy's Account" <guy@interlog.com> writes:
> This is not security by obscurity. It is long-established practice.
It might well be "long-established practice". But I still agree with
Marcus that it (usually) is security by obscurity.
To get a little further, I'll try to define "security by obscurity".
We have some information (in this case, user names), that the security
model considers as "public knowledge". This means that the security
model admits that a serious attacker is likely to have some or all of
this information handy before mounting an attack. For instance, she
might have scanned related mailing lists or webpages for
email-addresses, obtained lists of standard usernames that are
installed by default by the operating system or other popular
components, or socialized with some of the users.
This is also a question of user expectations; we usually try to
educate users that passwords are secret, but we don't say that
usernames are secret (and I suspect the latter would be quite a hard
task. "If my password is secret and my user name is also secret, why
do I need both?").
To say, in the security model, that some information is "public
knowledge" is a way to express that we don't want security to depend
on the information being kept secret. We want the system to be secure
enough (whatever that happens to mean to us) even if the attacker has
been able to get all the "public information".
I'd define "obscurity" as any steps taken in order to keep
information, which is classified as "public information" in the
security model, secret from attackers (or even secret from ordinary
users).
Note that, by this definition, "security by obscurity" is a
contradiction in terms; on one hand we assume that attackers *already*
know the "obscured" information, on the other hand we're trying to
keep it secret.
/Niels
> > The user login name is often very exposed, for example in email addresses,
> > log files etc. If you already have an account, you can usually just list
> > /home to get all user names of a system.
>
> But the problem pointed out allows an attacker *without* an account to gain
> information.
Reply to: