Re: [WebDNA] Encode cookies ONLY via "method=Base64"
This WebDNA talk-list message is from 2008
It keeps the original formatting.
numero = 101267
interpreted = N
texte = This is a multi-part message in MIME format. --------------030204000807020506090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/ > > > --------------030204000807020506090400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 <talk@webdna.us>. To unsubscribe, E-mail to: <talk-leave@webdna.us> 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 <talk@webdna.us>. To unsubscribe, E-mail to: <talk-leave@webdna.us> 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 <talk@webdna.us>. To unsubscribe, E-mail to: <talk-leave@webdna.us> archives: http://mail.webdna.us/list/talk@webdna.us old archives: http://dev.webdna.us/TalkListArchive/
--------------030204000807020506090400--
Associated Messages, from the most recent to the oldest:
This is a multi-part message in MIME format. --------------030204000807020506090400 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/ > > > --------------030204000807020506090400 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 <talk@webdna.us>. To unsubscribe, E-mail to: <talk-leave@webdna.us> 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 <talk@webdna.us>. To unsubscribe, E-mail to: <talk-leave@webdna.us> 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 <talk@webdna.us>. To unsubscribe, E-mail to: <talk-leave@webdna.us> archives: http://mail.webdna.us/list/talk@webdna.us old archives: http://dev.webdna.us/TalkListArchive/
--------------030204000807020506090400--
"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:
creating a ShipCosts database (1997)
2nd WebCatalog2 Feature Request (1996)
japanese characters (1997)
New syntax feedback for 4.0 (2000)
Access Denied! But why? (1997)
File perms (2002)
WebCat2 as a chat server? (1997)
# fields limited? (1997)
Setting up shop (1997)
[WebDNA] Connect to MS SQL (2013)
security problem (1997)
WebCat2 - Getting to the browser's username/password data (1997)
syntax question, not in online refernce (1997)
Great product and great job ! (1997)
Calendar (1997)
need help with textA field (1998)
POP Mail Server Reseting (1998)
PCS Frames (1997)
Searchable list archive (1997)
different show next (1997)