True... until I hack the hell out of it.
Case in point: Financial system used to do bill pay required a SSO
solution. The solution was dependent upon 3DES encryption using CBC
as the encryption mode (look it up for details) which requires an
initialization vector (IV) to kick off encryption. The client
requests to pay bill XYZ for a certain amount from a specific account
number. The request is effectively an SSO request from financial
system A to bill pay provider B. The unencrypted data looks something
like:
Pay_from_Acct|Pay_To_Acct|Amount|TimeStamp|...
So I encrypt the data with 3DES and a unique IV using a static key.
(There is a key rotation schedule, but that's unimportant ATM.) The
data is passed to bill pay provider in the following fashion:
http://provider.example/PayBill?InitiatizationVector=(IV)&encryptedString=(myEncryptedString)
Is it secure?
Nope!
In this case, the specific vulnerability is that the user has
knowledge of the URL, the encrypted string and the IV. Since the user
controls the IV (i.e. he can modify it to suit his needs) and the
account the money is paid out from is in the first 64 bits (1 block in
3DES) of the encrypted string, by brute-force modification of the IV I
can now modify the account ID (again, look up details on CBC mode
encryption with block ciphers for details) and pay bills out of
someone else's account as long as I can do the brute-force attack
within the timeframe of the timestamp expiration and find any one
account that is valid.
Anyway, this is the long way of saying why doing anything like this
involving encrypting the values is probably not a good idea. So
please, stop treating crypto like some magical pixie dust that makes
everything secure. It doesn't.
(As an aside, if ACFUG wants a preso on encryption and security I have
one that I have given before which I can drag out and present
anytime. CF's encryption is teh suck.)
-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 29, 2008, at 5:31 PM, shawn gorrell wrote:
But using strong encryption *sounds* very secure. And really it
isn't a matter of how secure that you really are, as long as your
solution *sounds* very secure to senior management. Right?
----- Original Message ----
From: Dean H. Saxe <[EMAIL PROTECTED]>
To: [email protected]
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 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).
Encrypting the values means that you need a way to share keys
securely, rotate keys, etc. What a total PITA.
-dhs
Dean H. Saxe, CISSP, CEH
[EMAIL PROTECTED]
"Dissent is the purest form of patriotism."
--Thomas Jefferson
On Jul 29, 2008, at 3:28 PM, Ajas Mohammed 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 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 http://www.fusionlink.com
-------------------------------------------------------------
-------------------------------------------------------------
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
-------------------------------------------------------------
