From: Javier Fernández-Sanguino (jfernandezgerminus.com)
Date: Mon Aug 13 2007 - 13:10:36 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Robin Wood dijo:
> Hi
> I'm developing a application which requires users to sign up with both
> a username and an email address. I only want an email address to sign
> up once and don't want duplication of usernames.
>
> If I just put up a warning stating that an email address is already
> registered if it is, the form is open to being used for user
> enumeration. Apart from using things like captchas to try to defeat
> automated attacks, is there any way to stop this?

Introduce a generic error. Don't give two different messages: the
'username already exist' and 'the email address is in use'. But just
give one 'the username or email address already exist, please change
it'. Might sound stupid, but it's (slightly) more work for the attacker
  to see which one is actually in use.

Make it increasingly difficult to do user enumeration by introducing:

- a delay for each test, increase the delay for each test coming from
the same location

- a maximum number of attempts from a given source. If there are N
attempts at signing up from the same source, trigger an internal alarm
and add the source to a blacklist and don't allow new sign ups until a
given delay goes through.

The tricky part here is 'location'. Location could could be the source
IP address, or the client's Forwarded-For HTTP header, or a specific
client identified by a Cookie or by a rewritten url with a server session.

As you are developing a system users need to sign in (and use of
client-tracking mechanisms is expected) you can try to defeat automated
attacks by forcing users to use the tracking mechanism of your choice
(cookies or URL rewritting with a session id). Tell clients that do not
allow this kind of tracking (e.g. don't store cookies or don't allow
redirects to rewritten locations with a session) that they need to
enable that if they want to work with you. Explain to the user why
tracking is needed id.

Of course, a malicious user could just generate M different sessions and
use them in parallel to brute force you, but each session just gives him
N*M consecutive attempts (with an increased delay between each attempt).
Just make sure your session generation code's delay is *larger* than the
minimum delay introduced for each attempt or, otherwise, a malicious
user will just generate many sessions for enumeration and discard them
after one use, as this would be faster than trying to reuse each session.

The alarm above and careful monitoring the # of sessions generated by
the web server app and comparing this with a baseline (i.e. the average
number of sessions your server handles) could be useful to detect these
kind of attacks whenever they happen.

Hope that helps,

Javier

-------------------------------------------------------------------------
Sponsored by: Watchfire

The Twelve Most Common Application-level Hack Attacks
Hackers continue to add billions to the cost of doing business online
despite security executives' efforts to prevent malicious attacks. This
whitepaper identifies the most common methods of attacks that we have seen,
and outlines a guideline for developing secure web applications.
Download today!

https://www.watchfire.com/securearea/whitepapers.aspx?id=701500000008rSe
--------------------------------------------------------------------------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]