LDS Account, MRN security, and mobile tools

Church Account is the primary user account (user name and password) for accessing online Church resources. Church Account was formerly known as LDS Account. This forum is a space to discuss all things related to Church Accounts (registration, account recovery, user experience, vulnerabilities, etc.).
eblood66
Senior Member
Posts: 3907
Joined: Mon Sep 24, 2007 9:17 am
Location: Cumming, GA, USA

#11

Post by eblood66 »

mkmurray wrote:What is wrong with relying on LDSAccount credentials? It has sufficient membership info and calling info associated with it on the Church's servers so as to make the right decisions about who to authenticate and what type of data to authorize the requester to have. What am I missing? Please explain further.

I think the concern is that with a 3rd party app, especially a closed source app, you can't be sure of what it may be doing with the information. It might be (innocently but inappropriately) temporarily storing it on a 3rd party server or it might be (maliciously) capturing sensitive data and forwarding it somewhere. All that would be required is getting a leader to use it and enter their LDS Account credentials.

Of course, it is very difficult to securely restrict a web service to specific consumers. Even with a public/private key handshake, the key would have to be stored in the application which means someone could reverse-engineer it and write a new app that poses as an official app.
User avatar
mkmurray
Senior Member
Posts: 3266
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

#12

Post by mkmurray »

eblood66 wrote:I think the concern is that with a 3rd party app, especially a closed source app, you can't be sure of what it may be doing with the information. It might be (innocently but inappropriately) temporarily storing it on a 3rd party server or it might be (maliciously) capturing sensitive data and forwarding it somewhere. All that would be required is getting a leader to use it and enter their LDS Account credentials.
Good point.
eblood66 wrote:Of course, it is very difficult to securely restrict a web service to specific consumers. Even with a public/private key handshake, the key would have to be stored in the application which means someone could reverse-engineer it and write a new app that poses as an official app.
Yes, that was my thought as well that it wouldn't be all that effective.
scgallafent
Church Employee
Church Employee
Posts: 3025
Joined: Mon Feb 09, 2009 4:55 pm
Location: Riverton, Utah

#13

Post by scgallafent »

eblood66 wrote:Of course, it is very difficult to securely restrict a web service to specific consumers. Even with a public/private key handshake, the key would have to be stored in the application which means someone could reverse-engineer it and write a new app that poses as an official app.

That was my initial thought when this discussion started. As long as the data is exposed and the communication can be analyzed, there is always the potential for someone to reverse-engineer an official app and then impersonate that app. The first example that comes to mind is HYMN, which impersonated iTunes to make purchase from the iTunes Store and skipped the last step of encrypting the music file.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#14

Post by RossEvans »

mkmurray wrote:I'm not sure I understand your expectations for how these web services are to be secured. How do you propose securing the web services beyond the LDSAccount credentials so that only community projects would have access? I suppose some kind of public shared key and private key thing could be used like is used in many encryption algorithms, but I don't understand the necessity.

What is wrong with relying on LDSAccount credentials? It has sufficient membership info and calling info associated with it on the Church's servers so as to make the right decisions about who to authenticate and what type of data to authorize the requester to have. What am I missing? Please explain further.
My assumption governed by two things:

First, I and others understood that a big part of the rationale for migrating apps to web services from MLS exports was to bring the applications such as Ward Tools inside the Community tent for enhanced security and centralized official control. I know that hearing that case was part of what persuaded Ward Tools developers to hand over their product to the Church and work inside the tent instead.

Second, there obviously has been a higher level of safeguard imposed on the MRN recently. It has been dropped from the MLS exports, even though those exports already require the highest level of permission inside MLS under local priesthood control. Also, the MRN has recently been dropped from the LDS Account-authenticated download of the geoceoded membership records available to ward leaders. From this and what comments have been made by Church employees on this forum I gather that for policy or legal reasons it is no longer considered reliable to trust local priesthood leaders to download this particular data element, only to view it. While I think that is lamentable, I am seeking to honor that principle while ensuring that these leaders at least regain view-access to the MRN (and any other data element considered this sensitive in the future) in the expanded version of LDS Tools. If the API is not locked down, then the data is effectively just as exportable as it used to be from MLS or maps.lds.org, so the same general privacy concern might force such data to be dropped altogether. I would much rather see the API restricted than to have local leaders denied access to view the data in the future LDS Tools. As local priesthood leaders have lost access to the MRN in Ward Tools (and I presume other third-party products) this crippling has already hurt the users. These priesthood leaders need a secure way to capture the data on their handheld app.

As for the question of how this might be done, I am aware that it would not be easy to lock down the API in an absolutely bulletproof way so that approved clients could never be spoofed, sniffed or reverse-engineered. But some kind of handshake, perhaps involving public-key tokens to help enforce some legal license and policy, would be much better than nothing. As my grandfather used to say, a good lock will keep an honest man out. The goal can be to prevent priesthood leaders from inadvertently running some tool to export the sensitive data, or be taken advantage of by third-party developers who do not honor policy unless they are compelled to do so.
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#15

Post by russellhltn »

RossEvans wrote:From this and what comments have been made by Church employees on this forum I gather that for policy or legal reasons it is no longer considered reliable to trust local priesthood leaders to download this particular data element, only to view it.
I have no idea if this is the issue, but in my state, the legal requirement to report a "data breach" is conditioned on the data includes information to access one's financial account. Name, address and birthdate by itself is not enough.

If the church was to make donation information available to members, then the MRN becomes that critical element. The church could be required to report a "data breach" everytime a Priesthood holder misplaced their phone.
RossEvans wrote:These priesthood leaders need a secure way to capture the data on their handheld app.
If I understand correctly, this is needed only because it's on a temple recommend. I don't know what the longer term plans are for that. That might change.

But it seems to me that procedures can be worked out to allow temple recommends to continue to be issued without having them on portable devices. A good part of that might be to train the members that "a lack of planning on their part is not an emergency on our part", or if you prefer a more gospel-oriented analogy, the parable of the Ten Virgins. You know, something radical, like appointments scheduled ahead of time? ;)
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#16

Post by RossEvans »

RussellHltn wrote:I have no idea if this is the issue, but in my state, the legal requirement to report a "data breach" is conditioned on the data includes information to access one's financial account. Name, address and birthdate by itself is not enough.

If the church was to make donation information available to members, then the MRN becomes that critical element. The church could be required to report a "data breach" everytime a Priesthood holder misplaced their phone.
I've never even seen speculation that the MRN might be required to access one's financial data someday. Rather, the rationale for tighter controls on the MRN seems likely to be based on the fact that it is one key element needed to set up or hijack an LDS Account right now.
RussellHltn wrote:If I understand correctly, this is needed only because it's on a temple recommend. I don't know what the longer term plans are for that. That might change.

But it seems to me that procedures can be worked out to allow temple recommends to continue to be issued without having them on portable devices. A good part of that might be to train the members that "a lack of planning on their part is not an emergency on our part", or if you prefer a more gospel-oriented analogy, the parable of the Ten Virgins. You know, something radical, like appointments scheduled ahead of time? ;)

Or leaders could just return to three-ring-binder technology, which of course has foolproof security. :eek:

I really don't think imposing more procedural red tape on leaders and members is the answer. (In my stake, holding recommend interviews first-come-first-served on regular weeknights is done for the convenience of both, and in my ward I see ad hoc interviews handled in a mutually satisfactory way all the time.) I think the better thing for technical enablers to worry about is how to put convenient and secure tools into the priesthood leaders' hands. That's what an app like Ward Tools (or the upcoming LDS Tools) is really for.
russellhltn
Community Administrator
Posts: 34417
Joined: Sat Jan 20, 2007 2:53 pm
Location: U.S.

#17

Post by russellhltn »

RossEvans wrote:I've never even seen speculation that the MRN might be required to access one's financial data someday. Rather, the rationale for tighter controls on the MRN seems likely to be based on the fact that it is one key element needed to set up or hijack an LDS Account right now.
And I seem to remember some hints that there might be some financial tie-in in the future. If that's on the drawing board, it would explain what's happening the MRNs now.
RossEvans wrote: Or leaders could just return to three-ring-binder technology, which of course has foolproof security. :eek:

Foolproof? I don't think it exists. But I would suggest that a list tucked into the recommend book is likely more secure then having it run around on the Bishopric's smart phones.

As for updating the list, I seem to remember some "minimum time" requirements that have to be met. Otherwise a call to the prior Bishop is in order. So I'd think updating the list each quarter or so would do fine.
Have you searched the Help Center? Try doing a Google search and adding "site:churchofjesuschrist.org/help" to the search criteria.

So we can better help you, please edit your Profile to include your general location.
jasonhyer
Member
Posts: 241
Joined: Fri Oct 19, 2007 11:15 am
Location: Roy, UT

#18

Post by jasonhyer »

RossEvans wrote:I really don't think imposing more procedural red tape on leaders and members is the answer. (In my stake, holding recommend interviews first-come-first-served on regular weeknights is done for the convenience of both, and in my ward I see ad hoc interviews handled in a mutually satisfactory way all the time.) I think the better thing for technical enablers to worry about is how to put convenient and secure tools into the priesthood leaders' hands. That's what an app like Ward Tools (or the upcoming LDS Tools) is really for.
As the Project Manager for LDS Tools for Android, our first priority is to put a stable app in the hands of the users. The security in the app is linked to the security surrounding your LDS Account. The team involved with building the app is primarily made up of volunteers with a couple of FTE's from the church acting as "advisors" to the project. They give us direction on where the Church as told them they would like the app to go and we present new features to them for approval. Our intent is to give a tool to members to help them stay more connected to membership and calendar data and to stay more informed.

While it would be nice to give priesthood leaders every bit of information that they could possibly use, that is not the intent of the app. We plan on adding features that will make it easier for them to do their jobs and be able to contact people but it isn't going to do everything for them, at least not in the near future. As Android technology continues to mature and the Church becomes more confident with its capabilities, we may at some time in the future see leaders having information such as MRN's but we are more concerned with letting leaders know who they have a stewardship over, being able to contact those people, and knowing what is going on in their units.

I'm reminded of a quote that can have many meanings, in this case concerning the availablity of some information. "Just because you can, doesn't mean you should." LDS Tools will continue to add features as they will benefit users and meet the needs of all members as we can do it safely. It is up to the church to decide what personal information can be made available to whom and in what format. I see no reason to push against something that is policy unless there is a good reason to do so and there is evidence that a change can be done safely without potentially exposing information that shouldn't be. Even then, I can make a suggestion, but if the decision is contrary to my suggestion, then that is final. I will uphold the decisions of priesthood leaders (who are ulitimately in charge of this effort) and not "kick against the pricks."
Jason Hyer
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#19

Post by RossEvans »

jasonhyer wrote:It is up to the church to decide what personal information can be made available to whom and in what format. I see no reason to push against something that is policy unless there is a good reason to do so and there is evidence that a change can be done safely without potentially exposing information that shouldn't be. Even then, I can make a suggestion, but if the decision is contrary to my suggestion, then that is final. I will uphold the decisions of priesthood leaders (who are ulitimately in charge of this effort) and not "kick against the pricks."

I certainly don't think that is what I am doing. My first question is still trying to determine what the policy actually is. Perhaps I misunderstood what I heard at the development conference last spring and in related conversations, but my clear understanding was that the plan for the membership web services was to restrict them to Community apps because that way the Church can maintain end-to-end control of how the services are used, and that would become more important as the services grow to include more confidential leadership data. Did I totally misunderstand the policy, or has it changed?
jasonhyer
Member
Posts: 241
Joined: Fri Oct 19, 2007 11:15 am
Location: Roy, UT

#20

Post by jasonhyer »

I would like to clarify my comments above. I am not trying to stifle any discussion about what could be included in LDS Tools. My intent was only to try and temper expectations on what will and can be included in the app in the future. While there are many great ideas that have been suggested, some suggestions are for items that do not seem feasible, at least in the near term. Discussions on such items as including the MRN as part of the data leaders will be able to access can only be conjecture at this point as we have seen that the Church has further restricted access to this information even in MLS. As the apps are mostly being developed by a volunteer community, what is included in the app will be directed by those who are employed by the Church and are being given direction by Priesthood leaders. My "kicking against the pricks" comment was only intended to mean that as much as we would like to have some features in mobile apps, that decision is ultimately a Priesthood decision and as a development community, we will follow the direction passed down to us from those leaders.

I am very enthusiastic about where these apps can take us but my enthusiasim has to be tempered by the capacity of the development community in both time and ability. As we have seen with the development of the new lds.org, these things take time. The mobile apps will take time to get to where we want them and while I don't want to discourage discussion, I would like to encourage patience.

With that said, if there are any of you that would like to contribute to the development of these apps, there is always a need for those that have the time and ability to build out these apps. While I can only speak for Gospel Library and LDS Tools for Android, I believe that any development group working on these mobile apps can use more help.

This work is divinely inspired and I can not thank enough those people who have gone out on their own to make this information available to members of the church who are yearning for it. They have laid a path for the official development of similar apps to follow and they have provided great vision. This work will move forward as fast as we can given the resources available. Thank you to all who are interested in this work and are willing to contribute where you can.
Jason Hyer
Post Reply

Return to “Church Account”