Built-in captcha control is easily circumvented, fails to stop spam

What steps will reproduce the problem?
1. Create a form with a captcha and a validator for it
2. Submit the form with a valid captcha
3. Try to submit the same form again by pressing F5/refresh in your browser

What is the expected output? What do you see instead?
One would expect that you can't use the same captcha token twice and submit the 
form for a second, third, etc. time. However, in fact you can do that.

What version of the product are you using? On what operating system?
Prado/trunk

Please provide any additional information below.
The problem with this is that it makes captcha practically useless in 
scenarious where you can initiate an action just by a single submit (for ex. 
because you can supply all neccessary parameters in a single form, or it is 
enough to alter only the properties of the form supposedly protected by the 
captcha, even if you need to do multiple submits afterwards), as once a - most 
likely human user - has broken the captcha image successfully, they will be 
able to submit the same form any number of times consecutively, which defeats 
the purpose of having the captcha check (to prevent spamming) in the first 
place.

Setting the TestLimit property or calling regenerateToken() after a successful 
submit are useless in this situation, because when doing a repeated submit, not 
the current but the previous pagestate is used again (the pagestate prior to 
the first submit), which means that both the token and the test count will be 
the same as for the first time. 

Also TokenExpiry has limited use, as you must set it to a reasonable limit for 
a user to actually be able to enter the captcha's characters - however, in that 
reasonable time dozens, hundreds or even thousands of repeated submits can be 
generated programmatically, or even just manually.

A possible solution could be to alter the captcha control so it stores the 
generated tokens in an application- or session-level global storage (instead of 
the pagestate/viewstate), and once the captcha has been used to successfully 
submit a form, it should remove the used tokens from that storage, thus 
preventing further use of them. However, as I currently can't imagine any way 
to differentiate between successful and failed submit at the 
component/framework level, that means that the captcha control should have a 
method added them which in turn could (and should) be used by the application 
code to signal the successful use of the captcha token to initiate a 
spam-protected action.
Original issue reported on code.google.com by google...@pcforum.hu on 8 Jul 2011 at 4:00
power-media / prado3

Built-in captcha control is easily circumvented, fails to stop spam #344
