Small concern in newforms-admin

[Malcolm Tredinnick]

I've been merging the Unicode changes into newforms-admin tonight (won't
be finished until tomorrow; I'm losing willpower) and I came across this
code (in admin/sites.py):

if u'@' in username:
# Mistakenly entered e-mail address instead of username? Look it up.
try:
user = User.objects.get(email=username)
except User.DoesNotExist:
message = _("Usernames cannot contain the '@' character.")
else:
message = _("Your e-mail address is not your username. Try '%s' instead.") % user.username

I'm a little bit concerned by this. It means that if the admin login
page is exposed (for remote login), I (being a hypothetical person of
negotiable morals and principles) can mine for usernames by guessing
email addresses. It's easier to get ahold of somebody's email address
(or guess it using the corporate scheme) than their username, so now I'm
reduced to only having to guess the password.

Not a huge security hole, but not having the option would be less leaky.
It's usually recommended not to report when the username but not the
password is correct in a login attempt. This has the same slight
weakness.

If somebody wanted to add a "I've forgotten my username and/or password"
link, that easy enough to customise anyway, so we're not being complete
bastards by removing this.

Regards,
Malcolm

--
Plan to be spontaneous - tomorrow.
http://www.pointy-stick.com/blog/

[Adrian Holovaty]

On 7/6/07, Malcolm Tredinnick <mal...@pointy-stick.com> wrote:
> I've been merging the Unicode changes into newforms-admin tonight (won't
> be finished until tomorrow; I'm losing willpower) and I came across this
> code (in admin/sites.py):

> [...]

> I'm a little bit concerned by this. It means that if the admin login
> page is exposed (for remote login), I (being a hypothetical person of
> negotiable morals and principles) can mine for usernames by guessing
> email addresses. It's easier to get ahold of somebody's email address
> (or guess it using the corporate scheme) than their username, so now I'm
> reduced to only having to guess the password.

For the record, that's in trunk, too -- it's in
staff_member_required() in django/contrib/admin/views/decorators.py.

I'm fine with removing that special-casing. We originally added it as
a usability feature before Django was open-sourced, because we found
our admin users were attempting to log in with their e-mail addresses,
but I can see how it might be misused.

Because the Unicode merge is going on, it's probably cleanest if we
wait for that newforms-admin/unicode merge, then apply the change to
both trunk and newforms-admin.

Thanks for bringing this up,
Adrian

--
Adrian Holovaty
holovaty.com | djangoproject.com

[Jacob Kaplan-Moss]

On 7/6/07, Adrian Holovaty <holo...@gmail.com> wrote:
> I'm fine with removing that special-casing. We originally added it as
> a usability feature before Django was open-sourced, because we found
> our admin users were attempting to log in with their e-mail addresses,
> but I can see how it might be misused.

Were it totally up to me, I'd leave it in to cut down on the number of
"help me!" calls I get (:P), but I see the security issue, so let's
kill it.

Jacob

[chris....@gmail.com]

I personally don't understand why we can't use email addresses as
usernames.

I know there are work arounds but it seems odd to me that we would
have to do extra steps to allow a user to log in with their email.

Just my $.02

-Chris

On Jul 6, 10:59 am, "Jacob Kaplan-Moss" <jacob.kaplanm...@gmail.com>
wrote:

[James Bennett]

On 7/6/07, chris....@gmail.com <chris....@gmail.com> wrote:
> I personally don't understand why we can't use email addresses as
> usernames.

You can, you just need to roll your own form.

--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

[Tai Lee]

indeed, many people prefer to login with their email address, or use
their email address as their username. that way they're not likely to
forget it, and can use the same one which is guaranteed not to be in
use by anyone else across all their sites. rather than having to
remember multiple usernames for different sites, sometimes having to
make less than ideal choices if their preferred username is already
taken, etc. was the reason for removing the ability to use emails as
usernames just to reduce the probability of usernames being guessed? i
would have thought that should be the edge case rather than the rule,
and developers could add their own validation rules to usernames if
they don't want email addresses in there.

[Marty Alchin]

To me, it boils down to something quite simple. Django's built-in auth
system uses usernames for identifying users, and email addresses as a
way to communicate with those users.

Yes, it might well be better for some sites to use email addresses as
the username, but in those cases, you would want it to be just that:
email addresses *as* usernames. You wouldn't want separate usernames
at all.

So, like many other things these days, it comes down to a bikeshed.
The Django authors built theirs the way they'd like it built, because
it's what they needed for what they were doing. If you need your own,
you're more than welcome to build your own, possibly using theirs as a
base. But it seems pretty senseless to be discussing which way should
the official distribution should be done, since it's pretty obvious
that the way it will be done is the way it's already being done.

-Gul

[Kevin Menard]

On 7/7/07, Marty Alchin <gulo...@gamemusic.org> wrote:

> So, like many other things these days, it comes down to a bikeshed.
> The Django authors built theirs the way they'd like it built, because
> it's what they needed for what they were doing. If you need your own,
> you're more than welcome to build your own, possibly using theirs as a
> base. But it seems pretty senseless to be discussing which way should
> the official distribution should be done, since it's pretty obvious
> that the way it will be done is the way it's already being done.

I'm not sure that makes a large amount of sense, so please correct me
if I'm wrong. But, if n users want to be able to use email addresses
as usernames but m developers are indifferent to it, where n is likely
to be magnitudes larger than m (just because m is small), then n
different people should all do it themselves and not bother with a
feature request? I guess I just don't understand how it can be
considered futile for users to try to enhance a feature added 3 years
ago *shrug*

--
Kevin

[Todd O'Bryan]

On Mon, 2007-07-09 at 08:09 -0400, Kevin Menard wrote:
> I'm not sure that makes a large amount of sense, so please correct me
> if I'm wrong. But, if n users want to be able to use email addresses
> as usernames but m developers are indifferent to it, where n is likely
> to be magnitudes larger than m (just because m is small), then n
> different people should all do it themselves and not bother with a
> feature request? I guess I just don't understand how it can be
> considered futile for users to try to enhance a feature added 3 years
> ago *shrug*

I have a backwards-compatible suggestion...

It seems that for people who want to use the email address as the
username, the username field becomes superfluous. What if we had a
setting that defaults to False called USE_EMAIL_AS_USERNAME. If it's
true, you fiddle around with the User model to make everything that
accesses or sets the username field use the email field instead. The
admin might be a little weird, because you'd see the email twice, but it
should be doable.

All that said, I don't need this, so somebody else would have to write
the patch. :-)

Todd