[aerogear-dev] Password reset 0.1.0

[Bruno Oliveira]

There we go answers inline.

--  
abstractj

On December 12, 2013 at 8:35:26 AM, Sebastien Blanc (scm.blanc at gmail.com) wrote:
> > 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 :

To adapt on UPS will be necessary to:

- Implement the TokenService interface
- Implement the endpoints like I did into that demo
- Replace the FakeService by something real
- Insert the configuration files

I can help with it

>  
> - I would like the new created user to be "blocked/inactive" until  
> he hasn't clicked the generated link, seems this approach okay  
> ? 

tbh I don’t think you should have inactive users into your database because is too risky, you should have something similar to the table “Token” to be send to the user.

And what is the correct way of doing this : assign a default password  
> and set the credential as expired ?

Have inactive users with default passwords is a bad idea, imo the correct workflow would be:

- Generate something pretty similar to the reset url during the first registration
- Send this url to our user (with the token having an expiration time)
- User access that url and has permissions to update the password 

Here is the problem when you generate an user into your database without any confirmation if they truly exists:

- Is possible to generate fake users

If only the admin is allowed to create/register users, I would suggest to generate the user with empty password and NEVER allow that user to login with empty passwords (not sure if it was clear but let me know)

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

You can store just like that, once the expiration time is validated and the token is destroyed I’m not sure about what do you mean about open a security hole. For example an attacker could hack the database and steal the reset tokens, but only if the time didn’t expired otherwise won’t happen, because the want’s to find out the “secret” to generate those tokens and try to break something generated with salt + iterations with PBKDF2.

Into other words is not impossible, but really hard. Another security hole would exist if the implementer incorrectly validate that token into the database.

>  
> - 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 ?

Into the way like it was written is possible but not recommended and lemme explain why (call me paranoid). 

Scenario 1: 

If an attacker hack the database and face with a table with a bunch of tokens but no relationship with other tables, will be hard to figure out which token belongs to an specific user and basically will be necessary to guess which token belongs to an specific e-mail.

Scenario 2: 

If we add a relationship between a table like “Token” and for example “User”, the attacker don’t need to guess anymore, is just a matter of check which token belongs to “john at doe.com” for example.

As I mentioned, is up to the implementer but for paranoids, risky.

Let me know if something doesn’t make sense.