HT/VT Reporting Website Overview

Discussions around miscellaneous technologies and projects for the general membership.
User avatar
WelchTC
Senior Member
Posts: 2085
Joined: Wed Sep 06, 2006 8:51 am
Location: Kaysville, UT, USA
Contact:

I hate to be the bearer of bad news but...

#191

Post by WelchTC »

The Earl wrote:This is looking really good. I hope soon we can get it rolled out for testing in some units.
I want to remind everyone that the Church has a policy about exporting information from MLS or LUWS and importing that same data into a server not officially sponsored and supported by the Church. You can use the data on your own "controlled" and "secure" PC's, laptops, and PDA's. However you are not allowed to host sites for your ward that would utilize this exported information.

This project is a "prototype" of what should or could be done. It is an excellent project and we have people at the Church watching this. We are looking at ways to either use this code or use the concepts of this code to make something more official. However this process takes time as we have to code secure ways for us to allow access to key data. We are looking at alternatives to speed up the process but nothing is definitive yet.

Don't shoot the messenger. ;)

Tom
scion-p40
Member
Posts: 259
Joined: Sun Apr 22, 2007 12:56 am

#192

Post by scion-p40 »

brado426 wrote:Below is a summary I sent to the testers of other changes that were made over the past week.
______________________________________________________________________

-----snip------
2. The “Edit Results by Household/Sister” function has been completely redesigned utilizing the new menu. This makes manually changing HT/VT results much easier. When clicking on the "Edit" link, the Contact Type menu will pop up so you can quickly select the new status for the desired household/sister.
----snip----


What is meant by the term "household/sister"? VT are individually assigned. A single household may have multiple VT assigned.
User avatar
brado426
Member
Posts: 313
Joined: Sun Feb 11, 2007 9:50 pm
Location: Foothill Ranch, CA
Contact:

#193

Post by brado426 »

scion wrote: What is meant by the term "household/sister"? VT are individually assigned. A single household may have multiple VT assigned.

Household is for Home Teaching while Sister is for Visiting Teaching.

For Home Teaching, the menu option is called "Edit Results by Household" which lists all the Households and allows the Presidency to manually edit each household's status.

For Visiting Teaching, the menu option is called "Edit Results by Sister" which lists all the Sisters and allows the Presidency to manually edit each sister's status.

The terminology is taken directly from the MLS system.

Brad O.
scion-p40
Member
Posts: 259
Joined: Sun Apr 22, 2007 12:56 am

#194

Post by scion-p40 »

Thanks. That makes sense.
User avatar
brado426
Member
Posts: 313
Joined: Sun Feb 11, 2007 9:50 pm
Location: Foothill Ranch, CA
Contact:

Security

#195

Post by brado426 »

I want to run something by you guys.... and that is the subject of security with this site. I believe the security model is pretty good as is, but I would like to get your opinions.

First, let me say that I strongly believe that we should not require the teacher to enter a username/password combination when reporting. I believe that if we require this, it will cause way too much complication and significantly decrease the percentage of results reported by the teachers.

That being said, let me explain how the security currently works.

The url that the users link to contains a User ID, a User Code, and verification Key.

https://www.htreporting.com/htrepbeta/ReportStats.aspx?key=54a32334&id=8&userid=46&code=31321&repmonth=7&repyear=2007

The ID is an integer that tells the system which group the user belongs to.

The User ID is an integer that tells the system which user is logging in.

The code is a 3 - 5 digit hex number that is automatically generated by the system when the users e-mail address is set up. This password does not (and cannot) change unless the teacher's e-mail address is remove and re-added. If this password changes, all previous links sent to the teacher will no longer work.

The key is an 8 digit hex number that ensures that the url has not been altered. If the url is altered, the system will display a message stating as such and not allow the teacher to report.

In addition to these three pieces of information contained in the url, the teacher is required to enter the first part of his or her e-mail address before accessing the reporting screen. This ensures that if the link gets into the wrong hands, that person must also have the necessary e-mail address.

All information transferred to and fron the site is encrypted using SSL, so the data cannot be intercepted between the client and the server.

Additionally, the links expire after 2 months so even if they did get into the wrong hands, they wouldn't be of much value.

Each teacher can be assigned an access level of Teacher, Supervisor, or Presidency Member. Only Presidency Members have the ability to change the access levels. Those who have Presidency Member access will notice an "Admin Menu" button in the upper right-hand corner when they access their reporting screen for which they can easily access the 'Admin Menu.' Supervisors also see the 'Admin Menu' button, but they will not have access to all the menu-items available on the 'Admin Menu.'

I believe that things are pretty darn secure as is, but I think it could be improved.

The specific questions I have for you are:

1. Do you think the Presidency Members should have a username/password? If their link got into the wrong hands and that person knew the first part of their e-mail address, they could run a-muck if they wanted to.

2. What do you think of the "no username/password" for teachers model? In my opinion, it is absolutely critical, but I'm guessing some of you may disagree with me.

3. If a teacher does not want their name in the system at all, how should it be handled? The teacher would still need to be in the church's records... just not online for HT/VT Reporting purposes. I'm envisioning an option for the Presidency to add a particular teacher to a list of "removed" teachers and the system would make that person pretty much invisible.

Brad O.
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#196

Post by thedqs »

For getting rid of the username password you could use a SAW type implementation. (SAW was developed by BYU and it is patented.) You can read more at http://isrl.cs.byu.edu/publications.php and select the paper about Simple Authentication for the Web. Since the church would be looking into implementing this site, this might be a possible way for the church to implement this security (I am assuming that the church can use BYU's patents).
- David
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#197

Post by thedqs »

By the way is the key the key used for the hash function to create the verification code? If so then once someone figures out the hash function then they could create their own url and be anyone.
- David
User avatar
brado426
Member
Posts: 313
Joined: Sun Feb 11, 2007 9:50 pm
Location: Foothill Ranch, CA
Contact:

#198

Post by brado426 »

thedqs wrote:By the way is the key the key used for the hash function to create the verification code? If so then once someone figures out the hash function then they could create their own url and be anyone.

Oops, the descriptions weren't matching the elements in the url. I have edited my previous post to make it clearer.

Each teacher has his or her own unique code so there is no way that anyone could modify the links to impersonate anyone else.

The key ensures that the url has not been modified. If the algorithm behind the key was somehow compromised, the worse that could happen is someone could change the link to allow them to report for a different month and year than the link was designed for. Even that wouldn't really be an issue because the system does not allow anyone to report for future months or more than 2 months in the past.

Another layer of security that could be added would be to munge the url's so that the url values wouldn't be readable at all.

I wasn't aware of that technology that BYU came up with. I'll take a look at it. Thanks.

Brad O.
User avatar
thedqs
Community Moderators
Posts: 1042
Joined: Wed Jan 24, 2007 8:53 am
Location: Redmond, WA
Contact:

#199

Post by thedqs »

What I meant about the unique code is someone could sniff the header and get a user's code. Then they could hash it and impersonate the person who's code that was. I was going from the outsider trying to get in. Of course if you generate a new pseudo user id for each month then I couldn't take last month's userid and try to report this months.

Basically the more constants you remove the better, of course that means more computing and sophistication to allow authorized users to connect.

As for the BYU tech, I hear about it every MWF since my professor is Tim and he helped create it.
- David
russellhltn
Community Administrator
Posts: 31971
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#200

Post by russellhltn »

brado426 wrote:1. Do you think the Presidency Members should have a username/password? If their link got into the wrong hands and that person knew the first part of their e-mail address, they could run a-muck if they wanted to.
I think that would be a good idea. Keep in mind that some families share the computer, so stuff sent via a link are not secure from other family members or house residents (think student dorms).

Now, does your system not allow traditional password/logins or is this just a way not to require them? Because as it seems now, the teacher must wait for their email for the link to get in. That may not sit well with some users who would rather be able to go to a easy to memorize URL (saved to their favorites) and log in.

And speaking of favorites ....... A URL that changes routinely is likely to create problems on that front as well. My suggestion there is if a invalid URL is found, that they are routed to the login screen. That way a saved favorite will always take them to the login screen.
Post Reply

Return to “Other Member Technologies”