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 verific
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,
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 3:40 PM, shawn gorrell <[EMAIL PROTECTED]> wrote:
> Crap Cam, you type faster than I do... I'd just posed the replay attack
> problem.
Heh - Replay Attack FTW!
Serious though - Ajas I think a common workflow would be this:
1) SSO generates a one time use token, crypts it,
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.
Dawn, SSO is handled through a seperate application.
I believe I have done necessary things and I plan to do *more*, just to be
on safe side/to make myself happ
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 s
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 authenti
Packet sniffers. Server logs. Pick your poison.
Sent via BlackBerry by AT&T
-Original Message-
From: "Ajas Mohammed" <[EMAIL PROTECTED]>
Date: Tue, 29 Jul 2008 16:45:51
To:
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is it safe
approach?
T
Packet sniffers. Server logs. Pick your poison.
Sent via BlackBerry by AT&T
-Original Message-
From: "Ajas Mohammed" <[EMAIL PROTECTED]>
Date: Tue, 29 Jul 2008 16:45:51
To:
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is it safe
approach?
T
>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 so
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).
Enc
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 suscept
2008, at 4:53 PM, [EMAIL PROTECTED] wrote:
Packet sniffers. Server logs. Pick your poison.
Sent via BlackBerry by AT&T
From: "Ajas Mohammed" <[EMAIL PROTECTED]>
Date: Tue, 29 Jul 2008 16:45:51 -0400
To:
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is
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,
Guys,
Remove encryption from the process. Encryption just complicates
things and makes the maintenance more of a pain in the rear than
necessary. Encryption is not needed if you choose a suitably secure
identifier to pass around to the client. After all, what do you think
a JSESSIONID
ug.org
Sent: Tuesday, July 29, 2008 5:06:23 PM
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is it safe
approach?
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 t
your
solution *sounds* very secure to senior management. Right?
- Original Message
From: Dean H. Saxe <[EMAIL PROTECTED]>
To: discussion@acfug.org
Sent: Tuesday, July 29, 2008 5:06:23 PM
Subject: Re: [ACFUG Discuss] cflocation with variables encrypted, is
it safe approach?
Do
Return Receipt
Your Re: [ACFUG Discuss] cflocation with variables encrypted, is
document: it safe approach?
Return Receipt
Your Re: [ACFUG Discuss] cflocation with variables encrypted, is
document: it safe approach?
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 pa
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 woul
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 an
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 eve
Ajas,
FWIW, you can either push the info to the remote site to be identified
by the ID or have the remote site pull it from you. Your choice,
really.
-dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
"I have always strenuously supported the right of every man to his own
opinion, however
26 matches
Mail list logo
