On Thu, Dec 12, 2013 at 6:49 AM, Bruno Oliveira <bruno@abstractj.org> wrote:
Good morning my friends, I think I finally found a happy path to the password reset workflow. To eat my own dog food, I wrote the whole interaction with AGJS (thanks a lot Luke for your patience). 

Details about the project:

url: https://github.com/abstractj/password-reset/
tag: 0.1.0
Dependencies: The following PR must be locally installed https://github.com/aerogear/aerogear-crypto-java/pull/14

The package “api” is what I would suggest to move to another project like ag-security for example and the other packages are mostly up to the implementer. 

Configuration files:

- The project has 2 configuration files

web.xml: 

        <init-param>
            <param-name>url</param-name>
            <param-value>http://localhost:8080/password-reset/</param-value>
        </init-param>
        <init-param>
            <param-name>redirect-page</param-name>
            <param-value>/reset/update.html</param-value>
        </init-param>

The “url” parameter is used by the project to provide the urls like: http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D and “redirect-page” is the page to be redirected when the correct token id is provided.

config.properties:

secret_key = "d9eb5171c59a4c817f68b0de27b8c1e340c2341b52cdbc60d3083d4e8958532" \
               “18dcc5f589cafde048faec956b61f864b9b5513ff9ce29bf9e5d58b0f234f8e3b"

“secret_key” will be the passphrase used by PBKDF2 to HMAC a new token and can’t be shared.

How to test it?

- git clone https://github.com/abstractj/password-reset/ && cd password-reset && mvn clean package 

Scenarios for testing:

- Workflow I

1. Open http://localhost:8080/password-reset/ at your browser
2. Input whatever e-mail and click on reset
3. At your console an URL will be printed at your logs. For example: http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D
4. Copy & paste it into your browser
5. If everything went well, you will probably see the update page. Input the e-mail, new password and the confirmation
6. Now try to send a request to the same URL and you will get a 404 (This is intentional, because the token was used & destroyed)

- Workflow II

1. Try to request the update.html page
2. You should get a 404 because you’re not allowed to do it without a valid token

- Workflow III
1. Try to request http://localhost:8080/password-reset/reset/?id=“Some random or repeated id here”
2. You should get a 404 because you’re not allowed to do it without a valid token

- Workflow IV
1. Change the value of https://github.com/abstractj/password-reset/blob/master/src/main/java/org/abstractj/model/Token.java#L22 to -10 for example.
2. Input whatever e-mail and click on reset
3. At your console an URL will be printed at your logs. For example: http://localhost:8080/password-reset/reset?id=CMZXGXLg%2Fw7nCBrlmEB%2BO6iDMHzxNSf8cD5idyDxS8U%3D
4. Copy & paste it into your browser
5. You should get a 404 because this token has already expired.

Open questions

- The usability is easy, tricky..the configuration files are too much?
Seems reasonable  
- Where the package “api” should be added? ag-security? nowhere?
Make sense to add this to ag-security IMO 
- Is the workflow ok for you?
 The reset flow is clear and I was able to play with your project.
Now, I have to think how to adapt this for UPS concerning the creation of the user, some question :

- I would like the new created user to be "blocked/inactive" until he hasn't clicked the generated link, seems this approach okay ? And what is the correct way of doing this : assign a default password and set the credential as expired ? 

- Can I store the tokens just as in your sample (JPA/Model flow) or opens that a big security hole ? 

-  Is there a way to have a relation between the token and the email (or whatever other unique identifier for the user) so that when the user clicks the link the backend already knows which users it concerns and just handle the password reset ? Or is that something that we don't want and the user will always have to enter his email when resetting ?   


Thoughts, suggestions?
Good job !  




--
abstractj

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev