[prev in list] [next in list] [prev in thread] [next in thread] 

List:       trac
Subject:    Re: [Trac] Re: AccountManager: erratic behaviour of ResetPwStore
From:       Nicolas MARTIN <ntmlod () locean ! upmc ! fr>
Date:       2017-09-07 16:26:50
Message-ID: f7c06c28-d2e3-dc1f-ddf7-251547a4126f () locean ! upmc ! fr
[Download RAW message or body]

Well good news ! I found the origin of our issue but probably the best 
people to explain it would be the plugin developers.

On the administration interface of the user accounts 
(/admin/accounts/users), you can create an account with 2 different 
forms: 'Add user' at the top of the page or 'Add external user' at the 
bottom (which in fact are duplicated in our project but it is an another 
story). The evident difference between them is the setting of the 
password (random or defined) but I didn't pay to much attention on this 
because there is no particular information in the wiki and everything 
was fine at that time.

So from the beginning I had to use 'Add user' form for the reasons I 
explained in my last message. The newly account was listed under 'Users' 
table then moved to the 'External Users' table after the first 
connection of the user.
During my vacations, my colleague was not sure which form to use. She 
saw that nearly all accounts were listed in 'External users' so she 
chose 'Add external user' form which was consistent. Today I give it a 
try to create a user account as usual ('Add user' form) and it works 
perfectly...

That's all for the visible part of the problem, I was guessing that the 
2 forms followed more or less the same process but it is not the case.
'Users' table seems to refer to accounts in the Trac database and 
'External users' to accounts in a password file. So my initial procedure 
of using 'Add user' jointly with HtPasswdStore is probably not the good 
one but it works.


Nicolas


On 07/09/2017 01:16, Nicolas MARTIN wrote:
> 
> On 6 September 2017 23:06:03 CEST, RjOllos <rjollos@gmail.com> wrote:
> > 
> > On Wednesday, September 6, 2017 at 8:46:52 AM UTC-7, Nicolas MARTIN
> > wrote:
> > > I've modified pwhash.py but I'm still faced the issue.
> > > 
> > > Now I'm trying to analyse this in a different way, to see why the
> > > procedure doesn't work now (changes in Trac or the server) or if the
> > > problem dates back to the authentication switch. In particular, I
> > found
> > > that most of the 'password_reset' entries for newly accounts are
> > still in
> > > the 'session_attribute' SQL datatable. Would they not have been
> > removed
> > > after the first connection with the personalized password ?
> > > 
> > As noted, there are several issues with password reset. I doubt it
> > works
> > properly in all circumstances. I will try to take a look in the next
> > few
> > days.
> > 
> > 
> > > The situation is a bit critical because I still can create an account
> > but
> > > for me I have no more a secure way to transmit the access. Any hint ?
> > > 
> > I don't understand the last statement.
> > 
> > - Ryan
> For security purpose, I use the reset password procedure for every new account.
> A new user contacts us by email with a chosen username, then I create the new \
> account (with only email and username, random password is generated), and ask \
> him/her back to follow the reset procedure. Finally the user has to set its own \
> password after the first connection. Following this, I presume to reduce \
> drastically the vulnerability of the whole process. The credentials of an account \
> will only be contained in a single email just once and valid for a very limited \
> time. Usually the user will finalize the  password reset in a few seconds. 
> At this time, I have a few people with a valid account but they can't use it. On \
> top of that, as the repository access is based on the same passwords file, they are \
> even not allowed to download the source code of our project. I'm a bit paranoid \
> perhaps but I don't want to send clear password if I'm not sure it will be changed \
> right away. 
> Nicolas
> 

-- 
You received this message because you are subscribed to the Google Groups "Trac \
Users" group. To unsubscribe from this group and stop receiving emails from it, send \
an email to trac-users+unsubscribe@googlegroups.com. To post to this group, send \
email to trac-users@googlegroups.com. Visit this group at \
https://groups.google.com/group/trac-users. For more options, visit \
https://groups.google.com/d/optout.


[prev in list] [next in list] [prev in thread] [next in thread]