Sound good only one thing we could as an extra safety let the token time out after x minutes / days. On 5 Dec,2013, at 12:43 , Bruno Oliveira <bruno(a)abstractj.org&gt; wrote: > Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/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 > 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 > > - /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%... > > > -- > abstractj > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev

Just wanted to add that the /rest/forgot endpoint response must return the same answer regardless of whether the given e-mail is successfully validated against the database or not. The client should not be able to find out if an e-mail address exists in our DB.

Good morning slackland, here comes the basic idea about password reset: https://github.com/abstractj/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 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 - /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%... -- abstractj _______________________________________________ aerogear-dev mailing list aerogear-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev