Re: [WebDNA] Encode cookies ONLY via "method=Base64"

This WebDNA talk-list message is from

2008


It keeps the original formatting.
numero = 101291
interpreted = N
texte = --Apple-Mail-39--59666912 Content-Type: multipart/alternative; boundary=Apple-Mail-38--59666966 --Apple-Mail-38--59666966 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Prime numbers only matter for secure file exchanges - not for encrypting a single file. Multiply two large primes together and it takes computers a lot of time to figure out what the factors of this product are. In a secure file exchange, the public key is the product of two large primes and the private key is either of the factors. Then, you encrypt the file with the other factor. Anyone intercepting the file has to figure out what the factors of the product are, and then which one is actually the seed for encryption of the file. I don't think its hard for today's computers to figure out 9 digit primes. In fact, that probably takes a few seconds on a fast machine. If you're depending on the speed of finding the factors as the main security, you need primes with hundreds of digits. These can be found online. And there's actually enough of them that it still takes too long when computers test only known primes. The best security is still common sense. Putting anything sensitive in a cookie is foolish. Putting a sku number in there makes sense. Then, making your data relational and configuring database permissions well makes more hurdles. You reach a point where the cost of the hassle exceed the value of the information. Pat On Oct 27, 2008, at 4:43 AM, Psi Prime, Matthew A Perosi wrote: > wow > That sounds like a lot of overhead. > I bet the algebra would be a lot faster. You would still need your > initial db to hold your custom ascii table though. > > Assuming you were only using 26+10=36 characters, you could create a > custom ascii table using 2 digits for each character. Then lets > assume you have a 10 character username and a 10 character > password. 20 characters total would convert to a string that is 40 > digits long. You could use 3 digits in your ascii table to make it > longer, the numbers don't have to be sequential either. > > Once you have a 40 digit long number you could do something like this > [math]cookiein=([40digits]*533000389)/125[/math] > That number gets sent as the cookie using [setcookie > name=fred&value=[cookiein]] > > Then to decode it you would use [math]cookieout=[getcookie fred][/ > math] > [math]40digits=(125*[cookieout])/533000389[/math] > At this point you could use a [loop] and a [getchars] to parse back > through the 40 digit string and reverse decode through your ascii > table. > > The security here all lies in the prime number. The only way to > decode the username and password would be to know the number. Since > it still takes a supercomputer to actually find prime numbers you > are IMHO not likely to come across a hacker with a supercomputer > that will be wasting his time trying to hack a website. > > Matthew A Perosi JewelerWebsites.com > ------------------------------by Psi Prime------- > Senior Web Developer 323 Union Blvd. > Totowa, NJ 07512 > Pre-Sales: 888.872.0274 > Service: 973.413.8213 > Training: 973.413.8214 > Fax: 973.413.8217 > > http://www.jewelerwebsites.com > http://en.wikipedia.org/wiki/Psi_Prime%2C_Inc > http://www.psiprime.com > > > Kenneth Grome wrote: >> >>> I'm curious what you might be using as a routine to >>> generate that string of 500 random characters. >>> >> I just entered 26 lowercase and 26 uppercase alpha chars and >> 10 digits into a db file, one record for each char, then I >> do a search for all records which gives me 62 total chars >> that can be retrieved, but I limit the search to the first >> 30 chars and I run the search inside a loop that iterates >> 70 times thus giving me a string of 2100 chars. I guess I >> could use other chars in the db but I know that >> alphanumerics won't create problems so I'll probably just >> stick with what I have for now. >> >> Then I create a random number between 1 and 1000 using >> several [random] tags and getchars which limits the >> resulting random number to 3 chars in length, and I use >> this [rn] as the start value with 999+[rn] as the end value >> in another getchars to extract a contiguous segment of the >> 1000 random chars from the original 2100 random char >> string -- so yes I'm using 1000 chars now rather than the >> 500 chars previously mentioned. >> >> Then I use another db with 50 fields and 50 records, each >> field containing one unique value ranging from 1-999. >> These values appear in random order in the columns in the >> db and there are no duplicates in these columns, so that >> when I search this db via rank=off I get 50 non-duplicate >> values ranging from 1-999 in whatever field I choose to >> retrieve. >> >> Next I count the number of characters in the "string to be >> encoded" which consists of the username then a separator >> string then the password all concatenated together. The >> number of chars in this string determines which field of >> values to retrieve from my 50x50 db. Each of the 50 >> retrieved values in the selected field represents a >> character positions in my original 1000 char random >> string ... >> >> I simply take the value from the first (then second, then >> third, etc.) record in the db, find the char position >> corresponding to that value (1-999) in the string of 1000 >> chars, and replace that char with the first (then second, >> then third, etc.) char appearing in my "string to be >> encoded". >> >> When all the chars in my "string to be encoded" have >> replaced the appropriate chars in my 1000 char string I use >> Base64 to further encode the resulting 1000 char string >> which becomes 1/3 longer, and that's the value I set as the >> cookie that identifies whether or not the visitor is valid >> and logged in. >> >> That's as far as I've gotten with it, and I haven't tested >> its speed yet but hopefully it will be 'fast enough'. >> >> :) >> >> Sincerely, >> Ken Grome >> >> >> >> >> >> >> >>> I'm curious what you might be using as a routine to >>> generate that string of 500 random characters. >>> >>> All the random character generators, or random image >>> choosers I've ever written always seem to be weighted >>> toward selecting numbers or images closer to the middle >>> of my field of selection rather than evenly over the >>> entire set of selectable items. I typically use the >>> [random] tag and calculate from there, but in my own >>> testing the number returned from the [random] tag seem to >>> follow a standard statistical bell curve. >>> >>> Whatever random character generator you create make sure >>> it include all possible characters that you would allow >>> within your username and password, and then make sure >>> they show up equally. >>> >>> Thinking about this a little differently you could also >>> convert your usernames and passwords into a number, >>> perhaps using your own version of an ascii table. Then >>> either mod, multiply, divide or otherwise write your own >>> algebraic equation that uses a sufficiently large prime >>> number like 533,000,389 in the calculation. >>> >>> With this procedure you are creating your own encryption >>> algorithm. This is actually the same procedure they use >>> in field of Liner Algebra to create new encryption >>> routines. Governments are always trying to discover the >>> next largest prime number faster than anyone else, >>> because at least for a little while until large primes >>> can be found those types of encryptions are unbreakable. >>> >>> To date there are more than 50 million prime numbers that >>> have been discovered. The higher the prime you select >>> the more difficult your self encryption will be to hack. >>> The most recent prime number was discovered on September >>> 8, 2008 and it had about 12.9 million digits. Can WebDNA >>> even handle a calculation that large? >>> >>> Anyway, using your own equation might be faster in the >>> long run than what you are suggesting. >>> >>> BTW, I did name my company partially after my >>> understanding of Prime Numbers. :-) >>> >>> >>> Matthew A Perosi >>> Psi Prime, Inc. >>> Senior Web Developer 323 Union Blvd. >>> Totowa, NJ 07512 >>> Pre-Sales: 888.872.0274 >>> Service: 973.413.8213 >>> Training: 973.413.8214 >>> Fax: 973.413.8217 >>> >>> http://www.jewelerwebsites.com >>> http://en.wikipedia.org/wiki/Psi_Prime%2C_Inc >>> http://www.psiprime.com >>> >>> Kenneth Grome wrote: >>> >>>>> Try "hiding" the value inside a longer string and then >>>>> use getchars to get the true value. >>>>> >>>> That's my plan at the moment. My current thoughts are >>>> to take this approach: >>>> >>>> Insert each of the user/pass chars into specified >>>> locations within a very long string of random >>>> characters. >>>> >>>> Example, I create a string of 500 random chars, then I >>>> replace the chars that exist in "certain positions" >>>> with my original user/pass chars. For example, if the >>>> user value is "someusername" I will use each of those >>>> 12 chars, one at a time, to replace one char in a >>>> pre-specified position in the string of 500 chars. >>>> Same with the pass value. Then I use Base64 to further >>>> encode it before setting the result as a cookie value. >>>> >>>> So the hacker has a problem: >>>> >>>> First he must realize that the cookie is Base64 encoded >>>> and decode it. Then he will see a string of 500 chars >>>> to further decode, but he doesn't know how many chars >>>> are in the user/pass values, nor does he know which of >>>> the 500 positions those chars occupy. >>>> >>>> I think this should work until WebDNA can handle >>>> encrypted cookies properly. Do any of you see >>>> potential problems with this approach? >>>> >>>> Sincerely, >>>> Ken Grome >>>> >>>> >>>>> Ken >>>>> >>>>> Try "hiding" the value inside a longer string and then >>>>> use getchars to get the true value >>>>> >>>>> I resorted to this technique some time ago when I >>>>> ended up with problems. >>>>> >>>>> Stuart >>>>> >>>>> On 27/10/2008, at 10:02 AM, Kenneth Grome wrote: >>>>> >>>>>>> sometimes a second decrypt and/or unurl >>>>>>> is needed. >>>>>>> >>>>>> A different number of decrypts and encrypts never >>>>>> works, you must always use the same number of these >>>>>> contexts. A different number of urls and unurls is >>>>>> definitely necessary >>>>>> >>>>>> sometimes: >>>>>> >>>>>>> Syntax reminder on variable (straight), and database >>>>>>> encryption: >>>>>>> Straight encryption: same amount of [url]'s going in >>>>>>> as comming out >>>>>>> Database encryption: one more [url] going in >>>>>>> than comming out >>>>>>> >>>>>> Right, thanks for the reminder. >>>>>> >>>>>> With the cookies I first tried the same number of >>>>>> urls and unurls but it was failing, so then I tried >>>>>> using one more url going in -- because I thought that >>>>>> *maybe* using cookies is similar to using a database. >>>>>> But this theory was wrong because an extra url with >>>>>> cookies does not fix the problem like it does with a >>>>>> database. >>>>>> >>>>>> >>>>>>> Could you please tell us what server you're using? >>>>>>> >>>>>> My client's Windows server running WebDNA 6.? >>>>>> >>>>>> >>>>>>> I have found the same thing as Ken has, and that it >>>>>>> is on our list of potential bugs that we are >>>>>>> addressing. The scope appears to be only in cookie >>>>>>> and orderfile interaction so far. >>>>>>> >>>>>> Orderfile too? >>>>>> >>>>>> Thanks Donovan, that's two scopes we should avoid >>>>>> when using the standard WebDNA encryption. Too bad >>>>>> though, since I want to use encrypted cookies for >>>>>> security reasons. >>>>>> >>>>>> >>>>>> PROBABLE CONCLUSION: >>>>>> >>>>>> Although Base64 is an encoding method (not an >>>>>> encryption method) it is the ONLY method that >>>>>> actually works when trying to obfuscate cookie >>>>>> values. >>>>>> >>>>>> Base64 is certainly not secure like an encrypted >>>>>> value might be, but it is better than nothing I >>>>>> guess. I tested all methods using cookies with the >>>>>> following results: >>>>>> >>>>>> standard webdna encryption --> fails 1/4 of the time >>>>>> method=CyberCash --> cannot be decrypted >>>>>> method=APOP --> cannot be decrypted >>>>>> method=Base64 --> 100% reliable in dozens of tests >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> Ken Grome >>>>>> ----------------------------------------------------- >>>>>> -- -- This message is sent to you because you are >>>>>> subscribed to the mailing list . To >>>>>> unsubscribe, E-mail to: >>>>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>>>> >>>>> ------------------------------------------------------ >>>>> --- This message is sent to you because you are >>>>> subscribed to the mailing list . >>>>> To unsubscribe, E-mail to: >>>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>>> >>>> ------------------------------------------------------- >>>> -- This message is sent to you because you are >>>> subscribed to the mailing list . >>>> To unsubscribe, E-mail to: >>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>> >> >> --------------------------------------------------------- >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> archives: http://mail.webdna.us/list/talk@webdna.us >> old archives: http://dev.webdna.us/TalkListArchive/ >> >> >> --Apple-Mail-38--59666966 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Prime numbers only matter for = secure file exchanges - not for encrypting a single = file.

Multiply two large primes together and it takes = computers a lot of time to figure out what the factors of this product = are.  In a secure file exchange, the public key is the product of = two large primes and the private key is either of the factors. =  Then, you encrypt the file with the other factor. Anyone = intercepting the file has to figure out what the factors of the product = are, and then which one is actually the seed for encryption of the = file.

I don't think its hard for today's = computers to figure out 9 digit primes. In fact, that probably takes a = few seconds on a fast machine. If you're depending on the speed of = finding the factors as the main security, you need primes with hundreds = of digits.  These can be found online. And there's actually enough = of them that it still takes too long when computers test only known = primes.

The best security is still common = sense.  Putting anything sensitive in a cookie is foolish. Putting = a sku number in there makes sense.  Then, making your data = relational and configuring database permissions well makes more hurdles. = You reach a point where the cost of the hassle exceed the value of the = information.

Pat

On Oct = 27, 2008, at 4:43 AM, Psi Prime, Matthew A Perosi wrote:

wow
That sounds like a lot of = overhead.
I bet the algebra would be a lot faster.  You would = still need your initial db to hold your custom ascii table though.
=
Assuming you were only using 26+10=3D36 characters, you could = create a custom ascii table using 2 digits for each character.  = Then lets assume you have a 10 character username and a 10 character = password.  20 characters total would convert to a string that is 40 = digits long.  You could use 3 digits in your ascii table to make it = longer, the numbers don't have to be sequential either.

Once = you have a 40 digit long number you could do something like this
= [math]cookiein=3D([40digits]*533000389)/125[/math]
That number gets = sent as the cookie using [setcookie name=3Dfred&value=3D[cookiein]]
Then to decode it you would use [math]cookieout=3D[getcookie = fred][/math]
[math]40digits=3D(125*[cookieout])/533000389[/math]
= At this point you could use a [loop] and a [getchars] to parse back = through the 40 digit string and reverse decode through your ascii = table.

The security here all lies in the prime number.  = The only way to decode the username and password would be to know the = number.  Since it still takes a supercomputer to actually find = prime numbers you are IMHO not likely to come across a hacker with a = supercomputer that will be wasting his time trying to hack a = website.

Matthew A =Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.com=http://en.wikipedia=.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com

=
Kenneth Grome wrote:
= 
I'm curious what you might =be using as a routine togenerate that string of 500 random characters.    
I just entered 26 =lowercase and 26 uppercase alpha chars and=2010 digits into a db file, one record for each char, then I=20do a search for all records which gives me 62 total chars=20that can be retrieved, but I limit the search to the first=2030 chars and I run the search inside a loop that iterates=2070 times thus giving me a string of 2100 chars. I guess I=20could use other chars in the db but I know that=20alphanumerics won't create problems so I'll probably just=20stick with what I have for now.Then I create a random number between 1 and 1000 using=20several [random] tags and getchars which limits the=20resulting random number to 3 chars in length, and I use=20this [rn] as the start value with 999+[rn] as the end value=20in another getchars to extract a contiguous segment of the=201000 random chars from the original 2100 random char=20string -- so yes I'm using 1000 chars now rather than the=20500 chars previously mentioned.Then I use another db with 50 fields and 50 records, each=20field containing one unique value ranging from 1-999. =20These values appear in random order in the columns in the=20db and there are no duplicates in these columns, so that=20when I search this db via rank=3Doff I get 50 non-duplicate=20values ranging from 1-999 in whatever field I choose to=20retrieve.Next I count the number of characters in the "string to be=20encoded" which consists of the username then a separator=20string then the password all concatenated together.  The=20number of chars in this string determines which field of=20values to retrieve from my 50x50 db.  Each of the 50=20retrieved values in the selected field represents a=20character positions in my original 1000 char random=20string ... =20I simply take the value from the first (then second, then=20third, etc.) record in the db, find the char position=20corresponding to that value (1-999) in the string of 1000=20chars, and replace that char with the first (then second,=20then third, etc.) char appearing in my "string to be=20encoded". =20When all the chars in my "string to be encoded" have=20replaced the appropriate chars in my 1000 char string I use=20Base64 to further encode the resulting 1000 char string=20which becomes 1/3 longer, and that's the value I set as the=20cookie that identifies whether or not the visitor is valid=20and logged in.That's as far as I've gotten with it, and I haven't tested=20its speed yet but hopefully it will be 'fast enough'.:)Sincerely,Ken Grome  
I'm curious what =you might be using as a routine togenerate that string of 500 random characters.All the random character generators, or random imagechoosers I've ever written always seem to be weightedtoward selecting numbers or images closer to the middleof my field of selection rather than evenly over theentire set of selectable items.  I typically use the[random] tag and calculate from there, but in my owntesting the number returned from the [random] tag seem tofollow a standard statistical bell curve.Whatever random character generator you create make sureit include all possible characters that you would allowwithin your username and password, and then make surethey show up equally.Thinking about this a little differently you could alsoconvert your usernames and passwords into a number,perhaps using your own version of an ascii table.  Theneither mod, multiply, divide or otherwise write your ownalgebraic equation that uses a sufficiently large primenumber like 533,000,389 in the calculation.With this procedure you are creating your own encryptionalgorithm. This is actually the same procedure they usein field of Liner Algebra to create new encryptionroutines.  Governments are always trying to discover thenext largest prime number faster than anyone else,because at least for a little while until large primescan be found those types of encryptions are unbreakable.To date there are more than 50 million prime numbers thathave been discovered.  The higher the prime you selectthe more difficult your self encryption will be to hack.The most recent prime number was discovered on September8, 2008 and it had about 12.9 million digits. Can WebDNAeven handle a calculation that large?Anyway, using your own equation might be faster in thelong run than what you are suggesting.BTW, I did name my company partially after myunderstanding of Prime Numbers.  :-)Matthew A PerosiPsi Prime, Inc.Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.com=http://en.wikipedia=.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.comKenneth Grome wrote:
= 
Try "hiding" the value inside a longer string and =thenuse getchars to get the true value.        
That's my plan at =the moment.  My current thoughts areto take this approach:Insert each of the user/pass chars into specifiedlocations within a very long string of randomcharacters.Example, I create a string of 500 random chars, then Ireplace the chars that exist in "certain positions"with my original user/pass chars.  For example, if theuser value is "someusername" I will use each of those12 chars, one at a time, to replace one char in apre-specified position in the string of 500 chars.=20Same with the pass value.  Then I use Base64 to furtherencode it before setting the result as a cookie value.So the hacker has a problem:First he must realize that the cookie is Base64 encodedand decode it.  Then he will see a string of 500 charsto further decode, but he doesn't know how many charsare in the user/pass values, nor does he know which ofthe 500 positions those chars occupy.I think this should work until WebDNA can handleencrypted cookies properly.  Do any of you seepotential problems with this approach?Sincerely,Ken Grome      
KenTry "hiding" the value inside a longer string and thenuse getchars to get the true valueI resorted to this technique some time ago when Iended up with problems.StuartOn 27/10/2008, at 10:02 AM, Kenneth Grome wrote:        
sometimes a second decrypt =and/or unurlis needed.            
A =different number of decrypts and encrypts neverworks, you must always use the same number of thesecontexts.  A different number of urls and unurls isdefinitely necessarysometimes:          
Syntax reminder on variable (straight), and databaseencryption:Straight encryption: same amount of [url]'s going inas comming outDatabase encryption: one more [url] going inthan comming out            
Right, =thanks for the reminder.With the cookies I first tried the same number ofurls and unurls but it was failing, so then I triedusing one more url going in -- because I thought that*maybe* using cookies is similar to using a database. But this theory was wrong because an extra url withcookies does not fix the problem like it does with adatabase.          
Could you please tell us what server you're using?            
My =client's Windows server running WebDNA 6.?          
I have found the same thing as Ken has, and that itis on our list of potential bugs that we areaddressing. The scope appears to be only in cookieand orderfile interaction so far.            
Orderfile too?Thanks Donovan, that's two scopes we should avoidwhen using the standard WebDNA encryption.  Too badthough, since I want to use encrypted cookies forsecurity reasons.PROBABLE CONCLUSION:Although Base64 is an encoding method (not anencryption method) it is the ONLY method thatactually works when trying to obfuscate cookievalues.Base64 is certainly not secure like an encryptedvalue might be, but it is better than nothing Iguess. I tested all methods using cookies with thefollowing results:standard webdna encryption --> fails 1/4 of the timemethod=3DCyberCash --> cannot be decryptedmethod=3DAPOP --> cannot be decryptedmethod=3DBase64 --> 100% reliable in dozens of testsSincerely,Ken Grome------------------------------------------------------- -- This message is sent to you because you aresubscribed to the mailing list <talk@webdna.us>. Tounsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/          
--------------------------------------------------------- This message is sent to you because you aresubscribed to the mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/        
--------------------------------------------------------- This message is sent to you because you aresubscribed to the mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/      
---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/
=

= --Apple-Mail-38--59666966-- --Apple-Mail-39--59666912 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGTCCAtIw ggI7oAMCAQICEBmvvAg5L6PclE8ruwo/gMYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyNzAxMTg1M1oXDTA5MDkyNzAxMTg1 M1owPjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMcG1A d2ViZG5hLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtb7ZYYJV7sbgqxdgpBU/ qCRsIJYGNIo40L9odKmo6Y/mPBybeSry8KefqmuWoBXxc6xCvSSJDWFcb2sZ+TkedZrdxvtoL1pH NjDZNe2ow+RCNUvJcQd1+ASzh0J4QLHnNyoMY3zuCQwqM6hK5gU4AlpOSITekksSFuGXBdJTjSeI gIpZFTTrd1c/Zv7miT9gO5UmHiyDClKP8oX31YFlb3q9EM2p8WQzb2Ce2M9kokCs8ZnhT+fRNc/Q 9lc4RJtEuf3zynvg0cCbf71pgoC0Zepsop466jrvc08MsxxzRJDmjw20ci/3ltk+iAcD3TchYppw yX4HZhjrrZXcOMBMkQIDAQABoykwJzAXBgNVHREEEDAOgQxwbUB3ZWJkbmEudXMwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQCBMxqOGsLwOxtLQ8YLvOQOym8UQyB0CiF0Dpd0oOA+hjD5 n9A1eileTd8OdkdPIb+der2Kw42N/UKARNSSkmn1hhKrgwTNYLyXFNlB+TJ2YvG13B27d4EaUdSn 2KWKDKG4w14lQSO9y+RTjMSuYi4kbeI50QHLZsTZDO3OhNcKjzCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQGa+8CDkvo9yUTyu7Cj+AxjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjgxNTM1NTJaMCMGCSqGSIb3 DQEJBDEWBBS9MutFZVwfcuWDsF1QDpSVYbNwAjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBmvvAg5L6PclE8ruwo/gMYwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC EBmvvAg5L6PclE8ruwo/gMYwDQYJKoZIhvcNAQEBBQAEggEASMN+5S2aHP6BA2BMK7Jhigly9Thw 8SbX/Z+ybBGeBkNqDoHwmwsdLUXCKVItxzQ894ds7DhV74dPR95f6Fycfgz3VgRiBAnn4ILtJSD6 pBPFf65tcnnJ0nfSnZ3LnCQTjIVq52nKMFEmmx1UAt7w7yfvLXu2u4IhJ9z/JwTDQIAqELbLDi80 DuMpzldFcSMw4oN8OJFcYWZgL6y3QY2mDxdY714SzTE+I4a29jz/tikpq+zt+6n8ftZ+MJxku08S gl4ivm8PNTfarCkmIIhOK+f0flZATU8J3c+xUKypsnAYeefQ9Bdth1QsgUR54gbCo3HsB9KQhJQh Ju1g41BoMgAAAAAAAA== --Apple-Mail-39--59666912-- Associated Messages, from the most recent to the oldest:

    
  1. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Stuart Tremain 2012)
  2. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Brian Fries 2012)
  3. Re: [WebDNA] Encode cookies ONLY via "method=Base64" ("Psi Prime Inc, Matthew A Perosi " 2012)
  4. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Govinda 2012)
  5. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Stuart Tremain 2012)
  6. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  7. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  8. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  9. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  10. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  11. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  12. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  13. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  14. Re: [WebDNA] Encode cookies ONLY via "method=Base64" ("Gary Krockover" 2008)
  15. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  16. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  17. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Marc Thompson 2008)
  18. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Bob Minor 2008)
  19. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Brian Fries 2008)
  20. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Marc Thompson 2008)
  21. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Patrick McCormick 2008)
  22. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  23. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Brian Fries 2008)
  24. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Christer Olsson 2008)
  25. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  26. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Donovan Brooke 2008)
  27. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  28. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  29. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  30. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  31. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  32. Re: [WebDNA] Encode cookies ONLY via "method=Base64" ("Psi Prime, Matthew A Perosi " 2008)
  33. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Stuart Tremain 2008)
  34. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Bob Minor 2008)
  35. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  36. RE: [WebDNA] Encode cookies ONLY via "method=Base64" ("Olin Lagon" 2008)
  37. RE: [WebDNA] Encode cookies ONLY via "method=Base64" ("Olin Lagon" 2008)
  38. Re: [WebDNA] Encode cookies ONLY via "method=Base64" ("Psi Prime, Matthew A Perosi " 2008)
  39. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  40. Re: [WebDNA] Encode cookies ONLY via "method=Base64" ("Psi Prime, Matthew A Perosi " 2008)
  41. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  42. Re: [WebDNA] Encode cookies ONLY via "method=Base64" ("Psi Prime, Matthew A Perosi " 2008)
  43. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
  44. Re: [WebDNA] Encode cookies ONLY via "method=Base64" (Stuart Tremain 2008)
  45. [WebDNA] Encode cookies ONLY via "method=Base64" (Kenneth Grome 2008)
--Apple-Mail-39--59666912 Content-Type: multipart/alternative; boundary=Apple-Mail-38--59666966 --Apple-Mail-38--59666966 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Prime numbers only matter for secure file exchanges - not for encrypting a single file. Multiply two large primes together and it takes computers a lot of time to figure out what the factors of this product are. In a secure file exchange, the public key is the product of two large primes and the private key is either of the factors. Then, you encrypt the file with the other factor. Anyone intercepting the file has to figure out what the factors of the product are, and then which one is actually the seed for encryption of the file. I don't think its hard for today's computers to figure out 9 digit primes. In fact, that probably takes a few seconds on a fast machine. If you're depending on the speed of finding the factors as the main security, you need primes with hundreds of digits. These can be found online. And there's actually enough of them that it still takes too long when computers test only known primes. The best security is still common sense. Putting anything sensitive in a cookie is foolish. Putting a sku number in there makes sense. Then, making your data relational and configuring database permissions well makes more hurdles. You reach a point where the cost of the hassle exceed the value of the information. Pat On Oct 27, 2008, at 4:43 AM, Psi Prime, Matthew A Perosi wrote: > wow > That sounds like a lot of overhead. > I bet the algebra would be a lot faster. You would still need your > initial db to hold your custom ascii table though. > > Assuming you were only using 26+10=36 characters, you could create a > custom ascii table using 2 digits for each character. Then lets > assume you have a 10 character username and a 10 character > password. 20 characters total would convert to a string that is 40 > digits long. You could use 3 digits in your ascii table to make it > longer, the numbers don't have to be sequential either. > > Once you have a 40 digit long number you could do something like this > [math]cookiein=([40digits]*533000389)/125[/math] > That number gets sent as the cookie using [setcookie > name=fred&value=[cookiein]] > > Then to decode it you would use [math]cookieout=[getcookie fred][/ > math] > [math]40digits=(125*[cookieout])/533000389[/math] > At this point you could use a [loop] and a [getchars] to parse back > through the 40 digit string and reverse decode through your ascii > table. > > The security here all lies in the prime number. The only way to > decode the username and password would be to know the number. Since > it still takes a supercomputer to actually find prime numbers you > are IMHO not likely to come across a hacker with a supercomputer > that will be wasting his time trying to hack a website. > > Matthew A Perosi JewelerWebsites.com > ------------------------------by Psi Prime------- > Senior Web Developer 323 Union Blvd. > Totowa, NJ 07512 > Pre-Sales: 888.872.0274 > Service: 973.413.8213 > Training: 973.413.8214 > Fax: 973.413.8217 > > http://www.jewelerwebsites.com > http://en.wikipedia.org/wiki/Psi_Prime%2C_Inc > http://www.psiprime.com > > > Kenneth Grome wrote: >> >>> I'm curious what you might be using as a routine to >>> generate that string of 500 random characters. >>> >> I just entered 26 lowercase and 26 uppercase alpha chars and >> 10 digits into a db file, one record for each char, then I >> do a search for all records which gives me 62 total chars >> that can be retrieved, but I limit the search to the first >> 30 chars and I run the search inside a loop that iterates >> 70 times thus giving me a string of 2100 chars. I guess I >> could use other chars in the db but I know that >> alphanumerics won't create problems so I'll probably just >> stick with what I have for now. >> >> Then I create a random number between 1 and 1000 using >> several [random] tags and getchars which limits the >> resulting random number to 3 chars in length, and I use >> this [rn] as the start value with 999+[rn] as the end value >> in another getchars to extract a contiguous segment of the >> 1000 random chars from the original 2100 random char >> string -- so yes I'm using 1000 chars now rather than the >> 500 chars previously mentioned. >> >> Then I use another db with 50 fields and 50 records, each >> field containing one unique value ranging from 1-999. >> These values appear in random order in the columns in the >> db and there are no duplicates in these columns, so that >> when I search this db via rank=off I get 50 non-duplicate >> values ranging from 1-999 in whatever field I choose to >> retrieve. >> >> Next I count the number of characters in the "string to be >> encoded" which consists of the username then a separator >> string then the password all concatenated together. The >> number of chars in this string determines which field of >> values to retrieve from my 50x50 db. Each of the 50 >> retrieved values in the selected field represents a >> character positions in my original 1000 char random >> string ... >> >> I simply take the value from the first (then second, then >> third, etc.) record in the db, find the char position >> corresponding to that value (1-999) in the string of 1000 >> chars, and replace that char with the first (then second, >> then third, etc.) char appearing in my "string to be >> encoded". >> >> When all the chars in my "string to be encoded" have >> replaced the appropriate chars in my 1000 char string I use >> Base64 to further encode the resulting 1000 char string >> which becomes 1/3 longer, and that's the value I set as the >> cookie that identifies whether or not the visitor is valid >> and logged in. >> >> That's as far as I've gotten with it, and I haven't tested >> its speed yet but hopefully it will be 'fast enough'. >> >> :) >> >> Sincerely, >> Ken Grome >> >> >> >> >> >> >> >>> I'm curious what you might be using as a routine to >>> generate that string of 500 random characters. >>> >>> All the random character generators, or random image >>> choosers I've ever written always seem to be weighted >>> toward selecting numbers or images closer to the middle >>> of my field of selection rather than evenly over the >>> entire set of selectable items. I typically use the >>> [random] tag and calculate from there, but in my own >>> testing the number returned from the [random] tag seem to >>> follow a standard statistical bell curve. >>> >>> Whatever random character generator you create make sure >>> it include all possible characters that you would allow >>> within your username and password, and then make sure >>> they show up equally. >>> >>> Thinking about this a little differently you could also >>> convert your usernames and passwords into a number, >>> perhaps using your own version of an ascii table. Then >>> either mod, multiply, divide or otherwise write your own >>> algebraic equation that uses a sufficiently large prime >>> number like 533,000,389 in the calculation. >>> >>> With this procedure you are creating your own encryption >>> algorithm. This is actually the same procedure they use >>> in field of Liner Algebra to create new encryption >>> routines. Governments are always trying to discover the >>> next largest prime number faster than anyone else, >>> because at least for a little while until large primes >>> can be found those types of encryptions are unbreakable. >>> >>> To date there are more than 50 million prime numbers that >>> have been discovered. The higher the prime you select >>> the more difficult your self encryption will be to hack. >>> The most recent prime number was discovered on September >>> 8, 2008 and it had about 12.9 million digits. Can WebDNA >>> even handle a calculation that large? >>> >>> Anyway, using your own equation might be faster in the >>> long run than what you are suggesting. >>> >>> BTW, I did name my company partially after my >>> understanding of Prime Numbers. :-) >>> >>> >>> Matthew A Perosi >>> Psi Prime, Inc. >>> Senior Web Developer 323 Union Blvd. >>> Totowa, NJ 07512 >>> Pre-Sales: 888.872.0274 >>> Service: 973.413.8213 >>> Training: 973.413.8214 >>> Fax: 973.413.8217 >>> >>> http://www.jewelerwebsites.com >>> http://en.wikipedia.org/wiki/Psi_Prime%2C_Inc >>> http://www.psiprime.com >>> >>> Kenneth Grome wrote: >>> >>>>> Try "hiding" the value inside a longer string and then >>>>> use getchars to get the true value. >>>>> >>>> That's my plan at the moment. My current thoughts are >>>> to take this approach: >>>> >>>> Insert each of the user/pass chars into specified >>>> locations within a very long string of random >>>> characters. >>>> >>>> Example, I create a string of 500 random chars, then I >>>> replace the chars that exist in "certain positions" >>>> with my original user/pass chars. For example, if the >>>> user value is "someusername" I will use each of those >>>> 12 chars, one at a time, to replace one char in a >>>> pre-specified position in the string of 500 chars. >>>> Same with the pass value. Then I use Base64 to further >>>> encode it before setting the result as a cookie value. >>>> >>>> So the hacker has a problem: >>>> >>>> First he must realize that the cookie is Base64 encoded >>>> and decode it. Then he will see a string of 500 chars >>>> to further decode, but he doesn't know how many chars >>>> are in the user/pass values, nor does he know which of >>>> the 500 positions those chars occupy. >>>> >>>> I think this should work until WebDNA can handle >>>> encrypted cookies properly. Do any of you see >>>> potential problems with this approach? >>>> >>>> Sincerely, >>>> Ken Grome >>>> >>>> >>>>> Ken >>>>> >>>>> Try "hiding" the value inside a longer string and then >>>>> use getchars to get the true value >>>>> >>>>> I resorted to this technique some time ago when I >>>>> ended up with problems. >>>>> >>>>> Stuart >>>>> >>>>> On 27/10/2008, at 10:02 AM, Kenneth Grome wrote: >>>>> >>>>>>> sometimes a second decrypt and/or unurl >>>>>>> is needed. >>>>>>> >>>>>> A different number of decrypts and encrypts never >>>>>> works, you must always use the same number of these >>>>>> contexts. A different number of urls and unurls is >>>>>> definitely necessary >>>>>> >>>>>> sometimes: >>>>>> >>>>>>> Syntax reminder on variable (straight), and database >>>>>>> encryption: >>>>>>> Straight encryption: same amount of [url]'s going in >>>>>>> as comming out >>>>>>> Database encryption: one more [url] going in >>>>>>> than comming out >>>>>>> >>>>>> Right, thanks for the reminder. >>>>>> >>>>>> With the cookies I first tried the same number of >>>>>> urls and unurls but it was failing, so then I tried >>>>>> using one more url going in -- because I thought that >>>>>> *maybe* using cookies is similar to using a database. >>>>>> But this theory was wrong because an extra url with >>>>>> cookies does not fix the problem like it does with a >>>>>> database. >>>>>> >>>>>> >>>>>>> Could you please tell us what server you're using? >>>>>>> >>>>>> My client's Windows server running WebDNA 6.? >>>>>> >>>>>> >>>>>>> I have found the same thing as Ken has, and that it >>>>>>> is on our list of potential bugs that we are >>>>>>> addressing. The scope appears to be only in cookie >>>>>>> and orderfile interaction so far. >>>>>>> >>>>>> Orderfile too? >>>>>> >>>>>> Thanks Donovan, that's two scopes we should avoid >>>>>> when using the standard WebDNA encryption. Too bad >>>>>> though, since I want to use encrypted cookies for >>>>>> security reasons. >>>>>> >>>>>> >>>>>> PROBABLE CONCLUSION: >>>>>> >>>>>> Although Base64 is an encoding method (not an >>>>>> encryption method) it is the ONLY method that >>>>>> actually works when trying to obfuscate cookie >>>>>> values. >>>>>> >>>>>> Base64 is certainly not secure like an encrypted >>>>>> value might be, but it is better than nothing I >>>>>> guess. I tested all methods using cookies with the >>>>>> following results: >>>>>> >>>>>> standard webdna encryption --> fails 1/4 of the time >>>>>> method=CyberCash --> cannot be decrypted >>>>>> method=APOP --> cannot be decrypted >>>>>> method=Base64 --> 100% reliable in dozens of tests >>>>>> >>>>>> >>>>>> Sincerely, >>>>>> Ken Grome >>>>>> ----------------------------------------------------- >>>>>> -- -- This message is sent to you because you are >>>>>> subscribed to the mailing list . To >>>>>> unsubscribe, E-mail to: >>>>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>>>> >>>>> ------------------------------------------------------ >>>>> --- This message is sent to you because you are >>>>> subscribed to the mailing list . >>>>> To unsubscribe, E-mail to: >>>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>>> >>>> ------------------------------------------------------- >>>> -- This message is sent to you because you are >>>> subscribed to the mailing list . >>>> To unsubscribe, E-mail to: >>>> archives: http://mail.webdna.us/list/talk@webdna.us >>>> old archives: http://dev.webdna.us/TalkListArchive/ >>>> >> >> --------------------------------------------------------- >> This message is sent to you because you are subscribed to >> the mailing list . >> To unsubscribe, E-mail to: >> archives: http://mail.webdna.us/list/talk@webdna.us >> old archives: http://dev.webdna.us/TalkListArchive/ >> >> >> --Apple-Mail-38--59666966 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Prime numbers only matter for = secure file exchanges - not for encrypting a single = file.

Multiply two large primes together and it takes = computers a lot of time to figure out what the factors of this product = are.  In a secure file exchange, the public key is the product of = two large primes and the private key is either of the factors. =  Then, you encrypt the file with the other factor. Anyone = intercepting the file has to figure out what the factors of the product = are, and then which one is actually the seed for encryption of the = file.

I don't think its hard for today's = computers to figure out 9 digit primes. In fact, that probably takes a = few seconds on a fast machine. If you're depending on the speed of = finding the factors as the main security, you need primes with hundreds = of digits.  These can be found online. And there's actually enough = of them that it still takes too long when computers test only known = primes.

The best security is still common = sense.  Putting anything sensitive in a cookie is foolish. Putting = a sku number in there makes sense.  Then, making your data = relational and configuring database permissions well makes more hurdles. = You reach a point where the cost of the hassle exceed the value of the = information.

Pat

On Oct = 27, 2008, at 4:43 AM, Psi Prime, Matthew A Perosi wrote:

wow
That sounds like a lot of = overhead.
I bet the algebra would be a lot faster.  You would = still need your initial db to hold your custom ascii table though.
=
Assuming you were only using 26+10=3D36 characters, you could = create a custom ascii table using 2 digits for each character.  = Then lets assume you have a 10 character username and a 10 character = password.  20 characters total would convert to a string that is 40 = digits long.  You could use 3 digits in your ascii table to make it = longer, the numbers don't have to be sequential either.

Once = you have a 40 digit long number you could do something like this
= [math]cookiein=3D([40digits]*533000389)/125[/math]
That number gets = sent as the cookie using [setcookie name=3Dfred&value=3D[cookiein]]
Then to decode it you would use [math]cookieout=3D[getcookie = fred][/math]
[math]40digits=3D(125*[cookieout])/533000389[/math]
= At this point you could use a [loop] and a [getchars] to parse back = through the 40 digit string and reverse decode through your ascii = table.

The security here all lies in the prime number.  = The only way to decode the username and password would be to know the = number.  Since it still takes a supercomputer to actually find = prime numbers you are IMHO not likely to come across a hacker with a = supercomputer that will be wasting his time trying to hack a = website.

Matthew A =Perosi            JewelerWebsites.com------------------------------by Psi Prime-------Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.com=http://en.wikipedia=.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.com

=
Kenneth Grome wrote:
= 
I'm curious what you might =be using as a routine togenerate that string of 500 random characters.    
I just entered 26 =lowercase and 26 uppercase alpha chars and=2010 digits into a db file, one record for each char, then I=20do a search for all records which gives me 62 total chars=20that can be retrieved, but I limit the search to the first=2030 chars and I run the search inside a loop that iterates=2070 times thus giving me a string of 2100 chars. I guess I=20could use other chars in the db but I know that=20alphanumerics won't create problems so I'll probably just=20stick with what I have for now.Then I create a random number between 1 and 1000 using=20several [random] tags and getchars which limits the=20resulting random number to 3 chars in length, and I use=20this [rn] as the start value with 999+[rn] as the end value=20in another getchars to extract a contiguous segment of the=201000 random chars from the original 2100 random char=20string -- so yes I'm using 1000 chars now rather than the=20500 chars previously mentioned.Then I use another db with 50 fields and 50 records, each=20field containing one unique value ranging from 1-999. =20These values appear in random order in the columns in the=20db and there are no duplicates in these columns, so that=20when I search this db via rank=3Doff I get 50 non-duplicate=20values ranging from 1-999 in whatever field I choose to=20retrieve.Next I count the number of characters in the "string to be=20encoded" which consists of the username then a separator=20string then the password all concatenated together.  The=20number of chars in this string determines which field of=20values to retrieve from my 50x50 db.  Each of the 50=20retrieved values in the selected field represents a=20character positions in my original 1000 char random=20string ... =20I simply take the value from the first (then second, then=20third, etc.) record in the db, find the char position=20corresponding to that value (1-999) in the string of 1000=20chars, and replace that char with the first (then second,=20then third, etc.) char appearing in my "string to be=20encoded". =20When all the chars in my "string to be encoded" have=20replaced the appropriate chars in my 1000 char string I use=20Base64 to further encode the resulting 1000 char string=20which becomes 1/3 longer, and that's the value I set as the=20cookie that identifies whether or not the visitor is valid=20and logged in.That's as far as I've gotten with it, and I haven't tested=20its speed yet but hopefully it will be 'fast enough'.:)Sincerely,Ken Grome  
I'm curious what =you might be using as a routine togenerate that string of 500 random characters.All the random character generators, or random imagechoosers I've ever written always seem to be weightedtoward selecting numbers or images closer to the middleof my field of selection rather than evenly over theentire set of selectable items.  I typically use the[random] tag and calculate from there, but in my owntesting the number returned from the [random] tag seem tofollow a standard statistical bell curve.Whatever random character generator you create make sureit include all possible characters that you would allowwithin your username and password, and then make surethey show up equally.Thinking about this a little differently you could alsoconvert your usernames and passwords into a number,perhaps using your own version of an ascii table.  Theneither mod, multiply, divide or otherwise write your ownalgebraic equation that uses a sufficiently large primenumber like 533,000,389 in the calculation.With this procedure you are creating your own encryptionalgorithm. This is actually the same procedure they usein field of Liner Algebra to create new encryptionroutines.  Governments are always trying to discover thenext largest prime number faster than anyone else,because at least for a little while until large primescan be found those types of encryptions are unbreakable.To date there are more than 50 million prime numbers thathave been discovered.  The higher the prime you selectthe more difficult your self encryption will be to hack.The most recent prime number was discovered on September8, 2008 and it had about 12.9 million digits. Can WebDNAeven handle a calculation that large?Anyway, using your own equation might be faster in thelong run than what you are suggesting.BTW, I did name my company partially after myunderstanding of Prime Numbers.  :-)Matthew A PerosiPsi Prime, Inc.Senior Web Developer             323 Union Blvd.                                 Totowa, NJ 07512Pre-Sales: 888.872.0274Service:   973.413.8213Training:  973.413.8214Fax:       973.413.8217http://www.jewelerwebsites.com=http://en.wikipedia=.org/wiki/Psi_Prime%2C_Inchttp://www.psiprime.comKenneth Grome wrote:
= 
Try "hiding" the value inside a longer string and =thenuse getchars to get the true value.        
That's my plan at =the moment.  My current thoughts areto take this approach:Insert each of the user/pass chars into specifiedlocations within a very long string of randomcharacters.Example, I create a string of 500 random chars, then Ireplace the chars that exist in "certain positions"with my original user/pass chars.  For example, if theuser value is "someusername" I will use each of those12 chars, one at a time, to replace one char in apre-specified position in the string of 500 chars.=20Same with the pass value.  Then I use Base64 to furtherencode it before setting the result as a cookie value.So the hacker has a problem:First he must realize that the cookie is Base64 encodedand decode it.  Then he will see a string of 500 charsto further decode, but he doesn't know how many charsare in the user/pass values, nor does he know which ofthe 500 positions those chars occupy.I think this should work until WebDNA can handleencrypted cookies properly.  Do any of you seepotential problems with this approach?Sincerely,Ken Grome      
KenTry "hiding" the value inside a longer string and thenuse getchars to get the true valueI resorted to this technique some time ago when Iended up with problems.StuartOn 27/10/2008, at 10:02 AM, Kenneth Grome wrote:        
sometimes a second decrypt =and/or unurlis needed.            
A =different number of decrypts and encrypts neverworks, you must always use the same number of thesecontexts.  A different number of urls and unurls isdefinitely necessarysometimes:          
Syntax reminder on variable (straight), and databaseencryption:Straight encryption: same amount of [url]'s going inas comming outDatabase encryption: one more [url] going inthan comming out            
Right, =thanks for the reminder.With the cookies I first tried the same number ofurls and unurls but it was failing, so then I triedusing one more url going in -- because I thought that*maybe* using cookies is similar to using a database. But this theory was wrong because an extra url withcookies does not fix the problem like it does with adatabase.          
Could you please tell us what server you're using?            
My =client's Windows server running WebDNA 6.?          
I have found the same thing as Ken has, and that itis on our list of potential bugs that we areaddressing. The scope appears to be only in cookieand orderfile interaction so far.            
Orderfile too?Thanks Donovan, that's two scopes we should avoidwhen using the standard WebDNA encryption.  Too badthough, since I want to use encrypted cookies forsecurity reasons.PROBABLE CONCLUSION:Although Base64 is an encoding method (not anencryption method) it is the ONLY method thatactually works when trying to obfuscate cookievalues.Base64 is certainly not secure like an encryptedvalue might be, but it is better than nothing Iguess. I tested all methods using cookies with thefollowing results:standard webdna encryption --> fails 1/4 of the timemethod=3DCyberCash --> cannot be decryptedmethod=3DAPOP --> cannot be decryptedmethod=3DBase64 --> 100% reliable in dozens of testsSincerely,Ken Grome------------------------------------------------------- -- This message is sent to you because you aresubscribed to the mailing list <talk@webdna.us>. Tounsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/          
--------------------------------------------------------- This message is sent to you because you aresubscribed to the mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/        
--------------------------------------------------------- This message is sent to you because you aresubscribed to the mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/      
---------------------------------------------------------This message is sent to you because you are subscribed tothe mailing list <talk@webdna.us>.To unsubscribe, E-mail to: <talk-leave@webdna.us>archives: http://mail.webdna.us/l=ist/talk@webdna.usold archives: http://dev.webdna.us/TalkLi=stArchive/
=

= --Apple-Mail-38--59666966-- --Apple-Mail-39--59666912 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGGTCCAtIw ggI7oAMCAQICEBmvvAg5L6PclE8ruwo/gMYwDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyNzAxMTg1M1oXDTA5MDkyNzAxMTg1 M1owPjEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEbMBkGCSqGSIb3DQEJARYMcG1A d2ViZG5hLnVzMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtb7ZYYJV7sbgqxdgpBU/ qCRsIJYGNIo40L9odKmo6Y/mPBybeSry8KefqmuWoBXxc6xCvSSJDWFcb2sZ+TkedZrdxvtoL1pH NjDZNe2ow+RCNUvJcQd1+ASzh0J4QLHnNyoMY3zuCQwqM6hK5gU4AlpOSITekksSFuGXBdJTjSeI gIpZFTTrd1c/Zv7miT9gO5UmHiyDClKP8oX31YFlb3q9EM2p8WQzb2Ce2M9kokCs8ZnhT+fRNc/Q 9lc4RJtEuf3zynvg0cCbf71pgoC0Zepsop466jrvc08MsxxzRJDmjw20ci/3ltk+iAcD3TchYppw yX4HZhjrrZXcOMBMkQIDAQABoykwJzAXBgNVHREEEDAOgQxwbUB3ZWJkbmEudXMwDAYDVR0TAQH/ BAIwADANBgkqhkiG9w0BAQUFAAOBgQCBMxqOGsLwOxtLQ8YLvOQOym8UQyB0CiF0Dpd0oOA+hjD5 n9A1eileTd8OdkdPIb+der2Kw42N/UKARNSSkmn1hhKrgwTNYLyXFNlB+TJ2YvG13B27d4EaUdSn 2KWKDKG4w14lQSO9y+RTjMSuYi4kbeI50QHLZsTZDO3OhNcKjzCCAz8wggKooAMCAQICAQ0wDQYJ KoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNV BAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRp ZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVl bWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0w MzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3 dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1h aWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjA dQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn 8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sC AwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9j cmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjAp BgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFiw9k6 GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpbNU1341Yh eILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxU aGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJl ZW1haWwgSXNzdWluZyBDQQIQGa+8CDkvo9yUTyu7Cj+AxjAJBgUrDgMCGgUAoIIBbzAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODEwMjgxNTM1NTJaMCMGCSqGSIb3 DQEJBDEWBBS9MutFZVwfcuWDsF1QDpSVYbNwAjCBhQYJKwYBBAGCNxAEMXgwdjBiMQswCQYDVQQG EwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhh d3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEBmvvAg5L6PclE8ruwo/gMYwgYcGCyqG SIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcg KFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0EC EBmvvAg5L6PclE8ruwo/gMYwDQYJKoZIhvcNAQEBBQAEggEASMN+5S2aHP6BA2BMK7Jhigly9Thw 8SbX/Z+ybBGeBkNqDoHwmwsdLUXCKVItxzQ894ds7DhV74dPR95f6Fycfgz3VgRiBAnn4ILtJSD6 pBPFf65tcnnJ0nfSnZ3LnCQTjIVq52nKMFEmmx1UAt7w7yfvLXu2u4IhJ9z/JwTDQIAqELbLDi80 DuMpzldFcSMw4oN8OJFcYWZgL6y3QY2mDxdY714SzTE+I4a29jz/tikpq+zt+6n8ftZ+MJxku08S gl4ivm8PNTfarCkmIIhOK+f0flZATU8J3c+xUKypsnAYeefQ9Bdth1QsgUR54gbCo3HsB9KQhJQh Ju1g41BoMgAAAAAAAA== --Apple-Mail-39--59666912-- Patrick McCormick

DOWNLOAD WEBDNA NOW!

Top Articles:

Talk List

The WebDNA community talk-list is the best place to get some help: several hundred extremely proficient programmers with an excellent knowledge of WebDNA and an excellent spirit will deliver all the tips and tricks you can imagine...

Related Readings:

PC Cookie Problem? (2003) syntax question, not in online refernce (1997) Force a search at the default.tmpl page? (1997) Certificates? (2005) WebCat2b13MacPlugIn - More limits on [include] (1997) Emailer Timing out (1999) Laying an egg. (1998) protect tag on NT IIS (1997) [WriteFile] problems (1997) AOL (1999) [WebDNA] error installing 6.2 on ubuntu (2011) Include vs. lookup? (1998) [OT] WebDNA Training (UK) (2003) WebCat2b15MacPlugin - showing [math] (1997) Any problem with using a g4 with WebCat (2000) GuestBook example (1997) BUG in [showif] using ^ (contains) (1997) $Append for Users outside the ADMIN group (1997) WebCat2: Items xx to xx shown, etc. (1997) Serving .wml pages to WAP via webcat (2000)