- Development - lists.drupal.org

[drupal-devel] [feature] Request New Password Security
by Jose A Reyero 31 Mar '05

31 Mar '05

Issue status update for http://drupal.org/node/18719 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: critical Assigned to: Anonymous Reported by: neofactor Updated by: Jose A Reyero Status: patch /Couldn't those nested if statements be made into one with a bit cleaner indentation?/ Maybe, but I had to split that if conditions in two parts because the $account var didn't get the value before the rest of the conditions -latest two- where evaluated. Someone can help with PHP here? /It looks like the page which the user arrives at after getting the new login information is their user page, not a page to set the password. The "Time out for password recovery e-mail" configuration is very unfriendly. It should be a drop down select of the most used human readable durations. Or we could just decide on one timeout and leave that hard coded in; who actually needs to use that setting?/ Agreed, will be polishing this a little bit, just wating for some more suggestions... For the duration, I'll change to 'hours', ok? Just don't like to restrict options using unneccessary dropdowns, it's only intended for administrators anyway. Maybe I add also a '0' for unlimited. Hardcoding it, would need anyway to be mentioned in the module help, so it's about the same overhead, both for coding and for the admin interface, and harcoding in two places in code is not good anyway. And I like having options, am I the only one? / The url is quite long, what could be done to make it shorter?/ Well, the url has to be long, it has neccessary params and an MD5 hash, which yes, could be cut someway, but that adding inneccessary code and also reducing security -though half an MD5 hash may be secure enough- but I see no point in that. Jose A Reyero Previous comments: ------------------------------------------------------------------------ March 11, 2005 - 03:52 : neofactor Problem: Any user can force another user's password to change... simply by selecting "request new password" and putting in their username. The user gets an email with the new.. but this feels like a violation to the user... and a pain. Solution? If someone requests a new password... Don't blindly change it... send an email that says...."Is this a real request authorized by you? Click here to confirm otherwise disregard this message" Please consider this critical for user by-in to Drupal as a secure system. I appreciate your consideration. http://drupal.org/node/18689 ------------------------------------------------------------------------ March 11, 2005 - 05:05 : neofactor I added some code to prevent the admin account from being reset... Please add as a patch. if ($account->uid == 1 { unset($account); form_set_error('name', t('Sorry. The username %name is not allowed to be changed.', array('%name' => ''. $edit['name'] .''))); } // Just above this code on line 911: if ($account) { $from = variable_get('site_mail', ini_get('sendmail_from')); $pass = user_password(); ------------------------------------------------------------------------ March 11, 2005 - 05:08 : killes(a)www.drop.org Please only set to "patch" if you are actually submitting one. The solution you proposed is rather a workaround and will not be acceptable for core. ------------------------------------------------------------------------ March 11, 2005 - 09:21 : Deno I was in charge of a web site with >10000 paying customers for some time, and the "customers care" was constantly troubled with pasword change requests, until we switched to a system that worked in the following way: 1) "I forgot the password" function accepts either users email, or users login name, generates a random phrase, and adds an entry to "pasword_change_request" table. This entry consists of: - User ID (corresponding to email or login) - random phrase - datestamp User ID is unique key, and the entries in this table older than MAX_TIME are regularly purged by a cron job. 2) System sends an email with a link to "change forgotten password" page with this random phrase as argument to the user. That would be something like: https://drupal.org/user/cfp/d438rwiuodw894732ehdw 3) When user follows the link, "cfp" page checks if the random phrase exists in the table, allows the user to immediately change the password, and sends another email with "your password was changed on RIGHT_NOW ... " note to the user in question. - Password change automatically triggers deleting of the corresponding entry in pasword_change_request table. - Password change automatically logs-in the user as well. This way, users weren't bothered by accidental password changes, and they also understood the system better than the one with automatically generated passwords. For additional security, we also built some brakes that assured that the number of attempts to change the password, such as: - "An email with instructions was sent to you X minutes ago. In case you don't receive it within N hours, please contact the site administrator" - "According to our logs, you have visited the CFP page more than NMAX times within last 24 hours. For security reasons, you will be denied access to this page for the next 24 hours. Please contact the site administrator." hope this helps... ------------------------------------------------------------------------ March 30, 2005 - 21:01 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login.patch (6.52 KB) This patch for -cvs- addresses this issue. It generates an *only one use* URL to login into user account, instead of a new password. Then the user clicks on the URL, logs in, and may change his old password if desired. It is a only one use URL, and has some additional security measures, like a configurable time-out -can be confgured in admin/user/settings- and also, if somebody uses it or password is changed in the meanwhile, previously generated login URLs of this type won't work. About how it works, it creates a new url with: - user id, - timestamp - a hash of current timestamp, changed date for account, and the old password hashed With this patch, this wont work for admin accounts, which I think is better, you never know... It has a number of features like: - User can be ignoring these emails if somebody else is requesting access, a new password request wont change current password. However, the user will be warned when seeing the emails - It reveals no sensible information about the user account in the URL itself - the generated hash is not predictable at all if you dont know the old password, as it depends on user's old password - there's a configurable timeout - The URL's are only one use, as they depend on two timestamps, one of which will be changing in case this login is used -or in case user logs in for other means - Any 'new password' request is independent of others, so no one can be interfering with one user asking for his password back. Also doesn't require any new db field nor keeping track of requested passwords. ------------------------------------------------------------------------ March 30, 2005 - 21:41 : chx Very nice patch. Please consider for 4.6. ------------------------------------------------------------------------ March 30, 2005 - 23:16 : drumm Couldn't those nested if statements be made into one with a bit cleaner indentation? It looks like the page which the user arrives at after getting the new login information is their user page, not a page to set the password. The "Time out for password recovery e-mail" configuration is very unfriendly. It should be a drop down select of the most used human readable durations. Or we could just decide on one timeout and leave that hard coded in; who actually needs to use that setting? The url is quite long, what could be done to make it shorter?

1 0

[drupal-devel] Release critical bugs for March 31, 2005
by drupal-devel＠drupal.org 31 Mar '05

31 Mar '05

Bbcode / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 10 weeks 4 days url: http://drupal.org/node/15654 Buddylist / bug reports SQL errors using HEAD from CVS age: 4 weeks 1 day url: http://drupal.org/node/18160 Chatbox / support requests Cron run kills Chat? age: 16 weeks 1 day url: http://drupal.org/node/14032 Drupal / bug reports Search ranking broken on pgsql age: 1 day 20 hours url: http://drupal.org/node/19629 When I ?q=node/add/forum, get:sprintf(): Too few arguments in /var/www/html/krsna/engine/includes/database.inc on line 147. age: 1 week 4 days url: http://drupal.org/node/19138 New submit error, non-admin user, postgresql database age: 3 weeks 1 day url: http://drupal.org/node/18552 Module-specific taxonomony support breaks existing sites assigned: walkah age: 3 weeks 3 days url: http://drupal.org/node/18471 PHP 4.3.11 and upload in IE age: 5 weeks 4 days url: http://drupal.org/node/17595 When I delete a user, any forum in which s/he has commented also disappears. assigned: Jill6q age: 6 weeks 5 hours url: http://drupal.org/node/17428 Path module allows one to override existing (non-aliased) paths. age: 6 weeks 1 day url: http://drupal.org/node/17386 Published poll doesnt show up in poll block if in submission queue age: 7 weeks 6 days url: http://drupal.org/node/16671 Adding two custom blocks with the same name produces a sql warning age: 7 weeks 6 days url: http://drupal.org/node/16659 Change to sesssion.inc violates UID database constraint age: 10 weeks 3 days url: http://drupal.org/node/15666 problem with forum.module with postgresql v7.4.1 age: 11 weeks 2 days url: http://drupal.org/node/15412 forum.module problem with postgresql v7.4.1 age: 11 weeks 2 days url: http://drupal.org/node/15411 PHP 5 gives error when session table has no session assigned: adschar age: 11 weeks 2 days url: http://drupal.org/node/15399 postgresql error age: 12 weeks 52 min url: http://drupal.org/node/15175 Entering an empty title broke drupal age: 19 weeks 2 days url: http://drupal.org/node/12974 Argument NOT must be type boolean age: 19 weeks 2 days url: http://drupal.org/node/12950 Private downloads aren't working age: 21 weeks 5 days url: http://drupal.org/node/12267 Comments in approval queue still show up in tracker age: 23 weeks 4 days url: http://drupal.org/node/11647 Twin problems with comments assigned: Junyor age: 24 weeks 6 days url: http://drupal.org/node/11366 Drupal / feature requests Taxonomy module should use nodeapi 'load' age: 3 weeks 5 hours url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 5 weeks 2 days url: http://drupal.org/node/17663 Don't reset existing password on request, prevent DoS password reset abuse age: 7 weeks 2 days url: http://drupal.org/node/16909 User info exposed to anonymous user age: 17 weeks 5 days url: http://drupal.org/node/13545 Allow named anchors to work without specifying full path to node age: 1 year 18 weeks url: http://drupal.org/node/4213 Drupal / support requests Fatal error: Unknown column 'headers' in 'field list' query assigned: Eagle-i age: 2 weeks 1 day url: http://drupal.org/node/18928 Strange session behavior age: 2 weeks 3 days url: http://drupal.org/node/18821 user redirected to homepage when logging in age: 3 weeks 5 days url: http://drupal.org/node/18381 Problem with Forums age: 11 weeks 4 days url: http://drupal.org/node/15299 Drupal / tasks atom.module working version to 4.5.0 assigned: hugoromano age: 21 weeks 8 hours url: http://drupal.org/node/12496 Consistency assigned: stefan nagtegaal age: 26 weeks 5 days url: http://drupal.org/node/11045 Drupal.org maintenance / bug reports drupaldocs.org and large fonts age: 3 weeks 5 days url: http://drupal.org/node/18367 Drupal.org print preview crashes Mozilla age: 4 weeks 10 hours url: http://drupal.org/node/18248 Konqueror problem age: 7 weeks 2 days url: http://drupal.org/node/16913 screenshots : page not found age: 7 weeks 5 days url: http://drupal.org/node/16752 Large Fonts problems age: 7 weeks 6 days url: http://drupal.org/node/16664 Drupal.org maintenance / feature requests Plain text posting age: 6 weeks 2 days url: http://drupal.org/node/17335 Event / bug reports Events for March 31, 2005 not showing up in calendar view age: 2 weeks 2 days url: http://drupal.org/node/18885 Doesn't work with i18n hack/module age: 4 weeks 1 day url: http://drupal.org/node/18145 search over fields.inc fields conceptual error age: 21 weeks 6 days url: http://drupal.org/node/12259 fields.inc screws up with multible multiselect fields age: 21 weeks 6 days url: http://drupal.org/node/12257 Still GMT/TZ issues with CVS age: 22 weeks 6 days url: http://drupal.org/node/11870 Time entry is GMT even when site default is not age: 23 weeks 4 days url: http://drupal.org/node/11630 Start Time of Event is NOT Preserved age: 40 weeks 6 days url: http://drupal.org/node/8565 Feature / bug reports Menu item not showing age: 25 weeks 5 days url: http://drupal.org/node/11210 File / bug reports segmentation fault related to filestore age: 1 year 26 weeks url: http://drupal.org/node/3001 Filestore / support requests File store module - Overwriting Filename....Help needed assigned: harishkm age: 52 weeks 13 hours url: http://drupal.org/node/6827 Unserialize error at line 104 age: 1 year 6 weeks url: http://drupal.org/node/5857 Filestore module- sql errors rectified assigned: harishkm age: 1 year 7 weeks url: http://drupal.org/node/5619 Filestore Module Problems unaddressed assigned: harishkm age: 1 year 9 weeks url: http://drupal.org/node/5365 Gallery / bug reports no images displayed in drupal 4.6-RC but they are displayed by gallery2 age: 5 days 48 min url: http://drupal.org/node/19467 Fatal Error: variable_get() age: 1 week 3 days url: http://drupal.org/node/19189 No Gallery Image Block age: 1 week 6 days url: http://drupal.org/node/19045 Mini applet can't find gallery at url / age: 2 weeks 4 days url: http://drupal.org/node/18785 "Cannot modify header information" age: 3 weeks 3 days url: http://drupal.org/node/18457 Fatal error: Undefined class name 'galleryembed' age: 5 weeks 1 day url: http://drupal.org/node/17746 Gallery / support requests Can't Embed Gallery into Drupal age: 4 weeks 3 days url: http://drupal.org/node/18029 Groups / bug reports Drupal-4.4-rc breaks registration setups and groups.module age: 1 year 2 weeks url: http://drupal.org/node/6392 Image / bug reports Cannot upload .jpgs age: 4 weeks 3 days url: http://drupal.org/node/18076 Wrongly formed html in image gallery age: 5 weeks 6 days url: http://drupal.org/node/17462 Image.Module does not know the correct filename age: 19 weeks 1 day url: http://drupal.org/node/13032 SAFE MODE Restriction in effect... age: 22 weeks 6 days url: http://drupal.org/node/11843 Uploading jpeg makes Imagemagick do high compression age: 24 weeks 3 days url: http://drupal.org/node/11445 Image module failing on Preview because of a blank node id age: 26 weeks 4 days url: http://drupal.org/node/11069 Similar problem with Directory Upload Slow age: 26 weeks 4 days url: http://drupal.org/node/11064 Node Aggregator / bug reports Please update Node_Aggregator age: 1 week 5 days url: http://drupal.org/node/19096 Import doesn't like XML/RSS feeds with no Title element age: 43 weeks 4 days url: http://drupal.org/node/8128 Node Aggregator / feature requests RSS items overwriting edited items age: 41 weeks 5 days url: http://drupal.org/node/8455 Notify / feature requests Notify.module ignores the true submission queue age: 1 year 22 weeks url: http://drupal.org/node/3765 Online / support requests Need Help age: 5 weeks 6 days url: http://drupal.org/node/17475 Pdfview / feature requests Internationalization support for PDF assigned: TheLibrarian age: 1 year 14 hours url: http://drupal.org/node/6795 Project / bug reports Invalid link to release files age: 5 weeks 3 days url: http://drupal.org/node/17625 blank page after install age: 8 weeks 1 day url: http://drupal.org/node/16575 "Page Not Found" when trying to view issues or add new release age: 16 weeks 6 days url: http://drupal.org/node/13815 Project pages display only title and description age: 19 weeks 3 hours url: http://drupal.org/node/13082 Fatal error: Cannot use string offset as an array in includes/tablesort.inc on line 113 assigned: publian age: 25 weeks 6 days url: http://drupal.org/node/11187 Can't create new project with issue tracker age: 32 weeks 17 hours url: http://drupal.org/node/10148 Project / support requests Help with everything - nothing seems to work in the latest build age: 18 weeks 2 days url: http://drupal.org/node/13310 Taxonomy dhtml / bug reports MySQL Error age: 5 days 21 hours url: http://drupal.org/node/19413 javascrip downloads square.gif for every category age: 6 weeks 1 day url: http://drupal.org/node/17366 TrackBack / bug reports Sends trackbacks for unpublished nodes age: 9 weeks 4 hours url: http://drupal.org/node/16239 Overly aggressive age: 16 weeks 5 days url: http://drupal.org/node/13865 trackback borks google and every other search engine age: 21 weeks 2 days url: http://drupal.org/node/12388 User experience / bug reports user interface problem http://drupal.org/forum/1?from=25 age: 4 weeks 15 hours url: http://drupal.org/node/18237 User experience / tasks WorkFlow and Action Module age: 5 weeks 5 days url: http://drupal.org/node/17517 Weblink / feature requests Display of child categories on the weblink directory default page age: 6 weeks 6 days url: http://drupal.org/node/17132 Display of child categories on the weblink directory default page age: 6 weeks 6 days url: http://drupal.org/node/17130

1 0

[drupal-devel] [feature] Request New Password Security
by drumm 31 Mar '05

31 Mar '05

Issue status update for http://drupal.org/node/18719 Project: Drupal Version: cvs Component: user.module Category: feature requests Priority: critical Assigned to: Anonymous Reported by: neofactor Updated by: drumm Status: patch Couldn't those nested if statements be made into one with a bit cleaner indentation? It looks like the page which the user arrives at after getting the new login information is their user page, not a page to set the password. The "Time out for password recovery e-mail" configuration is very unfriendly. It should be a drop down select of the most used human readable durations. Or we could just decide on one timeout and leave that hard coded in; who actually needs to use that setting? The url is quite long, what could be done to make it shorter? drumm Previous comments: ------------------------------------------------------------------------ March 10, 2005 - 20:52 : neofactor Problem: Any user can force another user's password to change... simply by selecting "request new password" and putting in their username. The user gets an email with the new.. but this feels like a violation to the user... and a pain. Solution? If someone requests a new password... Don't blindly change it... send an email that says...."Is this a real request authorized by you? Click here to confirm otherwise disregard this message" Please consider this critical for user by-in to Drupal as a secure system. I appreciate your consideration. http://drupal.org/node/18689 ------------------------------------------------------------------------ March 10, 2005 - 22:05 : neofactor I added some code to prevent the admin account from being reset... Please add as a patch. if ($account->uid == 1 { unset($account); form_set_error('name', t('Sorry. The username %name is not allowed to be changed.', array('%name' => ''. $edit['name'] .''))); } // Just above this code on line 911: if ($account) { $from = variable_get('site_mail', ini_get('sendmail_from')); $pass = user_password(); ------------------------------------------------------------------------ March 10, 2005 - 22:08 : killes(a)www.drop.org Please only set to "patch" if you are actually submitting one. The solution you proposed is rather a workaround and will not be acceptable for core. ------------------------------------------------------------------------ March 11, 2005 - 02:21 : Deno I was in charge of a web site with >10000 paying customers for some time, and the "customers care" was constantly troubled with pasword change requests, until we switched to a system that worked in the following way: 1) "I forgot the password" function accepts either users email, or users login name, generates a random phrase, and adds an entry to "pasword_change_request" table. This entry consists of: - User ID (corresponding to email or login) - random phrase - datestamp User ID is unique key, and the entries in this table older than MAX_TIME are regularly purged by a cron job. 2) System sends an email with a link to "change forgotten password" page with this random phrase as argument to the user. That would be something like: https://drupal.org/user/cfp/d438rwiuodw894732ehdw 3) When user follows the link, "cfp" page checks if the random phrase exists in the table, allows the user to immediately change the password, and sends another email with "your password was changed on RIGHT_NOW ... " note to the user in question. - Password change automatically triggers deleting of the corresponding entry in pasword_change_request table. - Password change automatically logs-in the user as well. This way, users weren't bothered by accidental password changes, and they also understood the system better than the one with automatically generated passwords. For additional security, we also built some brakes that assured that the number of attempts to change the password, such as: - "An email with instructions was sent to you X minutes ago. In case you don't receive it within N hours, please contact the site administrator" - "According to our logs, you have visited the CFP page more than NMAX times within last 24 hours. For security reasons, you will be denied access to this page for the next 24 hours. Please contact the site administrator." hope this helps... ------------------------------------------------------------------------ March 30, 2005 - 14:01 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login.patch (6.52 KB) This patch for -cvs- addresses this issue. It generates an *only one use* URL to login into user account, instead of a new password. Then the user clicks on the URL, logs in, and may change his old password if desired. It is a only one use URL, and has some additional security measures, like a configurable time-out -can be confgured in admin/user/settings- and also, if somebody uses it or password is changed in the meanwhile, previously generated login URLs of this type won't work. About how it works, it creates a new url with: - user id, - timestamp - a hash of current timestamp, changed date for account, and the old password hashed With this patch, this wont work for admin accounts, which I think is better, you never know... It has a number of features like: - User can be ignoring these emails if somebody else is requesting access, a new password request wont change current password. However, the user will be warned when seeing the emails - It reveals no sensible information about the user account in the URL itself - the generated hash is not predictable at all if you dont know the old password, as it depends on user's old password - there's a configurable timeout - The URL's are only one use, as they depend on two timestamps, one of which will be changing in case this login is used -or in case user logs in for other means - Any 'new password' request is independent of others, so no one can be interfering with one user asking for his password back. Also doesn't require any new db field nor keeping track of requested passwords. ------------------------------------------------------------------------ March 30, 2005 - 14:41 : chx Very nice patch. Please consider for 4.6.

1 0

[drupal-devel] [feature] Introduce crawl delay in robots.txt
by Morbus Iff 30 Mar '05

30 Mar '05

Issue status update for http://drupal.org/node/14177 Project: Drupal Version: cvs Component: other Category: feature requests Priority: minor Assigned to: bertboerland(a)www.drop.org Reported by: bertboerland(a)www.drop.org Updated by: Morbus Iff Status: patch It appears that robots.txt was removed in 2002 [1]. [1] http://cvs.drupal.org/viewcvs/drupal/drupal/Attic/robots.txt?rev=1.2&hideat… Morbus Iff Previous comments: ------------------------------------------------------------------------ December 10, 2004 - 05:29 : bertboerland(a)www.drop.org Though it is not "a standard" within the "non standard" robots.txt, many bots obey the "Crawl-delay:" parameter. Since drupal sites seem to be popular with search engines and lost of people have more aggresive bots than visitors at their site, it might be wise to slow down the robots by adding a robots.txt line like: User-Agent: * Crawl-Delay: 10 (time in seconds between page requests) Slurp (yahoo/AV) and MSFT bots obey this paramter, Googlebot not yet but will most likely in 2.1+ Does it makes sense to ship drupal with a default robots.txt with this parameter? If so, then there should be something in the documentaion about moving this to docroot in case drupal is installed in a subdirectory. ------------------------------------------------------------------------ March 30, 2005 - 14:41 : bertboerland(a)www.drop.org Seems like there is no robots.txt anymore in cvs? The old one was something like (delay added) # small robots.txt # more information about this file can be found at # http://www.robotstxt.org/wc/robots.html # if case your drupal site is in a directory # lower than your docroot (e.g. /drupal) # please add this before the /-es below # to stop a polite robot indexing an exampledir # add a line like # user-agent: polite-bot # Disallow: /exampledir/ # a list of know bots can be found at # http://www.robotstxt.org/wc/active/html/index.html # see http://www.sxw.org.uk/computing/robots/check.html # for syntax checking User-agent: * Crawl-Delay: 10 Disallow: /?q=admin Disallow: /admin/ Disallow: /cron.php Disallow: /xmlrpc.php Disallow: /database/ Disallow: /includes/ Disallow: /modules/ Disallow: /scripts/ Disallow: /themes/ Disallow: */add/

1 0

[drupal-devel] [feature] Request New Password Security
by chx 30 Mar '05

30 Mar '05

Issue status update for http://drupal.org/node/18719 Project: Drupal -Version: 4.5.2 +Version: cvs Component: user.module Category: feature requests Priority: critical Assigned to: Anonymous Reported by: neofactor Updated by: chx Status: patch Very nice patch. Please consider for 4.6. chx Previous comments: ------------------------------------------------------------------------ March 11, 2005 - 03:52 : neofactor Problem: Any user can force another user's password to change... simply by selecting "request new password" and putting in their username. The user gets an email with the new.. but this feels like a violation to the user... and a pain. Solution? If someone requests a new password... Don't blindly change it... send an email that says...."Is this a real request authorized by you? Click here to confirm otherwise disregard this message" Please consider this critical for user by-in to Drupal as a secure system. I appreciate your consideration. http://drupal.org/node/18689 ------------------------------------------------------------------------ March 11, 2005 - 05:05 : neofactor I added some code to prevent the admin account from being reset... Please add as a patch. if ($account->uid == 1 { unset($account); form_set_error('name', t('Sorry. The username %name is not allowed to be changed.', array('%name' => ''. $edit['name'] .''))); } // Just above this code on line 911: if ($account) { $from = variable_get('site_mail', ini_get('sendmail_from')); $pass = user_password(); ------------------------------------------------------------------------ March 11, 2005 - 05:08 : killes(a)www.drop.org Please only set to "patch" if you are actually submitting one. The solution you proposed is rather a workaround and will not be acceptable for core. ------------------------------------------------------------------------ March 11, 2005 - 09:21 : Deno I was in charge of a web site with >10000 paying customers for some time, and the "customers care" was constantly troubled with pasword change requests, until we switched to a system that worked in the following way: 1) "I forgot the password" function accepts either users email, or users login name, generates a random phrase, and adds an entry to "pasword_change_request" table. This entry consists of: - User ID (corresponding to email or login) - random phrase - datestamp User ID is unique key, and the entries in this table older than MAX_TIME are regularly purged by a cron job. 2) System sends an email with a link to "change forgotten password" page with this random phrase as argument to the user. That would be something like: https://drupal.org/user/cfp/d438rwiuodw894732ehdw 3) When user follows the link, "cfp" page checks if the random phrase exists in the table, allows the user to immediately change the password, and sends another email with "your password was changed on RIGHT_NOW ... " note to the user in question. - Password change automatically triggers deleting of the corresponding entry in pasword_change_request table. - Password change automatically logs-in the user as well. This way, users weren't bothered by accidental password changes, and they also understood the system better than the one with automatically generated passwords. For additional security, we also built some brakes that assured that the number of attempts to change the password, such as: - "An email with instructions was sent to you X minutes ago. In case you don't receive it within N hours, please contact the site administrator" - "According to our logs, you have visited the CFP page more than NMAX times within last 24 hours. For security reasons, you will be denied access to this page for the next 24 hours. Please contact the site administrator." hope this helps... ------------------------------------------------------------------------ March 30, 2005 - 21:01 : Jose A Reyero Attachment: http://drupal.org/files/issues/user_one_time_login.patch (6.52 KB) This patch for -cvs- addresses this issue. It generates an *only one use* URL to login into user account, instead of a new password. Then the user clicks on the URL, logs in, and may change his old password if desired. It is a only one use URL, and has some additional security measures, like a configurable time-out -can be confgured in admin/user/settings- and also, if somebody uses it or password is changed in the meanwhile, previously generated login URLs of this type won't work. About how it works, it creates a new url with: - user id, - timestamp - a hash of current timestamp, changed date for account, and the old password hashed With this patch, this wont work for admin accounts, which I think is better, you never know... It has a number of features like: - User can be ignoring these emails if somebody else is requesting access, a new password request wont change current password. However, the user will be warned when seeing the emails - It reveals no sensible information about the user account in the URL itself - the generated hash is not predictable at all if you dont know the old password, as it depends on user's old password - there's a configurable timeout - The URL's are only one use, as they depend on two timestamps, one of which will be changing in case this login is used -or in case user logs in for other means - Any 'new password' request is independent of others, so no one can be interfering with one user asking for his password back. Also doesn't require any new db field nor keeping track of requested passwords.

1 0

[drupal-devel] Official release cycle status.
by Adrian Rossouw 30 Mar '05

30 Mar '05

I saw an intriguing image on the Blended.org page .. which linked me to : http://www.blender3d.org/cms/The_Release_Cycle.361.0.html Essentially they display the status of their release cycle on the main page, to keep the community and the developers aware of the current development goals. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

1 0

[drupal-devel] [feature] Request New Password Security
by Jose A Reyero 30 Mar '05

30 Mar '05

Issue status update for http://drupal.org/node/18719 Project: Drupal Version: 4.5.2 Component: user.module Category: feature requests Priority: critical Assigned to: Anonymous Reported by: neofactor Updated by: Jose A Reyero -Status: active +Status: patch Attachment: http://drupal.org/files/issues/user_one_time_login.patch (6.52 KB) This patch for -cvs- addresses this issue. It generates an *only one use* URL to login into user account, instead of a new password. Then the user clicks on the URL, logs in, and may change his old password if desired. It is a only one use URL, and has some additional security measures, like a configurable time-out -can be confgured in admin/user/settings- and also, if somebody uses it or password is changed in the meanwhile, previously generated login URLs of this type won't work. About how it works, it creates a new url with: - user id, - timestamp - a hash of current timestamp, changed date for account, and the old password hashed With this patch, this wont work for admin accounts, which I think is better, you never know... It has a number of features like: - User can be ignoring these emails if somebody else is requesting access, a new password request wont change current password. However, the user will be warned when seeing the emails - It reveals no sensible information about the user account in the URL itself - the generated hash is not predictable at all if you dont know the old password, as it depends on user's old password - there's a configurable timeout - The URL's are only one use, as they depend on two timestamps, one of which will be changing in case this login is used -or in case user logs in for other means - Any 'new password' request is independent of others, so no one can be interfering with one user asking for his password back. Also doesn't require any new db field nor keeping track of requested passwords. Jose A Reyero Previous comments: ------------------------------------------------------------------------ March 11, 2005 - 03:52 : neofactor Problem: Any user can force another user's password to change... simply by selecting "request new password" and putting in their username. The user gets an email with the new.. but this feels like a violation to the user... and a pain. Solution? If someone requests a new password... Don't blindly change it... send an email that says...."Is this a real request authorized by you? Click here to confirm otherwise disregard this message" Please consider this critical for user by-in to Drupal as a secure system. I appreciate your consideration. http://drupal.org/node/18689 ------------------------------------------------------------------------ March 11, 2005 - 05:05 : neofactor I added some code to prevent the admin account from being reset... Please add as a patch. if ($account->uid == 1 { unset($account); form_set_error('name', t('Sorry. The username %name is not allowed to be changed.', array('%name' => ''. $edit['name'] .''))); } // Just above this code on line 911: if ($account) { $from = variable_get('site_mail', ini_get('sendmail_from')); $pass = user_password(); ------------------------------------------------------------------------ March 11, 2005 - 05:08 : killes(a)www.drop.org Please only set to "patch" if you are actually submitting one. The solution you proposed is rather a workaround and will not be acceptable for core. ------------------------------------------------------------------------ March 11, 2005 - 09:21 : Deno I was in charge of a web site with >10000 paying customers for some time, and the "customers care" was constantly troubled with pasword change requests, until we switched to a system that worked in the following way: 1) "I forgot the password" function accepts either users email, or users login name, generates a random phrase, and adds an entry to "pasword_change_request" table. This entry consists of: - User ID (corresponding to email or login) - random phrase - datestamp User ID is unique key, and the entries in this table older than MAX_TIME are regularly purged by a cron job. 2) System sends an email with a link to "change forgotten password" page with this random phrase as argument to the user. That would be something like: https://drupal.org/user/cfp/d438rwiuodw894732ehdw 3) When user follows the link, "cfp" page checks if the random phrase exists in the table, allows the user to immediately change the password, and sends another email with "your password was changed on RIGHT_NOW ... " note to the user in question. - Password change automatically triggers deleting of the corresponding entry in pasword_change_request table. - Password change automatically logs-in the user as well. This way, users weren't bothered by accidental password changes, and they also understood the system better than the one with automatically generated passwords. For additional security, we also built some brakes that assured that the number of attempts to change the password, such as: - "An email with instructions was sent to you X minutes ago. In case you don't receive it within N hours, please contact the site administrator" - "According to our logs, you have visited the CFP page more than NMAX times within last 24 hours. For security reasons, you will be denied access to this page for the next 24 hours. Please contact the site administrator." hope this helps...

1 0

[drupal-devel] [feature] Introduce crawl delay in robots.txt
by bertboerland 30 Mar '05

30 Mar '05

Issue status update for http://drupal.org/node/14177 Project: Drupal Version: cvs Component: other Category: feature requests Priority: minor -Assigned to: Anonymous +Assigned to: bertboerland(a)www.drop.org Reported by: bertboerland(a)www.drop.org Updated by: bertboerland(a)www.drop.org -Status: active +Status: patch Seems like there is no robots.txt anymore in cvs? The old one was something like (delay added) # small robots.txt # more information about this file can be found at # http://www.robotstxt.org/wc/robots.html # if case your drupal site is in a directory # lower than your docroot (e.g. /drupal) # please add this before the /-es below # to stop a polite robot indexing an exampledir # add a line like # user-agent: polite-bot # Disallow: /exampledir/ # a list of know bots can be found at # http://www.robotstxt.org/wc/active/html/index.html # see http://www.sxw.org.uk/computing/robots/check.html # for syntax checking User-agent: * Crawl-Delay: 10 Disallow: /?q=admin Disallow: /admin/ Disallow: /cron.php Disallow: /xmlrpc.php Disallow: /database/ Disallow: /includes/ Disallow: /modules/ Disallow: /scripts/ Disallow: /themes/ Disallow: */add/ bertboerland(a)www.drop.org Previous comments: ------------------------------------------------------------------------ December 10, 2004 - 11:29 : bertboerland(a)www.drop.org Though it is not "a standard" within the "non standard" robots.txt, many bots obey the "Crawl-delay:" parameter. Since drupal sites seem to be popular with search engines and lost of people have more aggresive bots than visitors at their site, it might be wise to slow down the robots by adding a robots.txt line like: User-Agent: * Crawl-Delay: 10 (time in seconds between page requests) Slurp (yahoo/AV) and MSFT bots obey this paramter, Googlebot not yet but will most likely in 2.1+ Does it makes sense to ship drupal with a default robots.txt with this parameter? If so, then there should be something in the documentaion about moving this to docroot in case drupal is installed in a subdirectory.

1 0

[drupal-devel] Drupal ID issues with spacing and information
by Carl McDade 30 Mar '05

30 Mar '05

I have posted an issue on this but I need to fix the problem today. A user has been allowed to use 'Name N' and recived a DrupalId of 'N(a)www.site.com/map' it should have been changed to 'Name_N(a)www.site.com/map' or a warning given. This did not happen and as result the Drupal ID cannot be used. I also cannot find any information on fixing or changing a DrupalID. An insights or help is appreciated. Carl McDade

1 0

[drupal-devel] holiday marketing
by Dries Buytaert 30 Mar '05

30 Mar '05

http://www.buytaert.net/albums/vars-2005/3/ -- Dries Buytaert :: http://www.buytaert.net/

2 1