If I discover the URL, what prevents me from using this same URL again?
On Tue, Jul 29, 2008 at 3:28 PM, Ajas Mohammed [EMAIL PROTECTED] wrote:
Hi,
I am implementing single sign on and after I verify user credentials, I have
to redirect user to secure area which has its own login verification
Right off the top of my head I would say that your specific implementation
would be susceptible to a replay attack. But I'll defer to Dean if he's
listening while on vacation...
- Original Message
From: Ajas Mohammed [EMAIL PROTECTED]
To: discussion@acfug.org
Sent: Tuesday, July 29,
Crap Cam, you type faster than I do... I'd just posed the replay attack problem.
- Original Message
From: Cameron Childress [EMAIL PROTECTED]
To: discussion@acfug.org
Sent: Tuesday, July 29, 2008 3:36:56 PM
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is it safe
Are you using IIS/Kerberos authentication where it's all handled on the
server and pulling who it is from there - or is your SSO handled through a
separate application where (for instance) an encrypted cookie is set so
applications across several servers can utilize the cookie for
authentication -
On Tue, Jul 29, 2008 at 4:11 PM, Ajas Mohammed [EMAIL PROTECTED] wrote:
Shawn/Cameron, yeap thats a big hole and I plan to use timestamp to avoid
it, but I dont know right now exactly how that will be done.
Using any predictable or easy to guess information (like a timestamp)
is not a good
Thanks for suggestion Cameron.
Before we get into that, Let me take one step backwards.
How will someone get my url. Here is the process explained in detial.
there are 2 parties. one identity provider(Idp) and other service
provider(SP) i.e. me.
identity provider has there own server to
Packet sniffers. Server logs. Pick your poison.
Sent via BlackBerry by ATT
-Original Message-
From: Ajas Mohammed [EMAIL PROTECTED]
Date: Tue, 29 Jul 2008 16:45:51
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is it safe
approach?
Thanks
From a security standpoint, CFLOCATION is the same as clicking a link
in a broswer (since CFLOCATION actually just send a relcation command
to the browser). URL vars from CFLOCATIONs may be found in IIS logs,
browser cache files, or observed in transit.
That makes it quite significant in your
Do not encrypt the values. You should send the values via a back
channel with a non-spoofable, non guessable, time limited (i.e. 2
min) token that is passed to the user and then the user is passed to
the new server (i.e. a client-side redirection using HTTP 3xx series
status codes).
Indeed Shawn.
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
Great spirits have often encountered violent opposition from weak
minds.
--Einstein
On Jul 29, 2008, at 3:40 PM, shawn gorrell wrote:
Right off the top of my head I would say that your specific
implementation would be
Hell, it goes to the user as part of the 302 redirect! So the URL is
easily identified.
-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 29, 2008, at
When you say no one knows', this is security through obfuscation, and it's
almost always a Bad PlanT. What you're implementing seems vulnerable to a
reply attack, if someone sniffed the transaction - I'd suggest at least
including a transaction state variable:
1. Create a new txUID with
BTW, creating this value in CF can be done, but make sure you don't
use rand(), its not random enough. Get 128 bits of entropy from
javax.security.SecureRandom().
dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
Dissent is the purest form of patriotism.
--Thomas Jefferson
On Jul 29,
Return Receipt
Your Re: [ACFUG Discuss] cflocation with variables encrypted, is
document: it safe approach?
14 matches
Mail list logo
