LDSTech

LDS Account, MRN security, and mobile tools

LDS Account is the primary user account (user name and password) for accessing online Church resources. This forum is a space to discuss all things related to LDS Account (registration, account recovery, user experience, vulnerabilities, etc.).

LDS Account, MRN security, and mobile tools

#1Postby RossEvans » Wed Dec 15, 2010 12:38 pm

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.

[color=black]On a regular computer, go to a web browser and do the following:[/color]

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?
RossEvans
Senior Member
 
Posts: 1325
Joined: Wed Jun 11, 2008 8:52 pm
Location: Austin TX

#2Postby mkmurray » Wed Dec 15, 2010 10:57 pm

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.
Many questions are already answered on the LDSTech wiki. Check it out!
User avatar
mkmurray
Senior Member
 
Posts: 3213
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah

#3Postby RossEvans » Thu Dec 16, 2010 7:36 am

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

#4Postby aebrown » Thu Dec 16, 2010 8:59 am

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.
Many questions are already answered on the LDSTech wiki. Check it out!
User avatar
aebrown
Community Administrator
 
Posts: 12723
Joined: Tue Nov 27, 2007 8:48 pm
Location: Sandy, Utah

#5Postby RossEvans » Thu Dec 16, 2010 3:25 pm

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

#6Postby jonesrk » Thu Dec 16, 2010 4:02 pm

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.
Ryan Jones
CDOL Developer
Stake Technology Specialist - Software / Stake Assistant Clerk
Former Ward Clerk
jonesrk
Senior Member
 
Posts: 1147
Joined: Tue Jun 30, 2009 7:12 am
Location: Farmington, UT, USA

#7Postby RossEvans » Thu Dec 16, 2010 11:00 pm

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

#8Postby jasonhyer » Tue Dec 21, 2010 6:28 pm

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.
jasonhyer
Member
 
Posts: 213
Joined: Fri Oct 19, 2007 10:15 am
Location: Roy, UT

#9Postby RossEvans » Tue Dec 21, 2010 7:53 pm

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

#10Postby mkmurray » Tue Dec 21, 2010 11:28 pm

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.
Many questions are already answered on the LDSTech wiki. Check it out!
User avatar
mkmurray
Senior Member
 
Posts: 3213
Joined: Tue Jan 23, 2007 9:56 pm
Location: Utah

Next

Return to LDS Account

Who is online

Users browsing this forum: No registered users and 0 guests