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
- 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(a)doe.xn--com-9o0a for example.
As I mentioned, is up to the implementer but for paranoids, risky.
Let me know if something doesn’t make sense.