[aerogear-dev] Fwd: Password reset 0.1.0

[Sebastien Blanc]

Sorry, just realized I replied only to AbstractJ and not the list.

---------- Forwarded message ----------
From: Sebastien Blanc <scm.blanc at gmail.com>
Date: Fri, Dec 13, 2013 at 6:38 PM
Subject: Re: [aerogear-dev] Password reset 0.1.0
To: Bruno Oliveira <bruno at abstractj.org>


Hi,
A quick update before the weekend starts ;)
I started to integrate this into UPS and I also moved some stuff to ag-sec
as discussed on this thread.

You can play with it here  : https://push-sblanc.rhcloud.com/

Steps :
1. Log in with admin/aerogear
2. On the top bar on the right you should see a menu icon (the
hamburger-menu icon) , select "Manage Users"
3. Click on "Create"
4. Create a new user by just providing a loginName. A popup will appear,
wait until the registration link appears (can be a bit long depending on
Open Shift's mood).
5. Copy paste this link in a new tab or browser.
6. You are redirected to a "confirmation" page, fill the info and send.
7. Go back to the first page you opened at step 1, logout, and now tries to
login with the new user. It should work.

PRs will be send out next week as I need some polish, validation and Role
Management but if you want to build it and deploy your self here is the
puzzle ;) :

- UPS :
https://github.com/aerogear/aerogear-unifiedpush-server/tree/register_link
- Admin UI :
https://github.com/sebastienblanc/aerogear-unified-push-server-admin-ui/tree/user_mngt
- Crypto : https://github.com/aerogear/aerogear-crypto-java/pull/14
- AG-SEC : https://github.com/sebastienblanc/aerogear-security/tree/token

Thanks again Bruno,





On Thu, Dec 12, 2013 at 1:24 PM, Sebastien Blanc <scm.blanc at gmail.com>wrote:

>
>
>
> On Thu, Dec 12, 2013 at 12:56 PM, Bruno Oliveira <bruno at abstractj.org>wrote:
>
>> 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
>>
> 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 at doe.com” 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 !
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131216/bba832d8/attachment.html