Re: [WebDNA] Encode cookies ONLY via "method=Base64"
This WebDNA talk-list message is from 2008
It keeps the original formatting.
numero = 101269
interpreted = N
texte = > 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/
Associated Messages, from the most recent to the oldest:
> 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/
Kenneth Grome
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:
Linux problems (2000)
[WebDNA] SpeedTest (2009)
fieldType=num (1997)
Any one heard from SM since that last email? (2006)
Banner Ad & Index.shtml (2000)
Re[2]: 2nd WebCatalog2 Feature Request (1996)
Notepad problems (1998)
Separate server for jpg/gif files (1998)
Pithy questions on webcommerce & siteedit (1997)
WebCat2b12 Mac.acgi--[searchstring] bug (1997)
Bug Report, maybe (1997)
[OT] Industry news from Australia (2000)
price carry over (1997)
SHOWNEXT (1999)
Web Catalog not encrypting/decrypting problem (1998)
Why is [authenticate] not recognizing [username] on all sitedirectories? (2000)
Document Contains No Data! (1997)
Using Plug-In while running 1.6.1 (1997)
Using copyfolder (2001)
RE: protect tag on NT (1997)