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

This WebDNA talk-list message is from

2008


It keeps the original formatting.
numero = 101270
interpreted = N
texte = This is a multi-part message in MIME format. --------------080009000708030901030507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/ > > > --------------080009000708030901030507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable wow
That sounds like a lot of overhead.
I bet the algebra would be a lot faster.=C2=A0 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.=C2=A0 Then lets ass= ume you have a 10 character username and a 10 character password.=C2=A0 20 characters total would convert to a string that is 40 digits long.=C2=A0 = 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.<= br>
The security here all lies in the prime number.=C2=A0 The only way to dec= ode the username and password would be to know the number.=C2=A0 Since it sti= ll 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            Jewe=lerWebsites.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.comhttp://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.comhttp://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 a=reto 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 neve=rworks, you must always use the same number of thesecontexts.  A different number of urls and unurls isdefinitely necessarysometimes:          
Syntax reminder on variable (straight), and da=tabaseencryption: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 us=ing?            
My client's Windows server running WebDNA 6.?          
I have found the same thing as Ken has, and th=at 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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/          
--------------------------------------------------=------- 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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/        
----------------------------------------------------=----- 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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/      
---------------------------------------------------------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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/
--------------080009000708030901030507-- 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)
This is a multi-part message in MIME format. --------------080009000708030901030507 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/ > > > --------------080009000708030901030507 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable wow
That sounds like a lot of overhead.
I bet the algebra would be a lot faster.=C2=A0 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.=C2=A0 Then lets ass= ume you have a 10 character username and a 10 character password.=C2=A0 20 characters total would convert to a string that is 40 digits long.=C2=A0 = 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.<= br>
The security here all lies in the prime number.=C2=A0 The only way to dec= ode the username and password would be to know the number.=C2=A0 Since it sti= ll 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            Jewe=lerWebsites.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.comhttp://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.comhttp://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 a=reto 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 neve=rworks, you must always use the same number of thesecontexts.  A different number of urls and unurls isdefinitely necessarysometimes:          
Syntax reminder on variable (straight), and da=tabaseencryption: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 us=ing?            
My client's Windows server running WebDNA 6.?          
I have found the same thing as Ken has, and th=at 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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/          
--------------------------------------------------=------- 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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/        
----------------------------------------------------=----- 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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/      
---------------------------------------------------------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/list/talk@webdna.usold archives: http://dev.webdna.us/TalkListArchive/
--------------080009000708030901030507-- "Psi Prime, Matthew A Perosi "

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:

Need relative path explanation (1997) Repeating Fields (1997) MASTER_STORE revision (2002) OUTSIDE LINKS TO SHOW SHOPPING CART????????? (1998) test (2001) Admin Edit prob. (1997) Question on TABLES (2003) Re:no template caching (1997) WebCat2b15MacPlugin - [protect] (1997) PIXO support (1997) When do we get to request new features? (1999) help (2001) syntax question, not in online refernce (1997) Passing Cart variable to subdirectory files? (1997) Cart Question (1998) Truncated value after space - refresh my memory.... (1997) RE: Answer: WebDelivery downloads alias, not original ? (1997) Ampersand Character (&) (1997) math on date? (1997) SetHeader (1997)