Resurrection: eduPersonTargettedId (Shibboleth v2)

[Losen, Stephen C (scl)]

Hi Joshua,

SHA1 is a one way hash, so the only way to go from targetedID to uid is to feed likely candidate uids to the algorithm and see if any result matches the targetedID.  It would not take terribly long to feed say 100,000 uids to the algorithm on today’s fast CPUs.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu<mailto:scl at virginia.edu>    434-924-0640

From: users [mailto:users-bounces at shibboleth.net] On Behalf Of Joshua Brodie
Sent: Friday, January 25, 2019 4:29 PM
To: Shib Users <users at shibboleth.net>
Subject: Re: Resurrection: eduPersonTargettedId (Shibboleth v2)

Thanks!

I was very optimistic earlier - that we had the logs from who has accessed the service (beyond the retention policies).

If provided with the eduPersonTargetedId value by the SP (and I know the hash) -- is it possible to reverse to the original seed value?

We are not going to migrate this legacy SP, that was on the deprecated v2 IDP,  to the v3 IDP. It's a security follow-up that I can't go to in detail.

On Thu, 24 Jan 2019 at 02:46, Losen, Stephen C (scl) <scl at virginia.edu<mailto:scl at virginia.edu>> wrote:
Hi Joshua,

I am pretty sure this is the algorithm that generates computed ID:

base64_encode(SHA1_digest(sp_entityID + “!” + uid + “!” + salt))

Or if you are running a v3 IDP you can define a computedID attribute (be sure to use base64 instead of base32) with the correct salt and then define a SP with the correct entityID to release it to, and use bin/aacli.sh to display the assertion, which will include the computedID.

Stephen C. Losen
ITS - Systems and Storage
University of Virginia
scl at virginia.edu<mailto:scl at virginia.edu>    434-924-0640

From: users [mailto:users-bounces at shibboleth.net<mailto:users-bounces at shibboleth.net>] On Behalf Of Joshua Brodie
Sent: Wednesday, January 23, 2019 10:12 PM
To: users <users at shibboleth.net<mailto:users at shibboleth.net>>
Subject: Resurrection: eduPersonTargettedId (Shibboleth v2)

Blast from the past. We have a long forgotten SP that wishes to find out users on our deprecated v2 Shibboleth.

They used the legacy eduPersonTargetedID in Shib2 -- and have stored the values for users.

We know who have access the SP by their uid from the logs.

What I am not sure is how to generate the targetedtId from the uid (outside of the long gone v2 instance)? Desired outcome: we sent the list of uid/eduPersonTargetedId mapping to the SP -- that they can find out who used their site (for a security follow-up).

The following is how we had configured the generation of the sent value (I have the salt).


<resolver:DataConnector id="mystoredhashedid" xsi:type="ComputedId" xmlns="urn:mace:shibboleth:2.0:resolver:dc"

                    generatedAttributeID="targetedID"

                    sourceAttributeID="uid"

                    salt="foobar">



                    <resolver:Dependency ref="dbmain" />



          </resolver:DataConnector>
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net<mailto:users-unsubscribe at shibboleth.net>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20190125/7f9ffdcb/attachment.html>