Re: preventing sign up forms from being used for user enumeration

[Javier Fernández-Sanguino <jfernandez () germinus com>]

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
--------------------------------------------------------------------------