[Owasp-ireland] Question about identity over two systems

Peter McEvoy peter.m.mcevoy at gmail.com
Thu May 14 08:05:01 EDT 2009


Thanks all,
I've had a few out-of-band replies and pretty much everyone is suggesting
identity federation schemes.

We want to provide added value to the customers of another company, and
their management/marketing team think we have a great idea.  But the problem
for us is that we wanted to provide the entire solution with minimum
disruption to the tech team/data centre of the other company.

We wanted to be masters of our own destiny and deliver the solution at our
pace without depending on the other team to deliver infrastructure.

It's very early days on this deal, and it could be that they already have
federation integration points in place for partners, but we have not had the
luxury of being able to actually speak to their tech team yet... We'll just
have to wait.

In retrospect, the hashing scheme I proposed in my inital mail is too weak:
it takes 3 mins to generate 10^8 hashes and we would need incredibly large
PINs to make it even remotely difficult to crack them.

Thanks for all your replies

Pete

PS Always add salt to your hashes!

2009/5/13 John Curran <john.curran at ucd.ie>

>  Hi,
>
> This is a problem we face in Higher ed for individualised anonymity in
> access to online resources, e.g. users looking for access to journal
> articles hosted externally- the user would like to have some form of local
> identity on the remote service, but we cannot provide any individual data to
> the remote system. In addition an (unstated below) requirement would
> appear to be that system A1 must be an authorised source of transactions for
> system A2. IT’s also a typical issue in Single sign-on and federated
> identity schemes.
>
>
>
> This requirement can be summarised as for a “sponsored identifier”, and
> this can be accomplished in very many ways.
>
>
>
> Proposed method. Compute and retain a random identifier i1 for all users
> i1, random salt concatenated with a hash of the userid for a given system
> will generate a unique ID.  For a given transaction this is encrypted by a1
> and passed to a2 with a nonce in the transaction (usually a timestamp)
>
> A2 decrypts the transaction (hey it’s the right key for a1, it must have
> come from there!, and the timestamp is within an acceptable window for it
> not to have been a replay attack) ( This could be a mutually authenticated
> SSL session) . i1 is stored locally and is unique for the user and the data
> held. It may be retrieved from a2 by whatever means by an authorised user of
> that application. Users access application a2 by handover from a1, and are
> verifiably the same individual at the same level as for a1, but now on a2
> they are anonymous- “welcome, a1 person”.
>
>
>
> Users shouldn’t need to know an” i1” value for the convenience of support
> operators. Such data should be retrieved and presented by reference to the
> a1 application keyed to a2 sourced data based on the authorised retriever
> having access to both. Otherwise, the user must provide personal details to
> associate with i1, defeating the purpose in the first place..
>
>
>
> Anyway, for more on this, google for details of the Shibboleth protocol, or
> look at the granddaddy of all token exchange protocols, Kerberos, or Yale
> CAS (Yale CAS is an open source SSO for higher ed, that uses SSL based
> protocols for Kerberos-like functionality) for a quick and pretty good open
> source toolkit.
>
>
>
> Regards,
>
> John
>
>
>
>
>
> *From:* owasp-ireland-bounces at lists.owasp.org [mailto:
> owasp-ireland-bounces at lists.owasp.org] *On Behalf Of *Peter McEvoy
> *Sent:* 12 May 2009 17:31
> *To:* owasp-ireland at lists.owasp.org
> *Subject:* [Owasp-ireland] Question about identity over two systems
>
>
>
> Hi guys,
> I'm really not sure if this is an approriate list to ask implmentation
> questions on, but trawling the archives the traffic has been varied, so I'll
> chance my arm and if anyone can point me to a more appropriate list...
>
> I'm looking for a technique that will allow an application A1 to create
> user transactions in another application A2, _without sharing any
> identifying information_.
>
> Specifically:
>
> 1) Application A1 stores information for a set of user entities.  User u1
> is identitifed by i1
>
> 2) A1 wants to create a transaction in application A2 for application user
> u1, but MUST NOT share any identifying information with A2 (due to data
> protection act).  A2 cannot store any identifying information, likewise due
> to DPA.
>
> 3) Application User u1 needs to identify and authenticate herself to A2 so
> that she can query transactions that are hers
>
> 4) Support user u2 wants to query A2 and list transactions of u1.  The
> support user will know i1 (or be able to request it from the user - but not
> any secret information).
>
> I have identified one solution using hashes:
> - Calculate hash i1, and use that as an identifier in all transactions.
> Call this H(i1).
> - u1 can submit (i1, password) to the application A2. A2 calculates H(i1)
> (but does not store i1) and that is used to query transactions. Password is
> used to authenticate
> - After having authenticated to A2 using (i2, supportPassword), u2 can
> submit i1 to A2, H(i1) is calculated and used in query.
>
> I _think_ this approach is sound, but would like confirmation from you
> guys!
>
> One identified issue, is that the space of identifiers i1 is well known and
> finite (10^7 combinations).  It could be possible to generate a lookup table
> of all identifiers, and their corresponding hashes.  The only way I can see
> a way around this, is by salting the hash with a PIN that is stored in A1,
> communicated to the user via A1 and is part of the identifying information
> used to calculate the hash.  But then, how do I provide support user access
> to the records in A2  (as the support user cannot know the PIN)?
>
> Here's hoping someone can point me in the right direction!
>
> Pete
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.owasp.org/pipermail/owasp-ireland/attachments/20090514/6c51bbb0/attachment.html 


More information about the Owasp-ireland mailing list