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
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 FusionLink
-------------------------------------------------------------
-------------------------------------------------------------
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
-------------------------------------------------------------
