1:48 p.m.
Thanks for having working this out !
Some comments inline
On Thu, Dec 5, 2013 at 12:38 PM, Bruno Oliveira <bruno(a)abstractj.org> wrote:
Good morning slackland, here comes the basic idea about password
reset:
Some considerations to keep in mind:
1. E-mail in an insecure channel, for this reason we won’t build any
functionality to “remember” the password, only reset.
2. It must be provided over SSL
3. We are not NSA proof, so this is just a prototype to validate ideas.
Details about the prototype:
1. The place to store the Token is totally up to the implementer:
keystore, PicketLink or whatever database
Okay but in the case of Unified Push Server what would be your advice
(PicketLink ? since we alreadu using it _
2. The url to reset the password is built with PBKDF2 +
authenticated
one-way hash function (HMAC), which means there’s no way you can pull the
url id back out. Into this way we are avoiding 2 issues: rainbow table
attacks and tampering, into other words an attacker will have a hard time
to brute force it, as well trying to corrupt the message.
3. This example doesn’t not validate e-mail address or have a login.
- Token table
- id: the hashed message generated and encoded in Base64 (Is
possible to be an hexadecimal)
- sentAt: the date and time when the token was sent to someone else
- expiration: token expiration. Default’s to 1 hour.
- used: if the token was used or not. I implemented it into this
way, but being paranoid I would suggest to just delete that record, if the
token was used.
- ExpirationTime class: just a class to deal with time and check if the
Token has expired.
- TokenService class: just a class to manipulate the tokens into the
database
- Endpoint workflow:
- /rest/forgot
1. User input the e-mail
2. E-mail is validated against the database
3. An URL to reset the password is sent
Ex: curl -v -H "Accept: application/json" -H "Content-type:
application/json" -d '{"email”:”john@doe.com"}' -X POST
http://localhost:8080/password-reset/rest/forgot
For first registrations, I presume it uses the same endpoint ? I'm
thinking of this scenario :
- An admin creates a new users just by providing a loginName.
- The backend creates the user and returns the url as explained above.
- Admin sends the link to the user.
- User click the link and set his password.
- /rest/reset
1. User sends an HTTP request with the token id
2. The id is validated against the database
3. User is redirected to the reset password page
4. The new password is configured
5. token id is destroyed into the database or disabled
Ex: curl -v -H "Accept: application/json" -H "Content-type:
application/json" -X POST
http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%...
Let me know what do you think and I can move forward implementing it.
Go Go Go !
Note: To build the project please make use of this PR
https://github.com/aerogear/aerogear-crypto-java/pull/13. A bug was found
on ag-crypto-java.
--
abstractj
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev