When a new user registers there is a screen that is horrible for security. It is the screen that shows the user the registration information that they just entered.

What in the world is their password doing being displayed in plain site? We blank out the password on entry, but display it to everyone shortly afterwards.

I've had a problem with this for a while just never got around to pointing this out until now.

I was showing our site to some bigwigs at our NOC when one of them was logging in showing everyone on a viewer. He registered for the site then, BANG, his password was displayed for everyone to see.

This should be changed ASAP.

=======================================
While I'm on the security issues.

When a user registers on the site, the site should not mail the user their password along with their username.

Again, poor security.

The username can be emailed, and later, if they forget their password, the password can be sent to their valid email address, but not along with their username.

The username and password should never be in the same email to a user.

I second all that ^

the email thing isn;t such an issue (its tradition that it will b in there. it goes without saying that it will be. hardly any cms-like systems dont do it).

however i totaly forgot about that signup thing. YES it should be changed. the very next version of df should come without that. good point mystic.

mc__ wrote:

the email thing isn;t such an issue (its tradition that it will b in there. it goes without saying that it will be. hardly any cms-like systems dont do it).

Tradition does not make it secure.

One of Dragonfly's main selling point is its security in code. Why toss that all out the window for tradition?

You should never see an organization such as a bank using that type of "tradition" on their site.

Sending passwords with usernames does not add to the functionality of Dragonfly, but the change would certainly add to its security.

i'll agree with mystic. the only time your password should be visible to you is when you request a forgotten password. period. that's being secure.

Has anyone got a temp workaround to replace the password on screen with 6 asterisks?

that should be easy enough if it's a form just replace the type=password and asterix should automatically display instead.

The email thing isn't a big deal. Signing up and emailing it is no different than requesting your password and emailing it. Both are visible through your email. Most users like to have it as a record of password so they can go back and retrieve it through their email system.

The first issue I do agree with.

Change line 154 of modules/Your_Account/register.php to

PHP:

<tr><td><b>'._PASSWORD.':</b></td><td>******</td></tr>.$content;

Thankyou!!

tank wrote:

The email thing isn't a big deal. Signing up and emailing it is no different than requesting your password and emailing it. Both are visible through your email.

As you say, email is visible and "in the clear" when it is being sent and easily intercepted and read. Let me explain how what I am talking about is certainly different.

The way it is being done now, if someone intercepts, or even "sees" an email with both the username and password on it, case cloased. All of the information to get into the account is handed to them in one nice package.

If, however, the password and username are only sent in different emails the task to use these to an advantage by some "sniffing" packets is greatly increased.

Here's how the email thing should work for increased security.

1. When a user signs up they can be sent a welcome to the website "username" email. There is no need to send them their password since they just signed up. If they choose to have the site generate a password you can add a line in the email stating that their password will be sent to them in another message.

2. If a user forgets their password and requests it to be sent to them, then send them just the password, not the username and password. They already know their username, that's how they were able to request their password.

3. If they need both their username and password sent because they used their email address to request the information, then the same procedure as step #1 above can be used.

tank wrote:

Most users like to have it as a record of password so they can go back and retrieve it through their email system.

I understand this, and frankly I do this as well.

My suggestions are not designed to make the user's life easier, they are designed to increase security for a CMS that advertises security as one of its main selling points.

My final request is that there should be a setting to not allow the site to "remember" user logins. If you want the site to be used as a more secure site, then you do not want the user to be "remembered" every time they return. For positive ID type sites the administrator should be able to set it so that the users MUST login each time they visit the site.

Ok, I fixed the password issue in all places. I believe, that I also disabled the username from the lost password email. Here is the code:

modules/your_account/register.php

line 154:

Code::

<tr><td><b>'._PASSWORD.':</b></td><td>*******</td></tr>'.$content;

line 232:

Code::

$message .= _TOAPPLY." $sitename.\n\n"._WAITAPPROVAL."\n\n"._FOLLOWINGMEM."\n"._USERNAME.": $username\n"._PASSWORD.": *******";

line 249:

Code::

$message .= _FOLLOWINGMEM."\n"._USERNAME.": $username\n"._PASSWORD.": ******";

line 251:

Code::

$message .= _TOAPPLY." $sitename.\n\n"._WAITAPPROVAL."\n\n"._FOLLOWINGMEM."\n"._USERNAME.": $username\n"._PASSWORD.": ******";

To disable username in email:

modules/your_account/index.php

line 98:

Code::

$message = _USERACCOUNT." ******* "._AT." $sitename "._HASTHISEMAIL." "._AWEBUSERFROM." ".decode_ip($userinfo["user_ip"])." "._HASREQUESTED."\n\n"._YOURNEWPASSWORD." $newpass\n\n "._YOUCANCHANGE." ".getlink('Your_Account', true, true)."\n\n"._IFYOUDIDNOTASK;

This works for me...but no guarantees as I am not a PHP/MySQL dev. Hope this helps.

Since we're speaking of passwords, I shall bring up another issue thats always bothered me. If you have another superuser besides yourself, and use SMTP your password is in the open.

admin.php?op=settings&s=7

I fully realize that the devs and Jr. devs are very busy, but it would be nice to see some, if not all, of these issues addressed in the next core release.

Many admins have come to Dragonfly for its security-conscience appraoch and I would like to see security of the CMS remain a priority.

I agree 100% and yes, you are right, the current devs are stretched to the max. Heck, I'm even having trouble finding a pocking programmer or two for the Forums.

I would like to see the security measures you've spoken on implimented into the core.