Zikula Community

• manarak
  
  

  • Rank: Helper
  • Registered: Dec 31, 1969
  • Last visit: May 20, 2010
  • Posts: 524

  Posted: Jan 26, 2004 - 12:38 AM

  Hi Mark
  
  Thumbs up for the work being done, I'm impressed that almost all of my requests are already filled!
  I am impatient to see .8!
  
  About the security problem, it is true that there are a lot of issues there.
  If the admin of a site was really looking to get the password of users, he could simply add some line of code to fork it out from the main scripts...
  I use several password "classes" depending on the security level I want. I use 3 different cycles of 3 passwords each:
  1- simple for PN sites and forums
  2- medium for sponsor program membership and online shops
  3- strong for admin functions, database access, online banking.
  But would anyone do the same?
  
  It is true that I try to hold the hand of my users in any possible way. If you would see what goes on here, you would do the same. I have already rewritten the description on how to obtain a new password in all supported languages on my site. I made a "connection refused" screen, explaining it may be because the password is wrong, I advise to copy-paste it from the mail, etc. and I also explain about cookies, and how to set cookies acception in the browser...
  
  Even I write that the password to access the site will be sent by mail, some users think it is clever to type mickeymouse@disney.com as an e-mail address and then complain by mail that they cannot access the site...
  
  Sometimes things have to be made very simple when security allows it.
  
  Maybe the amount of passwords not retrieved will be reduced by the ability to choose the password.
  
  Regards

  • 
  •  
• **unknown user**
  
  

  • Rank: Softmore
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 275

  Posted: Jan 26, 2004 - 01:08 AM

  markwest

  
  Thanks for taking the time to point out the flaw and come up with a solution.

  
  
  Thanks for your attention and for your efforts, Mark.

  • 
  •  
• **unknown user**
  
  

  • Rank: Helper
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 763

  Posted: Jan 28, 2004 - 07:30 AM

  While it is possible to make things easier, it is impossible to make them idiot proof. Anyone that believes that anything can be made idiot proof underestimates idiots. You'd have to be an idiot yourself to understand how they think (or don't) adn then you'd be no good at solving the problem. You can't understand an idiot or a genius unless you are one or the other and no group can truly understand the others. Every time you come up with a better plan that you are sure is idiot proof, along comes a better idiot to prove you wrong.
  
  They don't have to be Darwin Award candidates. There are a lot of people marginally above that level.
  
  I use PNCUserhack on my sites and its features are being included in .8 That will help. It does allow people to choose their own password. Storing unencrypted passwords is a very bad idea.
  
  The best solution I can think of is to have a registration scheme that works like this:
  1. At the registration page, the registrant gets to choose their own password and sees a notice (emphasized, perhaps in bold and red) that a confirmation notice is sent to the e-mail address they enter and that it needs to be valid.
  
  They further see that they have only completed step one of a two step process. They must activate their registration with the notice they are about to receive. Only then will they be able to login.
  
  2. When they receive the confirmation notice, they see, in order (Along with instructions), a clickable URL that will activate that registration. Next, because some e-mail programs strip such long URLs, a method to enter the activation code is supplied.
  
  Finally, (and here's something I have never seen) include instructions to write down their user name and password and store them in a safe place. This part should be emphasized also.
  
  I had a new member forget both his user name and password after just 2 days. Imagine if he had not included his real name in his registration. Incidentally, this points out why member lists must be searchable by e-mail addresses also.
  
  A means should be provided for the admin to delete unvalidated registrations. It could be done automatically after a set number of days. Perhaps the system could send them a notice to that effect, either before deletion and giving them one last chance or after deletion advising why they were deleted and inviting them to register again.
  
  Password change
  
  The admin should have the option of choosing from among two systems. The simplest, which works for many sites, would simply send a new password to the e-mail address on record either by user name of e-mail address. The notice they receive with the new password should include the instructions about saving it and storing in a secure location.
  
  Minus the instructions, a lot of large sites use this method. It is possible that aggravating people by forcing a new password upon them is not much of a problem.
  
  Let us not forget a method to help those people who lose access to the e-mail address they have on record.
  
  The other system, and apparently the one employed presently by PN (I've never used it) is to send a confirmation inquiry asking if they want to change their password. This is good for any site that may have a problem of this nature. There are a lot of nasty people in the world.
  
  Even so, sites with no need for the more stringent system should not be forced to use it.
  
  I worked with the developers of my former forum program on these matters (and hacked my own) and would gladly assist the PN developers on functionality and wording for the same features in PN.

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Jan 28, 2004 - 07:41 AM

  Duster,
  
  Thanks for the comments; appreciated as always.
  
  As each step of the process is represented by a template in the users module site admins can add as much or as little extra to the page as they see fit e.g. add a big STEP 1 OF 2 graphic in flashing neon yellow if they so wish. I've also included clickable links in the registration e-mails. I've not done the lost password part yet. Once I have i'd appreciate yourself, manarak and any others to register an account on my test site and tell me what you think of the layout and the process. The users module also provides a search option that includes searching by e-mail address. Periodic changes of password are something i've not thought about adding as yet and will probably have to wait until a future version.
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• manarak
  
  

  • Rank: Helper
  • Registered: Dec 31, 1969
  • Last visit: May 20, 2010
  • Posts: 524

  Posted: Jan 28, 2004 - 08:26 AM

  Duster
  
  Nobody, thank god, spoke about storing passwords unencrypted in the database!
  As you I raised the question wether to be able to choose between a 1-way encryption like MD5 (which is used by PN and which requires a 2-step password change procedure) and a 2-way encryption which would allow PN to retrieve the password and to send it by e-mail in the same step.
  
  Now Mark told this thought proves very difficult to realize, because it requires too much coding - I guess we will have to improve the registration and password resetting process as much as we can.
  Mark, I will be happy to be your "idiot" for testing the processes.
  
  Manarak.

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Jan 28, 2004 - 08:34 AM

  Manarak,
  
  What I said was that I wouldn't want to replace the current system with a two way encryption but since i'm opening up the authentication process to be more modular then a 3rd party could write such an authentication module. I personally wouldn't use it nor would I recommend others do so but each site admin would have the choice.
  
  I'll be sure to let you know when I need some testing.....
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• manarak
  
  

  • Rank: Helper
  • Registered: Dec 31, 1969
  • Last visit: May 20, 2010
  • Posts: 524

  Posted: Jan 28, 2004 - 08:50 AM

  Hello Mark
  
  I understand your position.
  However, when security is not a concern (for example when the site is just about gathering e-mail addresses or when the usernames are just used for commenting some babe pix) a 2-way encryption could do very well. As Duster pointed out, this system is currently used by many big websites - I guess they found that it works better if your site has a lot of "induhviduals" as members.
  My training as one of these has begun... <g>
  
  Manarak.</g>

  • 
  •  
• **unknown user**
  
  

  • Rank: Helper
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 763

  Posted: Jan 28, 2004 - 11:00 AM

  Actually, what I said is that a lot of sites use the method where they just send you a new password when one clicks on the lost password button. Either aggravating people by having their passwords changes is not much of a problem or an awful lot of sites are unresponsive to the problem. I expect it's the former. Having someone's password changed is a very ineffective method of aggravating someone.
  
  In one of the current discussions on passwords, someone suggested that the admin could retrieve them. For obvious reasons that is not possible at the moment. However, it may not be a good idea, especially for a site that has e-commerce. I'm not one to be overly concerned on a lot of little details as many are unlikely to ever happen.
  
  If a cracker breaks into a PN site with e-commerce and manages to charge anything with any credit cards used, maybe capturing the info as in the way some OpenSSH passwords have been captured, it could open the admin to suspicion at the very least. It's something to think about. Even with no legal liability, a site can get an unjustified (or maybe justified) reputation for being negligent.
  
  I've seen it happen as regards spamming, which is bad enough. None of my site members have ever been spammed by having their addresses harvested from my site. I've hacked my forum scripts to add protection, and had the develoepr add even more. A big commercial site, however, has had their posters spammed because they didn't take adequate protection. Consequently, people are more cautious there with their e-mail addresses and the site has a reputation for being easy for spammers to get to you.
  
  Things like passwords, especially if money is involved (e-commerce) require at least equal devotion to prevention.
  
  Remember, you're not paranoid if they are out to get you (or your site visitors).
  
  Paranoia is perfect awareness.

  • 
  •  
• **unknown user**
  
  

  • Rank: Helper
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 763

  Posted: Jan 28, 2004 - 11:10 AM

  Mark, you can count on me to help. We already have an idiot signed up. All we need is a couple of hobbits, a dwarf and an elf, and we're ready to go.

  • 
  •  
• Slugger
  
  

  • Rank: Expert
  • Registered: Mar 11, 2003
  • Last visit: Oct 21, 2009
  • Posts: 1104

  Posted: Feb 05, 2004 - 09:00 AM

  Just registered at a PHPNuke site that has the registration process I think Postnuke should have. Forget about compromising security because this, which is something I've brought up in these forums before, would do nothing of the sort!
  
  Registration should allow the site operator, who cares, to verify the registrant. This is currently done by sending a server-generated password to the email address given by the registrant. Unfortunately our current method is clumsy and there is a better way to do this!
  
  Regardless of what method the site operator chooses, a registrant should always be able to select a unique username and password they can easily remember. We can still require a functioning email address but, in the improved method, we do so by sending an authorization code which the registrant must use within 24 hours, along with their username and password, to activate their account.
  
  Let's think about this a second. As it now stands, the order is:
  
  1.) username and email address submitted by registrant
  2.) server generated code (password) sent to registrant's email address
  3.) registrant logs in with their username and the generated password.
  
  Instead, let's reorder the events:
  
  1.) username, password, and email address submitted by registrant
  2.) server generates an activation code sent to registrant's email address
  3.) registrant logs in with their password, their username, and the generated activation code.
  
  You'll note both scenarios have the same number of steps. You'll also notice, that, in the first scenario-the current scheme, the registrant does not have a personally selected password unless and until they CHANGE it.
  
  Forget about the fact that they may not know how to change their password! They're in with the server generated password. No wonder they can't remember it!
  
  In the second scenario, again same number of steps, we still confirm that the email address is legitimate but in this scenarion they make up their own password! Same number of steps, same number of server generated codes, and no less security. It's just a lot cleaner!
  
  I think anyone can see there are many advantages to the second scenario. One of which is fewer forgotten passwords.
  
  With the second scenario, because we know the difference between a first-time user and a regular, we can welcome them and even offer them a "tour" or tutorial. We can introduce them to whatever options we make available to them...different home page, themes, custom user block etc.
  
  Now, when they log in, a returning user and a first-time user look the same. Wouldn't it be better to treat them differently?
  
  Treating first-time users differently than regular users makes sense when it is to welcome them and familiarize them. It is not very welcoming to be forced to figure out how to lose that stupid computer-generated password when they may have no idea how to do it.
  
  If we improve the process and do a better job of introducing someone to the full functionality of our sites, we'll reduce the amount of work we have to do and increase the quality of our users’ experience. When, as in this case, it can be done without sacrificing anything, it needs to be done.
  
  Slugger

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Feb 05, 2004 - 09:13 AM

  Slugger,
  
  That's exactly one of the available signup processes available in the .8 users module.
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• Slugger
  
  

  • Rank: Expert
  • Registered: Mar 11, 2003
  • Last visit: Oct 21, 2009
  • Posts: 1104

  Posted: Feb 05, 2004 - 09:39 AM

  You really know how to make my parotid gland going.
  
  Slugger

  • 
  •  
• markwest
  
  

  • Rank: Team Member
  • Registered: Mar 18, 2002
  • Last visit: Oct 21, 2009
  • Posts: 6606

  Posted: Feb 05, 2004 - 09:45 AM

  I've got sidetracked on a couple of other small projects at the moment (strict HTML compliance for the xanthia themes and XHTML compatabilty and compliance for .8 ) but i'll be getting back to the users module this weekend so hopefully i'll have something for you guys to usabilty test for me towards the end of the weekend.
  
  -Mark
  
  --
  Visit My homepage and Zikula themes.

  • 
  •  
• **unknown user**
  
  

  • Rank: Helper
  • Registered: Mar 16, 2002
  • Last visit: Oct 21, 2009
  • Posts: 763

  Posted: Feb 05, 2004 - 11:26 AM

  Mark,
  
  I've been preparing a page for you outlining steps I would like to see. I'll e-mail you with the URL when I've finished. Meanwhile, here are 2 additions to the process. They come from ideas I suggested to the developers of the perl forum program I used prior to a PHP forum. They were implemented and work well. I still have a couple of forums operational on the old program (one for reading only) should you want to see it in action.
  
  As part of the registration process, acceptance of the rules must be acknowledged. I know PN has this too, but it merely has a link to them and a lot of people can easily skip it without ever knowing what they are. This system works by either importing a (HTML) page and adding a check box to acknowledge having read it, or presenting rules entered directly into the program. As my FAQ was rather lengthy, I used the entered rules and kept them short.
  
  The other feature took people on their first login to the member profile page. If no fields were marked as required, they wouldn't see it again unless they chose to add or change information later. If any fields were marked as required, they would have to complete those fields to get past this page, even on future logins.
  
  Naturally, this should be an option as some sites will not have need of it.
  
  The member profile was customizable, and highly customizable by hacking the script, which I did, but that is a different issue.

  • 
  •  
•  
•  

Users on-line

• frw

This list is based on users active over the last 60 minutes.