[aerogear-dev] Password reset 0.1.0

[Sebastien Blanc]

On Thu, Dec 12, 2013 at 6:49 AM, Bruno Oliveira <bruno at 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%3Dand “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#L22to -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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131212/412865ca/attachment-0001.html