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/whi
tepapers.aspx?id=701500000008rSe
------------------------------------------------------------
--------------
|