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 is? ;-)
-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 5:17 PM, sharrison wrote:
When you say “no one knows’, this is security through obfuscation,
and it’s almost always a Bad Plan™. 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 CreateUUID, and put it in the
database.
2. Encrypt it and send it with the CFLocation.
3. Go ahead and do your processing as described, but check the
database for the txUID – if it hasn’t been used, then let the
process continue, and mark the txUID as having been used. If it has,
then stop the login.
Adding a transaction receipt to what you’re implementing will help
(As will SSL, if you want to defend against replay attacks, etc),
but to do it right, you need to assume that everyone on the net
understands your architecture – what your tables are, what
algorithms you’re using, etc – and still make it secure. This is why
the encryption community won’t take anyone seriously unless they
fully disclose their algorithms.
W. Sean Harrison
Founder, CTO
ALIENetworks LLC
http://www.ALIENetworks.com
[EMAIL PROTECTED]
105 1/2 Main St
Smyrna, TN 37167
Direct: 615.838.9289
<image001.gif>
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ajas
Mohammed
Sent: Tuesday, July 29, 2008 2:28 PM
To: [email protected]
Subject: [ACFUG Discuss] cflocation with variables encrypted, is it
safe approach?
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 through uname pwd textbox, the usual way.
The idea with single sign on is to avoid that login verification
page. So, while redirecting user to secure area, I am planning to
pass 2 parameters in cflocation i.e. 1. to indicate its single sign
on, so in Application.cfm for secure area folder, I can set client
variables 2. the encrypted value of random key generated using
GenerateSecretKey func.
here is some code/logic
<cfset redirectToSS = "whatever">
<!--- generate a key, the alogorithm, encoding variables are set
before this --->
<cfset key = GenerateSecretKey(algorithm)>
<cfset redirectToSS = Encrypt(redirectToSS,key,algorithm,encoding)
<cfset encKey = Encrypt(key,"sometext")>
<cflocation url="../secureArea/MyHome.cfm?
redirectToSS=#redirectToSS#&vartest=#encKey#" >
Now in secureArea/Application.cfm
I will use redirectToSS and varTest. First decrypt varTest to get
keyvalue and then use key value to see whats in redirectToSS.
So,
<cfif redirectToSS eq "whatever">
set client variables that are needed to access application.
</cfif>
Does this makes sense? Is this approach safe, security wise,
considering no one knows what algorithm, encoding iam using to
encrypt redirectToSS and also the fact that the key is sent over
encrypted.
I am I missing something important here? Any holes in this approach?
Thanks,
--
<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 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
-------------------------------------------------------------