<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/4.6.4">
</HEAD>
<BODY>
sounds good to me<BR>
<BR>
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.<BR>
<BR>
On Thu, 2013-12-05 at 09:43 -0200, Bruno Oliveira wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Good morning slackland, here comes the basic idea about password reset:&nbsp;<A HREF="https://github.com/abstractj/password-reset">https://github.com/abstractj/password-reset</A>

Some considerations to keep in mind:&nbsp;

1. E-mail in an insecure channel, for this reason we won&#8217;t build any functionality to &#8220;remember&#8221; the password, only reset. &nbsp;&nbsp;
2. It must be provided over SSL&nbsp;
3. We are not NSA proof, so this is just a prototype to validate ideas.&nbsp;


Details about the prototype:&nbsp;

1. The place to store the Token is totally up to the implementer: keystore, PicketLink or whatever database&nbsp;
2. The url to reset the password is built with PBKDF2 + authenticated one-way hash function (HMAC),&nbsp;which means there&#8217;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.&nbsp;&nbsp;
3. This example doesn&#8217;t not validate e-mail address or have a login.&nbsp;

- Token table&nbsp;

-&nbsp;id: the hashed message generated and encoded in Base64 (Is possible to be an hexadecimal)&nbsp;
- sentAt: the date and time when the token was sent to someone else&nbsp;
- expiration: token expiration. Default&#8217;s to 1 hour.&nbsp;
- 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.&nbsp;

- ExpirationTime class: just a class to deal with time and check if the Token has expired.&nbsp;

- TokenService class: just a class to manipulate the tokens into the database&nbsp;

- Endpoint workflow:&nbsp;

- /rest/forgot&nbsp;

1. User input the e-mail&nbsp;
2. E-mail is validated against the database&nbsp;
3. An URL to reset the password is sent&nbsp;

Ex:&nbsp;curl -v -H &quot;Accept: application/json&quot; -H &quot;Content-type: application/json&quot; -d '{&quot;email&#8221;:&#8221;<A HREF="mailto:john@doe.com">john@doe.com</A>&quot;}' -X POST&nbsp;<A HREF="http://localhost:8080/password-reset/rest/forgot">http://localhost:8080/password-reset/rest/forgot</A>&nbsp;

- /rest/reset&nbsp;

1. User sends an HTTP request with the token id&nbsp;
2. The id is validated against the database&nbsp;
3. User is redirected to the reset password page&nbsp;
4. The new password is configured&nbsp;
5. token id is destroyed into the database or disabled&nbsp;

Ex:&nbsp;curl -v -H &quot;Accept: application/json&quot; -H &quot;Content-type: application/json&quot; -X POST&nbsp;<A HREF="http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D">http://localhost:8080/password-reset/rest/reset\?id\=sQrYVLJvwQptgYAg46t%2B%2BfoLrWxaPmkMY6mmvCs%2F51M%3D</A>&nbsp;


--&nbsp;
abstractj

_______________________________________________
aerogear-dev mailing list
<A HREF="mailto:aerogear-dev@lists.jboss.org">aerogear-dev@lists.jboss.org</A>
<A HREF="https://lists.jboss.org/mailman/listinfo/aerogear-dev">https://lists.jboss.org/mailman/listinfo/aerogear-dev</A>
</PRE>
</BLOCKQUOTE>
<BR>
</BODY>
</HTML>