On Thu, Dec 12, 2013 at 12:56 PM, Bruno Oliveira <bruno(a)abstractj.org&gt;wrote: > There we go answers inline. > > -- > abstractj > > On December 12, 2013 at 8:35:26 AM, Sebastien Blanc (scm.blanc(a)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 > Cool, I should be able to handle most of these, as soon if pushed stuff I will point it to you so you can help/give feedback > > > > > - 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) > Yeah, only admin can create users, this limits the risk of having fake users, so for the first iteration I will use this approach (empty password and able to login). > > > > > - 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(a)doe.xn--com-9o0a for example. > > As I mentioned, is up to the implementer but for paranoids, risky. > Ok, we will keep it simple and safe, just one "token" table with no relations. > > Let me know if something doesn’t make sense. > Thanks for your answers !