Security Token Timeouts Design

After learning about how the timeouts are created and used in the generated tokens by security service, I believe that some manner of refactoring is needed.

As I understand it, timeouts support business cases as follows:

1) DEFAULT: default token expiration for API calls
2) ACTIVATION: the period after which an activation attempt will cease to be allowed for a particular token
3) FORGOT_PASSWORD: the period after which a password reset attempt will cease to be allowed for a particular token

However, the implementation is such that:

1) the ui (vi a user, known or unknown) makes a call to the security API to get a token that allows unrestricted use of the send notification API.
2) the ui then uses this token to call the send notification API to send an email with the template specified.
3) the security API intercepts this token and checks to make sure it hasn't timed out.
4) depending on the template specified, the notification API asks the security API for the timeout for an action, the determination of which is based on said template.

This design is confusing. My research indicates that this design was chosen to prevent a perceived security hole. This hole is described as "an anonymous user attempting to reset a password numerous times."

There are several problems here. The first of which is that a new security hole has been opened that allows an anon to use the notification service unfettered for a period of time. After this time has expired the anon need only request a new notification service token.

The second problem is that the knowledge of timeouts is spread all throughout the system. Security component has the timeout values. Security SAPI sets the timesouts on the token genereated by the security component. The UI needs to know to get a send notification token and then send out a notification using the notification API. The notification API has to ask the security component for the timeouts to put in the emails. This is not a coherent design.

I propose doing what every other web site in the world does: allow anon access to the forgot password process and not worry about it being hit a thousands times. We can throttle attempts by IP or other identifying info if we must and that would be much cleaner. Furthermore, it should be the burden of the security API to handle the sending of the emails (using notification service) since it knows all about timeouts and should not defer this responsibility to the UI. This would prevent the spread of the overall process across so many layers. It would be clear, and simple. The only argument I can think of against this, based on our current requirements, would be that, some may say, security service shouldn't send emails. I believe that in this case it is a better candidate for doing so than opening up a security hole so that the UI can send a security related email.