Page Index Toggle Pages: [1] 2 3 4
Topic Tools
Very Hot Topic (More than 25 Replies) Check usernames when registering (Read 20,147 times)
Unilat
Development Team
Theme Team
****
Offline



Posts: 1,047
Location: Columbus Ohio, USA
Re: Check usernames when registering
Reply #45 - Jul 13th, 2009 at 3:11am
Post Tools
Yes, deti that is correct. The only possible thing a user could cause by putting code into the form variables and then sending it is receiving an error message because the perl script doesn't know what to do. And if they get that, then it's deserved and will alert someone that there's an issue, considering my subroutine should never throw an error Wink Only return true or false.
  
Back to top
 
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Check usernames when registering
Reply #44 - Jul 13th, 2009 at 12:57am
Post Tools
Matt Siegman wrote on Jul 12th, 2009 at 11:55pm:
The code to handle potentially dangerous input would have to be in the Perl script.

That's what I was getting at. Wink
  
Back to top
WWW  
IP Logged
 
Matt Siegman
YaBB Legends (Inactive)
*
Offline



Posts: 3,380
Location: Wichita, KS
Re: Check usernames when registering
Reply #43 - Jul 12th, 2009 at 11:55pm
Post Tools
Well, the Javascript code is just to fix a bug.

The code to handle potentially dangerous input would have to be in the Perl script.
  

-- Matt Siegman 8) Wish List
Back to top
 
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Check usernames when registering
Reply #42 - Jul 12th, 2009 at 9:19pm
Post Tools
Unilat wrote on Jul 11th, 2009 at 11:34pm:
But it is still not needed on type or formsession as neither of these will ever have odd characters.

deti wrote on Jul 12th, 2009 at 9:04pm:
Right. And not insert by a user.

Not usually, no... but it can be inserted by a user, specifically a malicious user who is trying to create buffer overflows or simply take advantage of improper input sanitization.

If this is being done just to fix a bug, then you can do it in ajax.js... if this is being done to increase security (i.e. to prevent malicious users from trying to get the Perl script to run things it shouldn't be running), then you must sanitize all input in POST and GET fields, even if it comes from hidden fields that a normal user wouldn't touch.
  
Back to top
WWW  
IP Logged
 
deti
Legacy Dev Team
Development Team
****
Offline



Posts: 2,650
Location: Prien am Chiemsee, Germany
Re: Check usernames when registering
Reply #41 - Jul 12th, 2009 at 9:04pm
Post Tools
Unilat wrote on Jul 11th, 2009 at 11:34pm:
But it is still not needed on type or formsession as neither of these will ever have odd characters.


Right. And not insert by a user. So it must be in ajax.js:
Code
Select All
function checkAvail(scripturl,val,type) {
	GetXmlHttpObject();
	if (xmlHttp == null) { alert("AJAX not supported."); return; }
	var session = document.getElementsByName("formsession");
	var params = "type=" + type + "&" + type + "=" + encodeURIComponent(val) + "&formsession=" + session[0].value;
	xmlHttp.open("POST", scripturl + "?action=checkavail", true);
	xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
	xmlHttp.setRequestHeader("Content-length", params.length);
	xmlHttp.setRequestHeader("Connection", "close");
	xmlHttp.onreadystatechange=returnAvail;
	xmlHttp.send(params);
} 

  

Was immer Du tun kannst
oder erträumst tun zu können,
beginne es.
Kühnheit besitzt Genie,
Macht und magische Kraft.
Beginne es jetzt.
Whatever you can do
or dream you can,
begin it.
Boldness has genius,
power and magic in it.
Begin it now.
J. W. Goethe
Back to top
WWW  
IP Logged
 
Matt Siegman
YaBB Legends (Inactive)
*
Offline



Posts: 3,380
Location: Wichita, KS
Re: Check usernames when registering
Reply #40 - Jul 12th, 2009 at 12:32am
Post Tools
I didn't look at the values closely, you're correct. It's always a good idea to encode user input, whether or not certain things are allowed. Anything weird in the query string can cause strange results.
  

-- Matt Siegman 8) Wish List
Back to top
 
IP Logged
 
Unilat
Development Team
Theme Team
****
Offline



Posts: 1,047
Location: Columbus Ohio, USA
Re: Check usernames when registering
Reply #39 - Jul 11th, 2009 at 11:34pm
Post Tools
Neither type variables need encoding, as well as formsession. My register page says no & are allowed in usernames or display name. Mine also does no allow equal signs (=). When I hit register it says invalid character even though an equals sign is listed as valid.

So if this is true none of the components need encoding, especially now since POST is used.

Edited:
I take the second part back. No = are allowed in user ID (so the text needs to be changed for that...) but they are allowed in display name so encoding can be used on the val variable. But it is still not needed on type or formsession as neither of these will ever have odd characters.

« Last Edit: Jul 11th, 2009 at 11:38pm by Unilat »  
Back to top
 
IP Logged
 
Matt Siegman
YaBB Legends (Inactive)
*
Offline



Posts: 3,380
Location: Wichita, KS
Re: Check usernames when registering
Reply #38 - Jul 11th, 2009 at 8:50pm
Post Tools
deti wrote on Jul 11th, 2009 at 4:20pm:
deti wrote on Jul 10th, 2009 at 2:01pm:
@ Unilat
If I have a user called --#deti#-- and I try to regist other user with same name, your feature tells me that I can use this name, but if I click "Go" on the reg-page it tells me that I can't register!?!
It looks like the JS doesn't transmit the right name to the Perl-script. Can you give a look after this?

I think the problem is that we send the request with GET, so we will get wrong output if we have ; & # = in the username, displayname or email.
Unilat, is it possible to send the request with POST instead of GET via AJAX?

If that is the problem, it means that we aren't encoding our query strings properly in javascript before building the URL. We need to fix it by calling encodeURIComponent(). We need to do this with GET and POST.

Unilat's fix needs to be slightly changed:
Code
Select All
var params = "type=" + type + "&" + type + "=" + val + "&formsession=" + session[0].value;
 


Should be
Code
Select All
var params = "type=" + encodeURIComponent(type) + "&" + encodeURIComponent(type) + "=" + encodeURIComponent(val) + "&formsession=" + encodeURIComponent(session[0].value);
 

  

-- Matt Siegman 8) Wish List
Back to top
 
IP Logged
 
Jet Li
Legacy Dev Team
Development Team
****
Offline



Posts: 6,588
Location: Hong Kong
Re: Check usernames when registering
Reply #37 - Jul 11th, 2009 at 8:48pm
Post Tools
@ Unilat

will update later to SVN. Smiley
  

PM me for YaBB Installation Service
Back to top
WWWGTalkFacebook  
IP Logged
 
Unilat
Development Team
Theme Team
****
Offline



Posts: 1,047
Location: Columbus Ohio, USA
Re: Check usernames when registering
Reply #36 - Jul 11th, 2009 at 8:40pm
Post Tools
Updated in ajax.js:
Code
Select All
function checkAvail(scripturl,val,type) {
	GetXmlHttpObject();
	if (xmlHttp == null) { alert("AJAX not supported."); return; }
	var session = document.getElementsByName("formsession");
	var params = "type=" + type + "&" + type + "=" + val + "&formsession=" + session[0].value;
	xmlHttp.open("POST", scripturl + "?action=checkavail", true);
	xmlHttp.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
	xmlHttp.setRequestHeader("Content-length", params.length);
	xmlHttp.setRequestHeader("Connection", "close");
	xmlHttp.onreadystatechange=returnAvail;

	xmlHttp.send(params);
} 



Update in UserSelect.pl:
Code
Select All
sub checkUserAvail {
	my $taken = "false$FORM{'type'}";

	if ($FORM{'type'} eq "email") {
		$FORM{'email'} =~ s~\A\s+|\s+\z~~g;
		if (lc $FORM{'email'} eq lc &MemberIndex("check_exist", $FORM{'email'})) { $taken = "trueemail" };
	} elsif ($FORM{'type'} eq "display") {
		$FORM{'display'} =~ s~\A\s+|\s+\z~~g;
		if (lc $FORM{'display'} eq lc &MemberIndex("check_exist", $FORM{'display'})) { $taken = "truedisplay" };
	} elsif ($FORM{'type'} eq "user") {
		$FORM{'user'} =~ s~\A\s+|\s+\z~~g;
		$FORM{'user'} =~ s/\s/_/g;
		if (lc $FORM{'user'} eq lc &MemberIndex("check_exist", $FORM{'user'})) { $taken = "trueuser" };
	}

	print "Content-type: text/plain\n\n$taken";

	CORE::exit; # This is here only to avoid server error log entries!
} 

  
Back to top
 
IP Logged
 
Unilat
Development Team
Theme Team
****
Offline



Posts: 1,047
Location: Columbus Ohio, USA
Re: Check usernames when registering
Reply #35 - Jul 11th, 2009 at 5:20pm
Post Tools
Yes, I'll change it and post the code here in a bit.
  
Back to top
 
IP Logged
 
deti
Legacy Dev Team
Development Team
****
Offline



Posts: 2,650
Location: Prien am Chiemsee, Germany
Re: Check usernames when registering
Reply #34 - Jul 11th, 2009 at 4:20pm
Post Tools
deti wrote on Jul 10th, 2009 at 2:01pm:
@ Unilat
If I have a user called --#deti#-- and I try to regist other user with same name, your feature tells me that I can use this name, but if I click "Go" on the reg-page it tells me that I can't register!?!
It looks like the JS doesn't transmit the right name to the Perl-script. Can you give a look after this?

I think the problem is that we send the request with GET, so we will get wrong output if we have ; & # = in the username, displayname or email.
Unilat, is it possible to send the request with POST instead of GET via AJAX?
« Last Edit: Jul 11th, 2009 at 4:22pm by deti »  

Was immer Du tun kannst
oder erträumst tun zu können,
beginne es.
Kühnheit besitzt Genie,
Macht und magische Kraft.
Beginne es jetzt.
Whatever you can do
or dream you can,
begin it.
Boldness has genius,
power and magic in it.
Begin it now.
J. W. Goethe
Back to top
WWW  
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Check usernames when registering
Reply #33 - Jul 11th, 2009 at 6:13am
Post Tools
OH Eng wrote on Jul 11th, 2009 at 5:47am:
we aren't really trying to protect against hacking at all, merely the casual PITA user who might wreak havoc with a misplaced password.

Well, I think we'll just have to agree to disagree on this.  In my view, security by obscurity is no security at all... but this argument is still being debated even after many decades.

IMHO, security features shouldn't be put in place to prevent potential havoc from a potential PITA user who is potentially not very motivated... by having any security procedure in place, it creates a false sense of safety, leading most non-savvy admins to believe that by enabling this feature or that, they are somehow safe from various intrusions.  At least if the features weren't there, users would know to be more careful.

I know you have a lot of experience on the support side and I guess no users have actually complained about this, so that's a plus... but the potential is there, and you yourself have admitted that the consequences are unpleasant.

In any case, I guess I'll cut the argument short, because I don't think either of us will convince the other... suffice it to say that I think security should be done properly or not at all.  My opinion only (and since I'm not an official dev, I can't go modifying files willy-nilly anyway Wink).

(If you're interested, though, the Wikipedia article on security by obscurity is a fun and educational read.
« Last Edit: Jul 11th, 2009 at 6:14am by cepheid »  
Back to top
WWW  
IP Logged
 
OH Eng
Past Team Members
Documentation Team
Offline



Posts: 4,026
Location: Pensacola, Florida USA
Re: Check usernames when registering
Reply #32 - Jul 11th, 2009 at 5:47am
Post Tools
Again, we are not talking about a bank here.  Notice I said "more" secure, not "totally" secure.  Right now, there is NO security if a password is intercepted because it can by used with a plainly visible displayed name.

Now I don't doubt you can decloak a username if you wanted to, but I bet there are not that many out there who both 1. can and 2. would.  Thus even hiding the username from plain view would be a step in a more secure direction.  Just as we're not talking about world-class hackers, scale it down and we aren't really trying to protect against hacking at all, merely the casual PITA user who might wreak havoc with a misplaced password.

To me, it's not a big deal.  Leave it alone is probably the best thing.  There are other things to work on.


« Last Edit: Jul 11th, 2009 at 5:47am by OH Eng »  

 
Back to top
 
IP Logged
 
cepheid
Senior Member
****
Offline



Posts: 516
Re: Check usernames when registering
Reply #31 - Jul 11th, 2009 at 3:17am
Post Tools
OH Eng wrote on Jul 11th, 2009 at 2:42am:
We've heard all about how insecure the CAPTCHA was in this version or that... but I've never seen one user in all the time I've been here complain of their Validation Code being defeated.

My YaBB 2.1 forum was routinely attacked by completely automated spambots who were able to defeat the captcha because it could be deconstructed on-the-fly.  I've seen at least a few posts on this forum detailing the same with v2.1.  v2.2 and up don't have that problem because the spammers didn't bother writing a new system (although the new system was still easily breakable); the current version implemented in CVS/SVN is much more secure.

You're right that the captcha is much more about spam control than security, though I consider spam control a form of security, personally.

OH Eng wrote on Jul 11th, 2009 at 2:42am:
The theft of, or even accidental disclosure of an Admin or GMod password IS a security risk, and that risk can be minimized by removing one of the two keys needed to log in with.

You're referring to masking of the usernames, correct?  If so, then to reiterate what I said above, the cloaking algorithm is easily defeated right now and anyone attempting to hack an admin/gmod account could quite easily figure out the admin/gmod's username simply by running the decloak routine locally.  In order to be actually effective at masking the username, the cloaking routine must be based on a private key stored on the server and revealed to no-one (just like the captcha).  Even if you turn off displayname login, the current implementation of the cloak is little more than a waste of processing cycles.  I'll also reiterate that cloaking of the username (assuming it is done properly, based on a private key) would be useful only for forums that also require the displayname to differ from the userid; those two options should be tied together, since one is useless without the other.

(I should also note that every YaBB forum, out of the box, creates an admin user with username "admin" ... cloaking won't help there, since that username is known by anyone who has any experience with YaBB, and can also just be trivially guessed.  Therefore, one of the login "keys" is already exposed for at least one admin user, and no amount of cloaking, even if implemented properly, will fix that.  The only solutions are to create a new admin user and delete the default one, or to change Setup.pl to ask the user for the initial admin username/password... if the default "admin" user is retained, then one of those login "keys" is forever exposed, cloaking or no.)

OH Eng wrote on Jul 11th, 2009 at 2:42am:
Well, gee, 3 days ago the US Secret Service network was hacked, so I'd say it would probably be child's play for hackers of that caliber to take on your ISP or host, let alone your forum, don't you think?

Nobody is talking about crackers of that caliber.  I can crack a cloaked username in under 10 seconds, because the cloaking routine makes no use of hidden information.  I was able to crack the captcha (which uses a much more cumbersome routine) with just my eyeballs in just about as much time.  I am by no means a world-class cracker.

I don't mean to dismiss your comments but one should not be so cavalier about the implementation of security.  If one is going to implement any security procedures, one should take pains to ensure that those procedures are at least as secure as required, and ideally as secure as possible given all other requirements (processing, space, user-friendliness, etc.).  To implement security procedures that can be trivially defeated not only doesn't add real security, it also creates a false sense of security that could be even more dangerous than not having any security at all.

If one is going to implement cloaking of usernames, it must be done in a way that cannot be trivially defeated.  It is my personal opinion that cloaking of usernames adds little to no security (a standard dictionary attack can figure out most usernames, which is why having a strong password is the ultimate, and really only, means of proper security), but that if one is going to implement it anyway (for whatever little security it adds), it must be done properly.

I guess I'll add it to my list of projects. Cheesy

I'm not trying to simply be argumentative; I am a firm believer in security and privacy protection (you should see how much encryption I use, and how much paper I shred!), but I also understand the huge problems associated with "security by obscurity," which much of this is.

OH Eng wrote on Jul 11th, 2009 at 2:42am:
Why do we NEED an online password retrieval system versus an email based one?Is there something wrong with the system in use now?

For the most part, no.  An online system is really only needed in the (relatively rare but very possible) event that a user who has forgotten his/her password does not have access to his/her registered email account (whether temporarily, e.g. away from the primary computer, or permanently, e.g. account canceled).  In that case, the user can't access the email with the reset link (either temporarily or permanently) and must email an admin to get a new password... which leaves to question how the admin can verify the user's identification to ensure that it's not a forged request.

Having an online system with security questions allows a user to reset his/her password even if he/she cannot access his/her registered email account, and without bothering an admin (who then has to trust the user's identity).
« Last Edit: Jul 11th, 2009 at 3:20am by cepheid »  
Back to top
WWW  
IP Logged
 
Page Index Toggle Pages: [1] 2 3 4
Topic Tools
 
  « Board Index ‹ Board  ^Top