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.).
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

LDS Account, MRN security, and mobile tools

#1

Post by RossEvans »

jasonhyer wrote:One issue we are finding as people are starting to use LDS Tools is that some people cannot sync despite repeated attempts to do so. One possibility is that there is a problem with the LDS Account. You can do the following to determine if it is an LDS Account issue.

On a regular computer, go to a web browser and do the following:

1. Go to https://new.lds.org/directory/services/ludrs/mem/current-user-unitNo
2. Log-in using your LDS Account when prompted
3. Open file downloaded or read the text in your browser and copy the six digit number at the end of the text (your unit number)
4. Take the unit number and put it in the following command (replacing <unit number> with their unit number):
https://beta.lds.org/directory/services/ludrs/mem/member-list/<unit number>

Is that json output going to remain available to end-users with LDS Account credentials, or will it be restricted to Community developers?
User avatar
mkmurray
Senior Member
Posts: 3266
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

#2

Post by mkmurray »

boomerbubba wrote:Is that json output going to remain available to end-users with LDS Account credentials, or will it be restricted to Community developers?
I'm guessing it's the service used by the various mobile apps created by the community volunteer developers. However, I imagine the mobile apps all use the LDSAccount credentials of each user to hit the service. If that's the case, then it seems like that service would remain open to anyone with LDSAccount credentials. Just guessing though.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#3

Post by RossEvans »

mkmurray wrote:I'm guessing it's the service used by the various mobile apps created by the community volunteer developers. However, I imagine the mobile apps all use the LDSAccount credentials of each user to hit the service. If that's the case, then it seems like that service would remain open to anyone with LDSAccount credentials. Just guessing though.

I understand that LDS Account credentials will be used to log in at runtime. But my impression was that the membership services were also going to be restricted to officially approved apps created by the Community. If that impression was wrong, then it would be technically possible to use the services to populate third-party apps, too.
User avatar
aebrown
Community Administrator
Posts: 15153
Joined: Tue Nov 27, 2007 8:48 pm
Location: Draper, Utah

#4

Post by aebrown »

boomerbubba wrote:
mkmurray wrote:I'm guessing it's the service used by the various mobile apps created by the community volunteer developers. However, I imagine the mobile apps all use the LDSAccount credentials of each user to hit the service. If that's the case, then it seems like that service would remain open to anyone with LDSAccount credentials. Just guessing though.

I understand that LDS Account credentials will be used to log in at runtime. But my impression was that the membership services were also going to be restricted to officially approved apps created by the Community. If that impression was wrong, then it would be technically possible to use the services to populate third-party apps, too.
Since I can follow the steps Jason gave in a browser, then there is nothing that would stop a third-party app (at least technically -- I don't know the legal issues) from doing the same. If I give that third-party app my LDS Account credentials, that app can access the webservice to get my directory information.
Questions that can benefit the larger community should be asked in a public forum, not a private message.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#5

Post by RossEvans »

Alan_Brown wrote:Since I can follow the steps Jason gave in a browser, then there is nothing that would stop a third-party app (at least technically -- I don't know the legal issues) from doing the same. If I give that third-party app my LDS Account credentials, that app can access the webservice to get my directory information.

That distinction may not be significant today, because the same directory content is also available for download as a CSV from the web site for an authenticated user. But it will become more significant in the near future as the membership services are expanded to support an expanded LDS Tools app aimed at leaders, who also are privy to more confidential information.

Personally, I don't find this controlled openness to be a bad thing because I favor making exports available to local priesthood leaders. I think their trustworthiness outweighs the risks, just as it has traditionally with MLS export files. But that is just my opinion, and there seems to be a nascent trend to cripple those exports -- for example, deleting the MRN. I also understood that part of the rationale was that the suppressed data would be provided instead through an API to locked-down apps built under Church supervision. If the API is not locked down, that rationale disappears.
jonesrk
Church Employee
Church Employee
Posts: 2361
Joined: Tue Jun 30, 2009 8:12 am
Location: South Jordan, UT, USA

#6

Post by jonesrk »

boomerbubba wrote: But that is just my opinion, and there seems to be a nascent trend to cripple those exports -- for example, deleting the MRN.
My understanding is that this is a move to protect the MRN (which is the key to member data access) and using the individual id as the way to connect people.

I think it is more of a identity theft protection instead of an attempt to cripple other tools.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#7

Post by RossEvans »

ryan jones wrote:My understanding is that this is a move to protect the MRN (which is the key to member data access) and using the individual id as the way to connect people.

I think it is more of a identity theft protection instead of an attempt to cripple other tools.
I understand the rationale. The effect is still to cripple some of the use of the MRN data for priesthood leaders. They use the MRN as a significant piece of content for such purposes as temple recommend interviews. It is more than just an ID for software records.

My point is that the same privacy vulnerability that accompanies providing the MRN in exports would also obtain in an API that is not locked down. Of course, there are other confidential data elements, too, that leaders will need in an expanded LDS Tools app.
jasonhyer
Member
Posts: 241
Joined: Fri Oct 19, 2007 11:15 am
Location: Roy, UT

#8

Post by jasonhyer »

RossEvans wrote:That distinction may not be significant today, because the same directory content is also available for download as a CSV from the web site for an authenticated user. But it will become more significant in the near future as the membership services are expanded to support an expanded LDS Tools app aimed at leaders, who also are privy to more confidential information.

Personally, I don't find this controlled openness to be a bad thing because I favor making exports available to local priesthood leaders. I think their trustworthiness outweighs the risks, just as it has traditionally with MLS export files. But that is just my opinion, and there seems to be a nascent trend to cripple those exports -- for example, deleting the MRN. I also understood that part of the rationale was that the suppressed data would be provided instead through an API to locked-down apps built under Church supervision. If the API is not locked down, that rationale disappears.

The key to all of this is your LDS Account login. If you use the procedure I listed above, if you are in a leadership position, you will see more information than somebody who is not. At this time, any app could technically get the data as long as a person logged in. I believe that there is already at least one paid app that does use the data. Note that the church does not charge for the apps it develops and makes available.
RossEvans
Senior Member
Posts: 1345
Joined: Wed Jun 11, 2008 9:52 pm
Location: Austin TX
Contact:

#9

Post by RossEvans »

jasonhyer wrote:The key to all of this is your LDS Account login. If you use the procedure I listed above, if you are in a leadership position, you will see more information than somebody who is not. At this time, any app could technically get the data as long as a person logged in. I believe that there is already at least one paid app that does use the data. Note that the church does not charge for the apps it develops and makes available.

Sure, I understand all that. But my impression was that the web services were going to be restricted to Community projects. Do you know if that has changed by design, or is the security of the API just not finished?

As I said above, this is less significant today because the content being disseminated is less sensitive than what priesthood leaders will need in an expanded LDS Tools app, much like Ward Tools offers from the MLS exports that are only available to local priesthood leaders. But meanwhile, the content of those exports, notably the MRN field, is being cut back because of concerns over privacy. It is obviously not that bishops, stake presidents, their counselors and clerks are no longer privileged to see the MRN. Rather, they will no longer be privileged to possess it in a portable, machine-readable form designed for export. That same vulnerability also would obtain in an online API that is not locked down by applications controlled by the Church. It is pretty trivial for program or script to parse online content from json or XML, almost as easy as it is to parse CSV files.

My aim is to maximize the utility of an expanded LDS Tools app for leaders, since that is now the official roadmap to supplant third-party products such as Ward Tools in the future. I suggest that will require a more restricted API than has been exposed to date for the rank-and-file apps.
User avatar
mkmurray
Senior Member
Posts: 3266
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah
Contact:

#10

Post by mkmurray »

RossEvans wrote:Sure, I understand all that. But my impression was that the web services were going to be restricted to Community projects. Do you know if that has changed by design, or is the security of the API just not finished?

As I said above, this is less significant today because the content being disseminated is less sensitive than what priesthood leaders will need in an expanded LDS Tools app, much like Ward Tools offers from the MLS exports that are only available to local priesthood leaders. But meanwhile, the content of those exports, notably the MRN field, is being cut back because of concerns over privacy. It is obviously not that bishops, stake presidents, their counselors and clerks are no longer privileged to see the MRN. Rather, they will no longer be privileged to possess it in a portable, machine-readable form designed for export. That same vulnerability also would obtain in an online API that is not locked down by applications controlled by the Church. It is pretty trivial for program or script to parse online content from json or XML, almost as easy as it is to parse CSV files.

My aim is to maximize the utility of an expanded LDS Tools app for leaders, since that is now the official roadmap to supplant third-party products such as Ward Tools in the future. I suggest that will require a more restricted API than has been exposed to date for the rank-and-file apps.
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.
Post Reply

Return to “Church Account”