Thanks all for your help so far. Now I have been looking at the
documentation for encrypt/decrypt and I would like to use one of the more
secure encryption algorithms, such as BLOWFISH or DES. I notice that the
more secure algorithms use the function GenerateSecretKey. Now do this mean
that when
Hi all, I am trying to store specific data into a database in an encrypted
format. This data also has to be decrypted so as to be displayed and edited
onscreen therefore ruling out using the hash function. The problem that I am
having is on the decrypt.
Example:
cfset foo =
From: Andy Mcshane [mailto:[EMAIL PROTECTED]
This is on Coldfusion 7, using a SQL database. I have tried
URLEncodedFormat before saving to the database and then using
URLDecode after retrieveing. As this text is defined by the
user then I cannot simply say that there can be no 10
use
my example data you can easily replicate the issue.
-Original Message-
From: Tangorre, Michael [mailto:[EMAIL PROTECTED]
Sent: 26 September 2005 12:57
To: CF-Talk
Subject: RE: Weird Encrypt/Decrypt problem!
From: Andy Mcshane [mailto:[EMAIL PROTECTED]
This is on Coldfusion 7, using
Whoa. So weird I also tested here, and the encoded johnmurray was
decoded to johnmurrax! It's not with all 10 charcs. string, by the way.
I think this is a CF default algorithm (CFMX_COMPAT, which is compatible
do earlier versions of CF) implementation bug.
You should use a more secure and
PROTECTED]
Sent: 26 September 2005 14:45
To: CF-Talk
Subject: Re: Weird Encrypt/Decrypt problem!
Whoa. So weird I also tested here, and the encoded johnmurray was
decoded to johnmurrax! It's not with all 10 charcs. string, by the way.
I think this is a CF default algorithm (CFMX_COMPAT, which
OK, follow up to this, can anybody suggest ways that they currently
encrypt/decrypt sensitive data? I need to encrypt the data to save into the
database and then at a later date retrieve that data, decrypt it and let the
user edit it. I have looked at using the various algorithms excluding
There is no bug in encrypt/decrypt, the problem is that in that
instance, the encrypt result contains a space at the end.
As you can see with the following code, the key is not *5)V%5*.Z59RR$,
but *5)V%5*.Z59RR$
cfset foo = encrypt(johnmurray, wibble)
CFOUTPUT[#htmlEditFormat(foo)#],
Does your database itself provide encrypted storage? That'd certainly
be easier if it does.
On a different topic, executing the code you listed demonstrated the
error with 'y' becoming 'x', but if the decrypt operation is changed
to use the foo variable directly, the proper result is returned.
The pre CF7 encrypt() function does not create dbsafe strings. You have to
toake it a further step for that: Wrap the string in toBase64() before you
store the data. IIRC (its been awhile) you use tostring() when decrypting.
I think the new algorithm options in cfencrypt()/cfdecrypt() could be
and that trailing space is being trimmed out by the db. Sooner or later
you would have other issues even if you work around this one somehow. See my
post on this in the other thread. Its an easy fix but you won't make the
'classic' CF algorithm any more secure.
--
--mattRobertson--
Janitor,
Whoops its not tostring that takes something out of base64. Its decode().
I have a template that I built up years ago from the CF example that
displays a bunch of different ways to skin this cat. You can pick it
apart to bulletproof your use of CF encryption.
CFSET
:[EMAIL PROTECTED]
Sent: Monday, September 26, 2005 12:30 PM
To: CF-Talk
Subject: Re: Weird Encrypt/Decrypt problem!
The pre CF7 encrypt() function does not create dbsafe strings. You have to
toake it a further step for that: Wrap the string in toBase64() before you
store the data. IIRC (its been
Those 'undocumented' functions have been documented for some time in
various places, including houseoffusion.com. There has been plenty of
discussion of them over the years.
The trouble with them is they are not guaranteed to be there in future
versions, and if they do remain their behavior is
There is no bug in encrypt/decrypt, the problem is that in that
instance, the encrypt result contains a space at the end.
Yeah. It's true. I totally missed that! No bug at all! :-)
[]s
Fabio Terracini
~|
Logware
Its actually not a bug. The encrypted string that is generated is
*5)V%5*.Z59RR$ with a space at the end. When you decrypt the string, if you
use the same string it will work as it should. In your case, the string was
trimmed and hence this behaviour.
You can verify this using this code
16 matches
Mail list logo
