It seems that you should only be able to access the "change password" page if 
you are either:

1.) Previously successfully authenticated
2.) Required to authenticate as part of change password.

In the case of #1, you're okay because you only need ensure that the user who's 
password is being changed is currently authenticated.

In the case of #2, change password should trigger authentication prior to 
persisting the modified user password.  This particular element represents 
business logic within your application and could (perhaps -- I've not tried 
this) be performed by injecting the AuthenticationManager into your backing 
bean and asking it to perform the normal authentication procedure prior to 
executing the password change in the database.

After examining your use case, it seems like you should force the brand new 
user to authenticate the first time with whatever random password your user 
creation algorithm is setting their initial password to.  Upon that initial 
authentication, you can evaluate that the user is past expiry and redirect to 
the password change page.  Alternatively (and preferably, additionally), the 
user can be forced to enter the temporary initial password on the change 
password screen.  

So, I guess my interpretation of the "best practice" for password change is 
that the user must already be authenticated or must undergo authentication 
prior to password change.  That will insulate you from exposure in the same way 
as your standard login flow does.

-jason

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, October 04, 2006 8:26 AM
To: [email protected]
Subject: Re: [Acegisecurity-developer] How to prevent brute force attack

Hi Jason,

I've already done this for the login page, but I don't know how to do it for my 
change password page.

Regards
Gunnar
 

> -----Ursprungligt meddelande-----
> Från: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
>  För [EMAIL PROTECTED]
> Skickat: den 4 oktober 2006 14:19
> Till: [email protected]
> Ämne: Re: [Acegisecurity-developer] How to prevent brute force attack
> 
> In familiar implementations, we've implemented the acegi 
> UserDetailsService object to translate user information drawn 
> from the application's database into a compatible 
> Authentication object.  This gives us the opportunity to set 
> the user's access flags based on our business rules (such as 
> determining password expiry).  
> 
> Additionally, acegi will drop an event on spring when 
> authentication succeeds or fails.  The failure message will 
> include the exception detailing the authentication failure.  
> You can use this to determine what the conditions of the 
> authentication attempt were and take action accordingly (such 
> as locking the user after a number of bad password attempts)
> 
> -jason
> 
> -----Original Message-----
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED]
>  On Behalf Of [EMAIL PROTECTED]
> Sent: Wednesday, October 04, 2006 8:12 AM
> To: [email protected]
> Subject: Re: [Acegisecurity-developer] How to prevent brute 
> force attack
> 
> Hi Luke!
>  
> Answers inline.
> 
> Regards
> Gunnar
> 
> > -----Ursprungligt meddelande-----
> > Från: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED]
> >  För Luke Taylor
> > Skickat: den 4 oktober 2006 13:42
> > Till: [email protected]
> > Ämne: Re: [Acegisecurity-developer] How to prevent brute 
> force attack
> > 
> > You should still be required to authenticate first to change your 
> > password (or at the same time as the change request is 
> submitted), so 
> > you should be able to lock the account after 3 failures here too.
> 
> Can you explain more how I should do that?
> 
> > How is the data stored for password expiry times etc?
> 
> The expiry time is stored in a sybase database. 
> I've created a new JdbcDaoImpl to add some more data to the 
> UserDetails object.
> 
> 
> > 
> > [EMAIL PROTECTED] wrote:
> > > Hi Gurus!
> > > 
> > > How can I prevent a brute force attack on my password
> > change jsp page?
> > > 
> > > Background:
> > > I've successfully secured a jsp/perl web application.
> > > Thanks to all acegi developers for this fine piece of software!
> > > 
> > > The login jsp page is protected against brute force by
> > leveraging the
> > > application event publishing features so the account is
> > locked for 30
> > > minutes after three failed logins.
> > > BTW I can't find any documentation for application event
> > publishing in
> > > the 1.0.0 manual.
> > > 
> > > My question is how I can do something similar to prevent
> > the password
> > > change page?
> > > 
> > > The password change page is open to role anonymous because
> > when a new
> > > user is entered in the system; password expired is set to a
> > past date
> > > to force the user to change the password the first time.
> > > 
> > > Are there any best practices to handle changes of passwords?
> > > 
> > > Regards
> > > Gunnar
> > > 
> > 
> > 
> > -- 
> >  Luke Taylor.                      Monkey Machine Ltd.
> >  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk
> > 
> > 
> > --------------------------------------------------------------
> > -----------
> > Take Surveys. Earn Cash. Influence the Future of IT Join 
> > SourceForge.net's Techsay panel and you'll get the chance to share 
> > your opinions on IT & business topics through brief surveys -- and 
> > earn cash 
> > http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> > _______________________________________________
> > Home: http://acegisecurity.org
> > Acegisecurity-developer mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> > 
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to 
> share your opinions on IT & business topics through brief 
> surveys -- and earn cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> _______________________________________________
> Home: http://acegisecurity.org
> Acegisecurity-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> 
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT Join 
> SourceForge.net's Techsay panel and you'll get the chance to 
> share your opinions on IT & business topics through brief 
> surveys -- and earn cash 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> _______________________________________________
> Home: http://acegisecurity.org
> Acegisecurity-developer mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
> 

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer

Reply via email to