From: <mar...@tr...> - 2004-07-19 11:46:55
|
I notices if a user looses the password he has to write to the admin via email to ask for a reset. I think we can add a "Lost password?" function that resets automatically the password and sends it to the user upon providing username and email address via form (where username and email address have to be in line with the info stored in the DB). I can add this to the next relase of the signup/password managing. Marcello |
From: Victor B. <vi...@fu...> - 2004-07-19 13:07:06
|
Hi Marcello, > I notices if a user looses the password he has to write to the admin > via email to ask for a reset. I think we can add a "Lost password?" > function that resets automatically the password and sends it to the > user upon providing username and email address via form (where > username and email address have to be in line with the info stored > in the DB). Ideally, we should implement the following scenario: 1. User forgets password 2. User goes to forget password option, and enters user name. 3. An email is sent to the user with a link to trigger the actual reset 4. The user receives the email, and clicks on the link. 5. The link triggers code in Mantis which resets the password. 6. The user receives another email with the new auto-generated password. 7. User logs in with the auto-generated password. 8. User changes password to a password that is easy to remember. The important thing about the confirmation email is to avoid people requesting a password reset for another user for which they know the user name and password. > I can add this to the next relase of the signup/password managing. That would be good. Regards, Victor |
From: Julian F. <ju...@be...> - 2004-07-19 17:51:53
|
Victor Boctor wrote: > Ideally, we should implement the following scenario: > > 1. User forgets password > 2. User goes to forget password option, and enters user name. > 3. An email is sent to the user with a link to trigger the actual reset > 4. The user receives the email, and clicks on the link. > 5. The link triggers code in Mantis which resets the password. Why not have the link provide the user with a place to enter a new password instead of having to round-trips via email? I don't think there's any added security by having two sets of emails... > 6. The user receives another email with the new auto-generated password. > 7. User logs in with the auto-generated password. > 8. User changes password to a password that is easy to remember. |
From: Dirk B. <bro...@tz...> - 2004-07-19 19:08:25
|
When you desing this feature, it will be great if you think about a blocking system for lock an account past 3 or 5 (config param) failed logins.... otherwise i can easy make an brute force...to get a password. i think the best way to desing a lost password function is to look at the email provider ... Dirk Julian Fitzell wrote: > > > Victor Boctor wrote: > >> Ideally, we should implement the following scenario: >> >> 1. User forgets password >> 2. User goes to forget password option, and enters user name. >> 3. An email is sent to the user with a link to trigger the actual reset >> 4. The user receives the email, and clicks on the link. >> 5. The link triggers code in Mantis which resets the password. > > > Why not have the link provide the user with a place to enter a new > password instead of having to round-trips via email? I don't think > there's any added security by having two sets of emails... > >> 6. The user receives another email with the new auto-generated password. >> 7. User logs in with the auto-generated password. >> 8. User changes password to a password that is easy to remember. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Chris S. <ch...@ep...> - 2004-07-20 01:11:44
Attachments:
forgotten_pwd.tar.gz
|
I tend to agree with Julian on this one. The solution put forth by Victor is needlessly complex, IMHO (as if that means anything ;) ). In fact, why not just have Mantis send a reset pwd on request, instead of having and email send a link. Attatched is the solution I hacked up at work (redone to work with CVS version). For an internal site, I didn't need to worry about DOS attacks. Also, for a company, people only have one email address, so I keyed off of the email. Basically, it works like so: 1.) User clicks on [Forgot your password?] link from login_page.php 2.) User has opportuinity to enter email address. 3.) If a matching email is found, a new password is generated, and sent to that email address. Simple as that. Maybe what I have attached could serve as a good starting place for something more advanced. But please, keep a simple, less complex option available. The attached archive contains a diff and two new files. I also added a new config variable to allow someone to turn the whole thing off... Chris Julian Fitzell wrote: > > > Victor Boctor wrote: > >> Ideally, we should implement the following scenario: >> >> 1. User forgets password >> 2. User goes to forget password option, and enters user name. >> 3. An email is sent to the user with a link to trigger the actual reset >> 4. The user receives the email, and clicks on the link. >> 5. The link triggers code in Mantis which resets the password. > > > Why not have the link provide the user with a place to enter a new > password instead of having to round-trips via email? I don't think > there's any added security by having two sets of emails... > >> 6. The user receives another email with the new auto-generated password. >> 7. User logs in with the auto-generated password. >> 8. User changes password to a password that is easy to remember. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > > > |
From: J.P. P. <pa...@wa...> - 2004-07-20 01:20:31
|
Chris Shaffer said: > I tend to agree with Julian on this one. The solution put forth by > Victor is needlessly complex, IMHO (as if that means anything ;) ). In > fact, why not just have Mantis send a reset pwd on request, instead of > having and email send a link. > > Attatched is the solution I hacked up at work (redone to work with CVS > version). For an internal site, I didn't need to worry about DOS > attacks. Also, for a company, people only have one email address, so I > keyed off of the email. Basically, it works like so: > > 1.) User clicks on [Forgot your password?] link from login_page.php > 2.) User has opportuinity to enter email address. > 3.) If a matching email is found, a new password is generated, and sent > to that email address. > > Simple as that. So if I'm bored one day (it happens), I can spend the day resetting your password.... The method Victor mentioned is fairly standard, and quite acceptable, IMN= SHO. --=20 Live fast, die young, You're sucking up my bandwidth. J.P. Pasnak, CD CCNA, LPIC-1 http://www.warpedsystems.sk.ca |
From: Chris S. <ch...@ep...> - 2004-07-20 02:03:34
|
J.P. Pasnak wrote: > So if I'm bored one day (it happens), I can spend the day resetting your > >password.... > >The method Victor mentioned is fairly standard, and quite acceptable, IMNSHO. > > > For that to happen, you'd have to know the email that I used to register with Mantis. Not very likely that some random person, out for a good time, would know that email. Besides, what are the odds off that happenening? Espcially on an internal, corporate site (I know, not everyone uses Mantis in such a way. But a fair portion do). This is one area where I think Mantis could use a simple version of the functionality, and build to a more complex, configurable option. You don't have to plan for the worst case senerio with every line of code. What you're describing is an edge case. Chris |
From: J.P. P. <pa...@wa...> - 2004-07-20 03:17:14
|
Chris Shaffer said: > J.P. Pasnak wrote: > >> So if I'm bored one day (it happens), I can spend the day resetting yo= ur >> >>password.... >> >>The method Victor mentioned is fairly standard, and quite acceptable, >> IMNSHO. >> >> >> > For that to happen, you'd have to know the email that I used to registe= r > with Mantis. Not very likely that some random person, out for a good > time, would know that email. > > Besides, what are the odds off that happenening? Espcially on an > internal, corporate site (I know, not everyone uses Mantis in such a > way. But a fair portion do). I use Mantis in both internal and external sites, and it is _far_ more likely in the internal ones that someone will know the email address and/or userid I use than the external ones. And I've had more internal people try to 'poke holes' in my projects :) >This is one area where I think Mantis > could use a simple version of the functionality, and build to a more > complex, configurable option. > Something was suggested that was in between your suggestion and Victors. = =20 That may be a good place to start. > You don't have to plan for the worst case senerio with every line of > code. What you're describing is an edge case. > But home many 'compromises' in code are acceptable? I've found that the things that you think are 'unlikely' are the first things that go wrong..= . --=20 Live fast, die young, You're sucking up my bandwidth. J.P. Pasnak, CD CCNA, LPIC-1 http://www.warpedsystems.sk.ca |
From: Mitch \(WebCob\) <mi...@we...> - 2004-07-20 03:59:42
|
> I use Mantis in both internal and external sites, and it is _far_ more > likely in the internal ones that someone will know the email address > and/or userid I use than the external ones. And I've had more internal > people try to 'poke holes' in my projects :) > I didn't know Saskatchewan was such a hostile place ;-) In the corp networks I manage, they'd have to spoof an IP first, and get around the vlans or they'd be caught, and it wouldn't happen often. If you work in a place like that I'd think people intentionally logging into your windows account (and triggering lockout with bad passwords) on purpose would be a problem too... what are you going to do? Remove that security? I echo the others... as long as there is a way to just use the standard "help I've lost my password, don't confuse me with the details, just send me a new one" - in fact hey - report in that email the IP that initiates the request! Then you don't have to worry about it being done as a joke. m/ |
From: J.P. P. <pa...@wa...> - 2004-07-20 04:54:45
|
Mitch (WebCob) said: >> I use Mantis in both internal and external sites, and it is _far_ more >> likely in the internal ones that someone will know the email address >> and/or userid I use than the external ones. And I've had more intern= al >> people try to 'poke holes' in my projects :) >> > > I didn't know Saskatchewan was such a hostile place ;-) > It keeps me on my toes :) > In the corp networks I manage, they'd have to spoof an IP first, and ge= t > around the vlans or they'd be caught, and it wouldn't happen often. > > If you work in a place like that I'd think people intentionally logging > into > your windows account (and triggering lockout with bad passwords) on > purpose > would be a problem too... what are you going to do? Remove that securit= y? > > I echo the others... as long as there is a way to just use the standard > "help I've lost my password, don't confuse me with the details, just se= nd > me > a new one" - in fact hey - report in that email the IP that initiates t= he > request! Then you don't have to worry about it being done as a joke. > Not if it went as suggested. Now you know the IP that did it, but your password is still changed. In a world full of NAT, hunting down the actual IP can be a lengthy process. As I said, I belive an 'in between' process was suggested, something alon= g the lines of: 1) Request password from site (site would generated auth code) 2) Recieve e-mail with link (auth code in link) 3) Click link 4) Redirected to page that allows you to reset password. --=20 Live fast, die young, You're sucking up my bandwidth. J.P. Pasnak, CD CCNA, LPIC-1 http://www.warpedsystems.sk.ca |
From: Mitch \(WebCob\) <mi...@we...> - 2004-07-20 06:31:32
|
> 1) Request password from site (site would generated auth code) > 2) Recieve e-mail with link (auth code in link) > 3) Click link > 4) Redirected to page that allows you to reset password. I agree that seems simpler - with the repeated provisors that the authcode (while reversable to prevent having to store resets in progress) must not be reversable without knowing the particular config of a site (and not just having your own copy of mantis) which implies needing a unique per install key. m/ |
From: Julian F. <ju...@be...> - 2004-07-20 06:48:06
|
Well, I just don't think it's any less secure than Victor's suggestion with less hassle to the user. It is of course possible that I'm missing something... But yes, the URL certainly has to be unhackable. Ideally it would even be one-time (but as you point out, we'd then have to store information on the resets). The best compromise is probably to have the timestamp of the request in the decoded data. Then we could have it work only for an hour, or 6 hours, or whatever... could even be configurable. Julian Mitch (WebCob) wrote: >>1) Request password from site (site would generated auth code) >>2) Recieve e-mail with link (auth code in link) >>3) Click link >>4) Redirected to page that allows you to reset password. > > > I agree that seems simpler - with the repeated provisors that the authcode > (while reversable to prevent having to store resets in progress) must not be > reversable without knowing the particular config of a site (and not just > having your own copy of mantis) which implies needing a unique per install > key. > > m/ > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev |
From: Chris S. <ch...@ep...> - 2004-07-22 11:04:25
|
Not to beat this dead horse, again. But, would JP's suggested process be acceptable for password resets? I've got no problems modifying my current patch to do this. I just want to be sure it would be accepted (should it work, of course ;) ). Chris J.P. Pasnak wrote: >As I said, I belive an 'in between' process was suggested, something along >the lines of: > >1) Request password from site (site would generated auth code) >2) Recieve e-mail with link (auth code in link) >3) Click link >4) Redirected to page that allows you to reset password. > > > > > |
From: Glen S. <grs...@co...> - 2004-07-22 16:03:17
|
Chris Shaffer wrote: > Not to beat this dead horse, again. But, would JP's suggested process > be acceptable for password resets? I've got no problems modifying my > current patch to do this. I just want to be sure it would be accepted > (should it work, of course ;) ). Looks good to me, seems logical, simple, and reasonably secure. > > Chris > > J.P. Pasnak wrote: > >> As I said, I belive an 'in between' process was suggested, something >> along >> the lines of: >> >> 1) Request password from site (site would generated auth code) >> 2) Recieve e-mail with link (auth code in link) >> 3) Click link >> 4) Redirected to page that allows you to reset password. > -- Glen Starrett |
From: Mitch \(WebCob\) <mi...@we...> - 2004-07-22 16:14:05
|
If you need a specific persons attention (like Victor for example) it is a good idea to cc him directly. He doesn't always get to read all of the threads... With my comment about making sure it wasn't reverse enginerable by using a site unique key, yes - I think this was a good comprimise. m/ > -----Original Message----- > From: man...@li... > [mailto:man...@li...]On Behalf Of Chris > Shaffer > Sent: Thursday, July 22, 2004 4:06 AM > To: man...@li... > Subject: Re: [Mantisbt-dev] Lost password function > > > Not to beat this dead horse, again. But, would JP's suggested process > be acceptable for password resets? I've got no problems modifying my > current patch to do this. I just want to be sure it would be accepted > (should it work, of course ;) ). > > Chris > > J.P. Pasnak wrote: > > >As I said, I belive an 'in between' process was suggested, > something along > >the lines of: > > > >1) Request password from site (site would generated auth code) > >2) Recieve e-mail with link (auth code in link) > >3) Click link > >4) Redirected to page that allows you to reset password. > > > > > > > > > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Mantisbt-dev mailing list > Man...@li... > https://lists.sourceforge.net/lists/listinfo/mantisbt-dev > |
From: Victor B. <vi...@fu...> - 2004-07-22 23:20:39
|
Hi all, > He doesn't always get to read all of the threads... [Victor] I actually do, but I don't always have the time to reply right away. With these discussions, I also like to get more feedback before posting my conclusions. First, aims: A1. Providing "Forgot Password" functionality A2. This feature will not be available for anonymous user account, users without a registered email address, or protected user accounts. A3. It would be nice if we can re-use the feature for "password resets" or creation of random password when creating new users without specifying a password. Advantage, new user will be taken to change password page directly, and password will not be sent in plain text. A4. Users MUST only be able to reset their own passwords. A5. A password reset link must only be usable to change the password once. A6. Users MUST not be able to create their own links to be used for password resets of other users (unless they know their passwords!). [note that using an internal key we can block this ability completely, even if user has access to Mantis source code.] A7. Stop an attacker from clicking forgot password to spam account owner with emails. A8. Include IP information in password reset request emails. Ok, here comes the how part: 1. User requests a password reset 2. Email will be sent with a link which look like the following: http://.../password_reset.php?user=vboctor&auth=XXXXXXXXXXXXXX auth_code = md5( config_get( 'path' ) . $t_username . $t_current_password ); an error will be triggered if user account does not meet conditions specified in A2. 3. User clicks on the link: The auth code is re-calculated for the specified user, if the same, then user is logged in, and prompted with the user information page which allows change of password. The above scenario covers A1, A2, A4, A5, A6, A8. A3: can be done by adding code in password reset to re-use the same code. A7: will require a change to db schema In my opinion, this is the approach that we should follow. However, we can definitely implement it on a couple of stages. Regards, Victor. |
From: Mitch \(WebCob\) <mi...@we...> - 2004-07-23 01:21:26
|
> > He doesn't always get to read all of the threads... > [Victor] I actually do, but I don't always have the time to reply right > away. With these discussions, I also like to get more feedback before > posting my conclusions. Excuse me ;-) Didn't mean it to sound critical - hadn't heard from you in a bit - remembered our emails before where you said to cc you if it required your direct input (or am I mixing up my projects again? ;-) > 2. Email will be sent with a link which look like the following: > http://.../password_reset.php?user=vboctor&auth=XXXXXXXXXXXXXX user should be base64'd. Usernames can have characters that are not URL friendly if the user configurable regex is changed. > auth_code = md5( config_get( 'path' ) . $t_username . > $t_current_password ); This addresses A5 only if the same password is never used - right? $t_current_password itself is not a cleartext password anyways right? Just confirming - a few peoples contents indicated they were assuming passwords were stored in a readable format... > A3: can be done by adding code in password reset to re-use the same > code. One more extension possibility... can this work? Would it be a big change to allow a project manager (configurable of course) to INVITE a new user. Just thinking of another re-use for this code... Right now, users can sign themselves up, but we for example maintain MANY private projects for our users, and allow them to manage their own access (removes us as the bottleneck). Rather than having people sign themselves up, it would be nice to delegate that function to a project manager, who could then trigger the new account creation, with an automatic membership in the current project (selectable at creation time or editable now as it is currently...) Is this obtainable another way? Or am I right in thinking this is related to the new functionality? m/ |
From: Alex N. (a. Wanderer) <ba...@la...> - 2004-07-20 10:11:51
|
Hello Chris, On Mon, 19 Jul 2004 22:06:04 -0400 (20.07.2004 8:06 my local time), received Tuesday, July 20, 2004 at 8:49:51, you wrote about "[Mantisbt-dev] Lost password function" at least in part: CS> For that to happen, you'd have to know the email that I used to register CS> with Mantis. Reporter (any reporter) can know it CS> Not very likely that some random person, out for a good CS> time, would know that email. Really? I have e-mail shown to reporters, because they like idea of direct mailing "reporter-reporter", but "bad boy" can play bad joke using _your_ technique of resetting password - because this link placed on unauthenticated page, simple bot can reset pass, for example, every 10 minutes, or even faster CS> Besides, what are the odds off that happenening? Espcially on an CS> internal, corporate site (I know, not everyone uses Mantis in such a CS> way. But a fair portion do). And owners of external Mantis-based bugtrackers (I know a lot of companies) will sent Mantis to trash with this huge hole CS> You don't have to plan for the worst case senerio with every line of CS> code Be ready to worst is _first rule_ of every good programmer and real admin -- Best regards, Alex Netman (aka Wanderer) |
From: Chris S. <ch...@ep...> - 2004-07-20 11:12:37
|
Alex Netman (aka Wanderer) wrote: >Really? I have e-mail shown to reporters, because they like idea of >direct mailing "reporter-reporter", but "bad boy" can play bad joke >using _your_ technique of resetting password - because this link placed >on unauthenticated page, simple bot can reset pass, for example, every >10 minutes, or even faster > > > Well... Maybe that's the 'security hole' and not a lost password feature. Besides, you guys are forgetting that someone would WANT to take down a Mantis install to do this. Really, how likely is that? Maybe you guys live in more hostile environs, than I do (apparently, Saskatewan is a rough place, by what I hear ;) ). But I really think you're worrying about nothing. >And owners of external Mantis-based bugtrackers (I know a lot of >companies) will sent Mantis to trash with this huge hole > > > I use Mantis on my personal site, and I have no problems running with this patch. You're making a mountain out of a mole-hill. >CS> You don't have to plan for the worst case senerio with every line of >CS> code >Be ready to worst is _first rule_ of every good programmer and real >admin > > > Which, in my opinion, is one of the contributors to buggy code. Coders spend so much time figuring out what to do with edge-cases, that they don't spend the proper time planning, writing, and debugging the core functionality of their program. Ever read 'The Inmates Are Running The Asylum'? Nice book on software design. Anyway... Back on topic. As I said, my patch could be a good starting point. I really do think I'm in favor of the solution put for by JP. Simple, secure. I'll change my patch to do that, if the Mantis Team would accept that. Chris |
From: Mitch \(WebCob\) <mi...@we...> - 2004-07-20 03:49:32
|
> So if I'm bored one day (it happens), I can spend the day resetting your > password.... > > The method Victor mentioned is fairly standard, and quite > acceptable, IMNSHO. > > -- > Live fast, die young, > You're sucking up my bandwidth. > > J.P. Pasnak, CD Ok - quote the standard? I can appreciate the security - as long as similar precations to what I added were taken - but where is it standard? I've never seen a system like that. m/ |
From: J.P. P. <pa...@wa...> - 2004-07-20 04:58:12
|
Mitch (WebCob) said: >> So if I'm bored one day (it happens), I can spend the day resetting yo= ur >> password.... >> >> The method Victor mentioned is fairly standard, and quite >> acceptable, IMNSHO. >> >> -- >> Live fast, die young, >> You're sucking up my bandwidth. >> >> J.P. Pasnak, CD > > Ok - quote the standard? > > I can appreciate the security - as long as similar precations to what I > added were taken - but where is it standard? > > I've never seen a system like that. > I didn't say it was _a standard_, I said 'The method is fairly standard'.= =20 In other words, I have seen it before, have used it before, and don't think it is too outrageous. --=20 Live fast, die young, You're sucking up my bandwidth. J.P. Pasnak, CD CCNA, LPIC-1 http://www.warpedsystems.sk.ca |