serious security issue when user changed email address (security UserID) andthen used the old one!

[Malcolm]

This problem occurred a while ago, and I hoped it would go away - but it occurred again today and is causing major loss of confidence in my system!!

The problem:

I have set up the login so that the UserID is the email address field in a database table.
I allocate a password initially, that users can then change if they wish.

This user changed their email address in the database - in the correct field etc. (I didn't know this, so didn't change it in the security)

Then, for some reason, the user logged on using their old email address and correct password. The database let them in (fair enough), but instead of filtering their grid views on their primary keyID - a widely used session variable for filtering data in my system - no filter operated. Thus the user could see all the data. General panic has ensued and I'm the chief target!

I understand why the user was able to log in, (because their email address was the same as that recorded in the security table), but how can I ensure that if/when this happens again that at least some form of filter is in place? Do I lock them out of changing their emails? Can I somehow connect the security UserID to the field in the database table rather than the security? Can I construct the system to lock poepl out if the email they have recorded in the database doesn't match the UserID in the security table?

I've got this far by using A5's fantastic wizards and Steve Working's great videos (no blame Steve if you read this), so while I'm OK at SQL, I'm not flash at xbasic

Any help would be very much appreciated.

Malcolm

[Peter.Greulich]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

Needless to say there is something very wrong with your security setup. I assume that the table they changed their email address was not the websecurity_users table. You can't allow users to change their primary user_id, but it sounds like in your case something else is going on. It doesn't make sense that if the websecurity_users table email address did not change that they would be able to see all the data. Typically, when someone logs in you retrieve the group and set the session (filter) variable accordingly. Not sure what's going on in your case.

[bob9145]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

my reply here was not pertinent

[Michael1954]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

Hi Malcolm

In the Registereduser Table the UserName is often an email Address. This is the linking field back to security. You cannot let people edit this field. If you include an extra email field in this table that is not set by websecurity you need to consider all possibilities very carefully.

This is the field passed in when someone logs in with Alphas security so if you have the wrong values here your filtering can fail. I think Jerry recommends setting a default filter value that will return no records, this means if an error occurs no records are returned. In your system all records appear to be returned.

Michael

[Steve Wood]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

Linking a separate users table to security on an email address is poor design, unless you also make sure if email address is changed, it changes in security as well. But it is still poor design as far as I am concerned. Users MUST be able to change their email address, or even if you don't allow that in your system, it cannot be a primary key spread throughout the system such that it causes a problem if it is changed (orphaned records, etc).

[Malcolm]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

Thanks for your feedback - I've now done a bit more reading and I think Michael has hit on the cause of the problem. This is my setup:

In Web Security, I have specified the User ID configuration as 'valid email address.'
The security table has the email addresses I used to set users up with their logins (e.g. Login username is: [email protected])
The security checks the users login name ([email protected]) and the password, asseses it as valid and proceeds to the page where I've set up the variables (Steve's login_processing page)

I then define my session.UserID as follows:


'the UserID is the primary key from the RTLBDetails table
cn="::name::CMS"
table="RTLBDetails"
filter="RTLBemail='" + a5ws_getcurrentuser()+"'"
result="GroupID"
session.UserID=sql_lookup(cn, table, filter, result)

at this point the getcurrentuser() <> "RTLBemail" I guess that means the session.UserID is null (correct?)

When I use :UserID as a filter in my grid SQL statement (e.g. WHERE fieldname=:UserID), the filter is ineffectual as the value is null (correct?)

The solutions:

1. do not allow users to change their email addresses (in the data tables) - which means a whole lot of admin for me and delays for users (that's what I've done now)
2. Michael's suggestion above "I think Jerry recommends setting a default filter value that will return no records, this means if an error occurs no records are returned."
3. move to another userlogin system.

Michael, can you point me in the right direction as how to set up that 'default user filter that returns no data?' Perhaps it should be such that if the 'filter' condition isn't met in the getcurrentuser() function, then a 'decoy' userID is returned thus preventing any data from being displayed.

Thanks again for reading and responding.

Malcolm

[Steve Wood]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

If a person logs in and "something is wrong" (like you cannot find a matching User record or your GroupID, or something else critical) you should log them back out and not allow any access. That is different than 'setting a default filter that returns no records'. Your tactic is a mistake because OTHER things will go wrong if the person is allowed to login.

Also, if your filter is "WHERE fieldname=:UserID" and UserID is NULL, it will faithfully return all records where UserID is a NULL value. You can easily test this. You might have a different SQL query that somehow acts differently so I suggest, after you test this theory, that you might have to find some other reason that your user can see ALL records when they are not supposed to.

It is also easy to test for the value in your session.userid with functions like

?session.userid on an A5W page
or
save_to_file(session.userid,"c:\mytest.txt")

[Michael1954]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

Hi

Just to clear up a miss understanding there is no debate that a person who does not have permission should always be logged out. However I think you have built a system that uses 2 email address one in the security system that you should be filtering on, and one that the user can edit that you are filtering on. Respectfully this is not the way to do it.

I think there are 2 issues here.

If you want to follow Jerry's videos and use a valid email as the user name; keep that as the link returned by Alpha's security. This is your filter, set this to "noUser" as a default. Alpha security will never allow this value as it checks for a valid email address. Allow the user to enter and change a field; say contact email. Give them no access to UserName the link to the Alpha security. This way the user can change their email at will.

Should the user have a desire to change their UserName for log in then make them delete their current login and create a new one. All of this is explained by Jerry.

Should you be capable enough to stray from under the wings of Jerry then plenty of people on this message board have the skills to help you. Few are better than Steve. For me as a poor programmer I would rather stay with Jerry's paradigm and lose a little of the ease of use proposed by Steve.

Michael

[Progytech]

Re: serious security issue when user changed email address (security UserID) andthen used the old one!

Hi Malcom,
I have a system that uses the following logic to allow maintenance of the email being used as the User ID:
I have one table called Employees with an auto-incemented field (PK_Employees) and EmployeeEmail field using MS-SQL database.
All my filtering are based on this PK_Employees and not the email address field, so the EmployeeEmail can change at any time, but the PK_Employees will always be the same for this employee.

In the Employee grid AfterUpdateRecord() event, I have code that will check if the EmployeeEmail has changed and if so, it will update the security table using the framework a5ws...() functions as shown below:

function AfterUpdateRecord as v (e as p)
'-- If the email address was changed, then we need to check the following:
'1: That the old email exist in the Security Framework database and if so
'2: Update that UserID with the current email, so the Provider can login
if alltrim(e.OldDataSubmitted.EmployeeEmail) <> alltrim(e.DataSubmitted.EmployeeEmail) then
	if a5ws_WebUser_Exists(e.OldDataSubmitted.EmployeeEmail) then
		dim UserValue as p
		dim UserValue.Guid as c
		dim UserValue.UserID as c
	
		UserValue.Guid = A5WS_Get_GUID_From_User(e.OldDataSubmitted.EmployeeEmail)
		UserValue.UserID = e.DataSubmitted.EmployeeEmail
		UserValue.eMail = e.DataSubmitted.EmployeeEmail
		
		if len(alltrim(UserValue.Guid)) > 0 then
			dim output as p
			dim output.controls as p
			dim output.controls.guid.value as c

			'-- Update this record with the new email address in the Security Framework.		
			A5WS_Save_WebUser_Values(output, UserValue)
		end if
	else
		' This user does not exist in the Security Framework
		' so just ignore this email change.
	end if
end if

end function

In my case, I don't allow end users access to the security table, only to the Employee data when the email can be changed and it will be updated in the security table silently.

Be aware that I am using MS-SQL tables for the Alpha Security Framework.

Hope this help you out.