Thanks everyone for the replies.

Thanks Dean for giving a detailed insight about encryption and back channel.
Thanks Sean for CreateUUID example.

I am glad I am not using encryption now because crazy things were happening,
beyond my control.

I am sticking to the idea suggested by pretty much everyone
i.e. unique random ID, identifying the transaction which is independent of
the user .

Thanks a lot.

Ajas.



On 7/30/08, Dean H. Saxe <[EMAIL PROTECTED]> wrote:
>
> BTW, the reason your solution is inappropriate is because you have allowed
> the user to control the transaction by controlling the data passed between
> the two systems.  By passing the data via a back channel you can remove the
> user from the authentication mechanism between the two systems and require
> the user to have previously authenticated via your site before using SSO to
> the target site.  Your solution doesn't require any prior login, since a
> user could theoretically "guess" a valid login string.  (Theoretically being
> the key term here.  Unlikely is another.  But it is still not a good idea.)
>
> -dhs
>
>
> Dean H. Saxe, CISSP, CEH
> [EMAIL PROTECTED]
> "If liberty means anything at all, it means the right to tell people what
> they do not want to hear."
>    -- George Orwell, 1945
>
>
>
> On Jul 30, 2008, at 11:30 AM, Dean H. Saxe wrote:
>
> Ajas,
>>
>> Your model is broken.  Not to say I have never implemented a similar
>> solution, I have.  But it is a poor solution which can be significantly
>> improved.  (I run into these all the time on penetration tests, so you are
>> not the first or last to try this...)
>>
>> A valid, strong solution would pass the structure from server to server
>> via a back channel and avoid the user altogether.  If done over SSL, there
>> is no need for encryption (beyond the SSL).  A unique, time limited, highly
>> random token (not a UUID) would be used to identify the transaction and that
>> is the only information needed by the user, this clearly needs to be
>> provided in the transaction passed via the back channel and should be
>> created from a secure random number generator.  The server receiving the SSO
>> request  (target server) would need to maintain state of all requests passed
>> by the back channel and remove those requests from its queue when they time
>> out (e.g. <2 minutes after receipt) or when the valid request from the user
>> containing the SSO identifier is received by the target server.
>>
>> There is little extra work needed for this solution, but the long term
>> time/effort savings are huge by not having to deal with the problems brought
>> up by encryption.  Might as well get it right the first time, rather than
>> having to recode a proper solution later after you find out why yours is
>> broken, right?
>>
>> -dhs
>>
>> Dean H. Saxe, CISSP, CEH
>> [EMAIL PROTECTED]
>> "A true conservationist is a person who knows that the world is not given
>> by his fathers, but borrowed from his children."
>> -- John James Audubon
>>
>>
>>
>>
>> On Jul 30, 2008, at 11:10 AM, Ajas Mohammed wrote:
>>
>> Hi,
>>>
>>> Thanks everyone for the suggestions. Those suggestions were really
>>> helpful.
>>>
>>> Sean, CreateUUID looks like a good idea. I will use it in addition to my
>>> logic. Anyone wants to comment anything about that approach.
>>>
>>> Dean, The reason I want to encrypt is because I plan to pass a structure
>>> as url parameter using wddx and I want to pass it over encrypted, otherwise
>>> it looks like simple xml with all values easily seen in url.I have to use
>>> wddx because I cant pass structure as url parameter.
>>>
>>> Shawn, agreed about management. Honestly, no one asked me todo this. I
>>> want to make it as safe as possible using the help from some great minds we
>>> have in this group. ;-) .
>>>
>>> Ajas.
>>>
>>>
>>> On 7/29/08, [EMAIL PROTECTED] <
>>> [EMAIL PROTECTED]> wrote: Return Receipt
>>>
>>>  Your       Re: [ACFUG Discuss] cflocation with variables encrypted, is
>>>  document:  it safe approach?
>>>
>>>  was        [EMAIL PROTECTED]
>>>  received
>>>  by:
>>>
>>>  at:        07/29/2008 06:01:18 PM
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> -------------------------------------------------------------
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.edituserform<http://www.acfug.org/?fa=login.edituserform>
>>>
>>> For more info, see http://www.acfug.org/mailinglists
>>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>>> List hosted by http://www.fusionlink.com
>>> -------------------------------------------------------------
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> <Ajas Mohammed />
>>> http://ajashadi.blogspot.com
>>> We cannot become what we need to be, remaining what we are.
>>> No matter what, find a way. Because thats what winners do.
>>> You can't improve what you don't measure.
>>> Quality is never an accident; it is always the result of high intention,
>>> sincere effort, intelligent direction and skillful execution; it represents
>>> the wise choice of many alternatives.
>>> -------------------------------------------------------------
>>> To unsubscribe from this list, manage your profile @
>>> http://www.acfug.org?fa=login.edituserform<http://www.acfug.org/?fa=login.edituserform>
>>>
>>> For more info, see http://www.acfug.org/mailinglists
>>> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
>>> List hosted by FusionLink
>>> -------------------------------------------------------------
>>>
>>
>>
>
>
> -------------------------------------------------------------
> To unsubscribe from this list, manage your profile @
> http://www.acfug.org?fa=login.edituserform<http://www.acfug.org/?fa=login.edituserform>
>
> For more info, see http://www.acfug.org/mailinglists
> Archive @ http://www.mail-archive.com/discussion%40acfug.org/
> List hosted by http://www.fusionlink.com
> -------------------------------------------------------------
>
>
>
>


-- 
<Ajas Mohammed />
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.



-------------------------------------------------------------
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-------------------------------------------------------------

Reply via email to