RE: pseudo-memory leak
I tried to crack this hash and failed. However, my rainbow tables are limited. I only have lowercase alphanumeric up to 14 characters. (Which is probably about the limit that the md5 rainbow tables support at this time). This means that strong passwords (even ones with uppercase letters) are not crackable using this method, but any password up to 14 characters in length consisting of lowercase alphanumeric characters can be cracked pretty easily. And my guess is that over 90% of your user's passwords would fall into this category (unless you've set up a strong password policy). If you want to test it, give me another string of lowercase alpha numeric characters up to 14 characters in length, and see how long it takes me to crack it. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:52 PM To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226958 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Interesting topic.
We gave up using client variables a while back when they started severely
impacting performance under load. It's incredibly important to avoid client
variables on systems under load. When we switched from client vars to a cookie
(hashed user ID password combo) and used sessions exclusively, the site
performance improved significantly.
The problem you outline seems to be a problem for session variables too. Using
the runtime.SessionTracker, CFMX reports that there are currently 3900 open
sessions (20 min timeout) on our server. Probably about 1/3 to 1/2 of them are
either users who dont have cookies turned on (and therefore create a new
session each page), or are bots. It's unclear how much of a performance hit
this needless creation and destruction of sessions causes, but it certainly
isn't optimal.
Thanks for the cfapplication switching idea. I'll give it a shot and see if
the number of active sessions drops.
I'd be interested in hearing if anyone has any ideas about stopping sessions
from cookieless people from being created (that cant be identified as being
bots) in the first place. I've got a feeling there is no solution for this one
though.
Regards,
Terry
Sorry, meant to post the whole thing. :)
For the last few weeks I've been having some problems with House of
Fusion. The memory for the JRun.exe has been going through the roof
and I didn't know why. The code was tight, nothing had really changed
on the site, so what was up? The answer was Yahoo.
In the last 3 weeks Yahoo has ramped up their indexing of sites. For a
site as large as House of Fusion, this can take quite a bit of time.
I've logged 2-4 yahoo bot hits per second at some times.
So how was yahoo the problem? Because of client variables. Not DB
client variables and not even the dreaded registry client variables.
Just simple cookie based client variables. It seems that when a client
variable is set, a memory structure is also set for CF. Now each bot
hit is assumed to be it's own session as it does not accept cookies.
This mean each bot hit generates a memory structure of about 1k. Now
this is not really a lot, but when you have a few 10's of thousands of
hits from bots a day, it adds up.
I'm still waiting on word from Macromedia as to when a client memory
structure times out, but this seems to be the issue.
So what's the solution? There are 4.
1. Increase your ram. If you can do this, then ramp up your memory as
high as you can. This is not a perfect solution but it saves throwing
time at the problem and gives you a 'buffer' against problems of this
sort.
2. Set a robots.txt with a Crawl-delay setting. Mine is set to 1
second but you can set yours to something higher
3. set a different cfapplication for the most common bots. I use a
simple regular expression to find key words that only exist in bots:
CFIF
REFindNoCase('Slurp|Goo
glebot|BecomeBot|msnbot|Mediapartners-Google|ZyBorg|RufusBot|EMonitor',
cgi.http_user_agent)
CFAPPLICATION name=FusionA clientmanagement=no
sessionmanagement=no setclientcookies=no setdomaincookies=no
clientstorage=Cookie
CFELSE
CFAPPLICATION name=FusionA clientmanagement=yes
sessionmanagement=no setclientcookies=yes setdomaincookies=no
clientstorage=Cookie
/CFIF
This will make sure that a client structure is NOT created for one of
these bots.
4. Use the same regex to clean out the client structure after the bot
finishes the page. Use structclear(client) to remove the data in the
onRequestEnd.cfm, the onRequestEnd method of the application.cfc or in
the template itself.
Bottom line is that while bots are great for indexing your content,
they can cause havoc on your system when a lot of memory is assigned
to what is essentially a 'dead session'.
http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226457
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Just tried your approach (sessionmanagement=no for bots) but every bot that
hits a page that references a session variable (even in a check) then throws an
error:
Before session variables can be used, the session state management system must
be enabled using the CFAPPLICATION tag.
Any idea on how to get around this error so that the bots can see content? It
would be nice to at least allow the bots to index something other than an error
message :)
Terry
Interesting topic.
We gave up using client variables a while back when they started
severely impacting performance under load. It's incredibly important
to avoid client variables on systems under load. When we switched
from client vars to a cookie (hashed user ID password combo) and
used sessions exclusively, the site performance improved significantly.
The problem you outline seems to be a problem for session variables
too. Using the runtime.SessionTracker, CFMX reports that there are
currently 3900 open sessions (20 min timeout) on our server. Probably
about 1/3 to 1/2 of them are either users who dont have cookies turned
on (and therefore create a new session each page), or are bots. It's
unclear how much of a performance hit this needless creation and
destruction of sessions causes, but it certainly isn't optimal.
Thanks for the cfapplication switching idea. I'll give it a shot and
see if the number of active sessions drops.
I'd be interested in hearing if anyone has any ideas about stopping
sessions from cookieless people from being created (that cant be
identified as being bots) in the first place. I've got a feeling
there is no solution for this one though.
Regards,
Terry
Sorry, meant to post the whole thing. :)
For the last few weeks I've been having some problems with House of
Fusion. The memory for the JRun.exe has been going through the roof
and I didn't know why. The code was tight, nothing had really
changed
on the site, so what was up? The answer was Yahoo.
In the last 3 weeks Yahoo has ramped up their indexing of sites. For
a
site as large as House of Fusion, this can take quite a bit of time.
I've logged 2-4 yahoo bot hits per second at some times.
So how was yahoo the problem? Because of client variables. Not DB
client variables and not even the dreaded registry client variables.
Just simple cookie based client variables. It seems that when a
client
variable is set, a memory structure is also set for CF. Now each bot
hit is assumed to be it's own session as it does not accept cookies.
This mean each bot hit generates a memory structure of about 1k. Now
this is not really a lot, but when you have a few 10's of thousands
of
hits from bots a day, it adds up.
I'm still waiting on word from Macromedia as to when a client memory
structure times out, but this seems to be the issue.
So what's the solution? There are 4.
1. Increase your ram. If you can do this, then ramp up your memory
as
high as you can. This is not a perfect solution but it saves
throwing
time at the problem and gives you a 'buffer' against problems of
this
sort.
2. Set a robots.txt with a Crawl-delay setting. Mine is set to 1
second but you can set yours to something higher
3. set a different cfapplication for the most common bots. I use a
simple regular expression to find key words that only exist in
bots:
CFIF
REFindNoCase('Slurp|Goo
glebot|BecomeBot|msnbot|Mediapartners-Google|ZyBorg|RufusBot|EMonitor',
cgi.http_user_agent)
CFAPPLICATION name=FusionA clientmanagement=no
sessionmanagement=no setclientcookies=no setdomaincookies=no
clientstorage=Cookie
CFELSE
CFAPPLICATION name=FusionA clientmanagement=yes
sessionmanagement=no setclientcookies=yes setdomaincookies=no
clientstorage=Cookie
/CFIF
This will make sure that a client structure is NOT created for one
of
these bots.
4. Use the same regex to clean out the client structure after the
bot
finishes the page. Use structclear(client) to remove the data in the
onRequestEnd.cfm, the onRequestEnd method of the application.cfc or
in
the template itself.
Bottom line is that while bots are great for indexing your content,
they can cause havoc on your system when a lot of memory is assigned
to what is essentially a 'dead session'.
http://www.blogoffusion.com/index.
cfm/2005/11/28/pseudomemory-leak
~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble
Ticket application
http://www.houseoffusion.com/banners/view.cfm?bannerid=48
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226462
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
Re: pseudo-memory leak
Add in checker code to see if a session exists before using the session var.
IsDefined('session')
Just tried your approach (sessionmanagement=no for bots) but every bot
that hits a page that references a session variable (even in a check) then
throws an error:
Before session variables can be used, the session state management system
must be enabled using the CFAPPLICATION tag.
Any idea on how to get around this error so that the bots can see content?
It would be nice to at least allow the bots to index something other than
an error message :)
Terry
Interesting topic.
We gave up using client variables a while back when they started
severely impacting performance under load. It's incredibly important
to avoid client variables on systems under load. When we switched
from client vars to a cookie (hashed user ID password combo) and
used sessions exclusively, the site performance improved significantly.
The problem you outline seems to be a problem for session variables
too. Using the runtime.SessionTracker, CFMX reports that there are
currently 3900 open sessions (20 min timeout) on our server. Probably
about 1/3 to 1/2 of them are either users who dont have cookies turned
on (and therefore create a new session each page), or are bots. It's
unclear how much of a performance hit this needless creation and
destruction of sessions causes, but it certainly isn't optimal.
Thanks for the cfapplication switching idea. I'll give it a shot and
see if the number of active sessions drops.
I'd be interested in hearing if anyone has any ideas about stopping
sessions from cookieless people from being created (that cant be
identified as being bots) in the first place. I've got a feeling
there is no solution for this one though.
Regards,
Terry
Sorry, meant to post the whole thing. :)
For the last few weeks I've been having some problems with House of
Fusion. The memory for the JRun.exe has been going through the roof
and I didn't know why. The code was tight, nothing had really
changed
on the site, so what was up? The answer was Yahoo.
In the last 3 weeks Yahoo has ramped up their indexing of sites. For
a
site as large as House of Fusion, this can take quite a bit of time.
I've logged 2-4 yahoo bot hits per second at some times.
So how was yahoo the problem? Because of client variables. Not DB
client variables and not even the dreaded registry client variables.
Just simple cookie based client variables. It seems that when a
client
variable is set, a memory structure is also set for CF. Now each bot
hit is assumed to be it's own session as it does not accept cookies.
This mean each bot hit generates a memory structure of about 1k. Now
this is not really a lot, but when you have a few 10's of thousands
of
hits from bots a day, it adds up.
I'm still waiting on word from Macromedia as to when a client memory
structure times out, but this seems to be the issue.
So what's the solution? There are 4.
1. Increase your ram. If you can do this, then ramp up your memory
as
high as you can. This is not a perfect solution but it saves
throwing
time at the problem and gives you a 'buffer' against problems of
this
sort.
2. Set a robots.txt with a Crawl-delay setting. Mine is set to 1
second but you can set yours to something higher
3. set a different cfapplication for the most common bots. I use a
simple regular expression to find key words that only exist in
bots:
CFIF
REFindNoCase('Slurp|Goo
glebot|BecomeBot|msnbot|Mediapartners-Google|ZyBorg|RufusBot|EMonitor',
cgi.http_user_agent)
CFAPPLICATION name=FusionA clientmanagement=no
sessionmanagement=no setclientcookies=no setdomaincookies=no
clientstorage=Cookie
CFELSE
CFAPPLICATION name=FusionA clientmanagement=yes
sessionmanagement=no setclientcookies=yes setdomaincookies=no
clientstorage=Cookie
/CFIF
This will make sure that a client structure is NOT created for one
of
these bots.
4. Use the same regex to clean out the client structure after the
bot
finishes the page. Use structclear(client) to remove the data in the
onRequestEnd.cfm, the onRequestEnd method of the application.cfc or
in
the template itself.
Bottom line is that while bots are great for indexing your content,
they can cause havoc on your system when a lot of memory is assigned
to what is essentially a 'dead session'.
http://www.blogoffusion.com/index.
cfm/2005/11/28/pseudomemory-leak
~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226464
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
Re: pseudo-memory leak
Nope, still doesn't work. Even though the session.pid test is never reached,
the error is still thrown. Try the following code:
CFAPPLICATION name=bot_version sessionmanagement=no clientmanagement=no
cfif isdefined(session)
cfif isdefined(session.userid)
An error is thrown by the above statement each time
/cfif
/cfif
Add in checker code to see if a session exists before using the session var.
IsDefined('session')
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226469
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
ugh, you have sessionmanagement=no
DK
On 12/7/05, Terry Ford [EMAIL PROTECTED] wrote:
Nope, still doesn't work. Even though the session.pid test is never
reached, the error is still thrown. Try the following code:
CFAPPLICATION name=bot_version sessionmanagement=no
clientmanagement=no
cfif isdefined(session)
cfif isdefined(session.userid)
An error is thrown by the above statement each time
/cfif
/cfif
Add in checker code to see if a session exists before using the session var.
IsDefined('session')
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226471
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Correct, that's what I'm trying to do -- disable session management entirely for bots so that thousands of sessions dont get needlessly created and destroyed every 15 minutes. Just to put this in perspective as to why I'm experimenting with this, Google has over 500,000 pages from my site indexed. Add in Google Adwords on a large number of those pages, and Google is literally hammering the site 24 hrs a day. This is great for driving traffic, but the overhead of maintaining state for each one of these bot requests seems wasteful to me. The problem is that as soon as you disable session management, all pages that reference session variables (even inside of scope existence checks) throw errors. So it doesn't look like there's a way to me of disabling session management for certain cgi.http_user_agents, yet having it enabled for non-bots. ugh, you have sessionmanagement=no DK On 12/7/05, Terry Ford [EMAIL PROTECTED] wrote: ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226473 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Terry, Session management is set at the application level. It's not different for each visitor - it is the same for all pages governed by the application.cfm page. Try this approach. Cfif cgi.http_user_agent IS some list of bots... cfapplication name=botApplication sessionmanagement=no cfelse cfapplication name=RegularUserApplication sessionmanagement=yes /cfif this code will in effect create 2 applications - botApplication and regularuserapplication - one with mangement ON and one with mangement OFF. -Mark -Original Message- From: Terry Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 12:57 PM To: CF-Talk Subject: Re: pseudo-memory leak Correct, that's what I'm trying to do -- disable session management entirely for bots so that thousands of sessions dont get needlessly created and destroyed every 15 minutes. Just to put this in perspective as to why I'm experimenting with this, Google has over 500,000 pages from my site indexed. Add in Google Adwords on a large number of those pages, and Google is literally hammering the site 24 hrs a day. This is great for driving traffic, but the overhead of maintaining state for each one of these bot requests seems wasteful to me. The problem is that as soon as you disable session management, all pages that reference session variables (even inside of scope existence checks) throw errors. So it doesn't look like there's a way to me of disabling session management for certain cgi.http_user_agents, yet having it enabled for non-bots. ugh, you have sessionmanagement=no DK On 12/7/05, Terry Ford [EMAIL PROTECTED] wrote: ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226485 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Regarding my application name approach - you could then try the following in botapplication session = structnew(); session.user = 0 session.id = 0 . etc It would actually be variables.session - but it would allow your code to work (assuming you can come up with defaults for all your session vars.) ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226486 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Hi Mark, Yes, that is understood and is precisely what I'm doing. The issue is that any user of botApplication who hits any template containing a reference to a session variable (*even if protected within isdefined() checks*) will receive an error. At least that is the behavior with CFMX 6.1. Regards, Terry Terry, Session management is set at the application level. It's not different for each visitor - it is the same for all pages governed by the application.cfm page. Try this approach. Cfif cgi.http_user_agent IS some list of bots... cfapplication name=botApplication sessionmanagement=no cfelse cfapplication name=RegularUserApplication sessionmanagement=yes /cfif this code will in effect create 2 applications - botApplication and regularuserapplication - one with mangement ON and one with mangement OFF. -Mark -Original Message- From: Terry Ford [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 07, 2005 12:57 PM To: CF-Talk Subject: Re: pseudo-memory leak Correct, that's what I'm trying to do -- disable session management entirely for bots so that thousands of sessions dont get needlessly created and destroyed every 15 minutes. Just to put this in perspective as to why I'm experimenting with this, Google has over 500,000 pages from my site indexed. Add in Google Adwords on a large number of those pages, and Google is literally hammering the site 24 hrs a day. This is great for driving traffic, but the overhead of maintaining state for each one of these bot requests seems wasteful to me. The problem is that as soon as you disable session management, all pages that reference session variables (even inside of scope existence checks) throw errors. So it doesn't look like there's a way to me of disabling session management for certain cgi.http_user_agents, yet having it enabled for non-bots. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226488 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
More info
You can't do this - at least not this way You can referenced something
named session in the variables scope (variables.session.blah), but when
you try to use the order of precedence in your favor to evaluate (cfdump
var=#session#) you get an empty structure...
Of course you could setup the session and copy it to another scope with
each request.. using it for storage only... in that case you would end up
with something like this.
Cfif isDefined('url.botAp')
cfapplication name=botApplication sessionmanagement=no
clientmanagement=Yes
cfset localcopyofsession .color1 = 'blue'
cfset localcopyofsession .color2 = 'blue'
cfelse
cfapplication name=RegularUserApplication sessionmanagement=yes
cfif structKeyExists(session,'user')
cfset variables.localcopyofsession = session (or
structcopy or
duplicate)
cfelse
cfset session.color1 = 'blue'
cfset session.color2 = 'blue'
cfset variables.localcopyofsession = session
/cfif
/cfif
Then, everywhere you currently use session you would use
localcopyofsession.
This would cause the bots to all share the same session values
-Mark
-Original Message-
From: Mark A Kruger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 3:22 PM
To: CF-Talk
Subject: RE: pseudo-memory leak
Regarding my application name approach - you could then try the following
in botapplication
session = structnew();
session.user = 0
session.id = 0
.. etc
It would actually be variables.session - but it would allow your code to
work (assuming you can come up with defaults for all your session vars.)
~|
Discover CFTicket - The leading ColdFusion Help Desk and Trouble
Ticket application
http://www.houseoffusion.com/banners/view.cfm?bannerid=48
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226489
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Well if you're going to go to all the trouble (and performance hit) of building
your own session scope and copying structs and stuff, you might as well just
wave the white flag and let the bots use session management ;)
Terry
More info
You can't do this - at least not this way You can referenced something
named session in the variables scope (variables.session.blah), but when
you try to use the order of precedence in your favor to evaluate (cfdump
var=#session#) you get an empty structure...
Of course you could setup the session and copy it to another scope with
each request.. using it for storage only... in that case you would end up
with something like this.
Cfif isDefined('url.botAp')
cfapplication name=botApplication sessionmanagement=no
clientmanagement=Yes
cfset localcopyofsession .color1 = 'blue'
cfset localcopyofsession .color2 = 'blue'
cfelse
cfapplication name=RegularUserApplication sessionmanagement=yes
cfif structKeyExists(session,'user')
cfset variables.localcopyofsession = session (or
structcopy or
duplicate)
cfelse
cfset session.color1 = 'blue'
cfset session.color2 = 'blue'
cfset variables.localcopyofsession = session
/cfif
/cfif
Then, everywhere you currently use session you would use
localcopyofsession.
This would cause the bots to all share the same session values
-Mark
-Original Message-
From: Mark A Kruger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 3:22 PM
To: CF-Talk
Subject: RE: pseudo-memory leak
Regarding my application name approach - you could then try the following
in botapplication
session = structnew();
session.user = 0
session.id = 0
. etc
It would actually be variables.session - but it would allow your code to
work (assuming you can come up with defaults for all your session vars.)
~|
Find out how CFTicket can increase your company's customer support
efficiency by 100%
http://www.houseoffusion.com/banners/view.cfm?bannerid=49
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226491
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Hey.. you started it (lol)
-Original Message-
From: Terry Ford [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 2:45 PM
To: CF-Talk
Subject: Re: pseudo-memory leak
Well if you're going to go to all the trouble (and performance hit) of
building your own session scope and copying structs and stuff, you might as
well just wave the white flag and let the bots use session management ;)
Terry
More info
You can't do this - at least not this way You can referenced something
named session in the variables scope (variables.session.blah), but when
you try to use the order of precedence in your favor to evaluate (cfdump
var=#session#) you get an empty structure...
Of course you could setup the session and copy it to another scope with
each request.. using it for storage only... in that case you would end up
with something like this.
Cfif isDefined('url.botAp')
cfapplication name=botApplication sessionmanagement=no
clientmanagement=Yes
cfset localcopyofsession .color1 = 'blue'
cfset localcopyofsession .color2 = 'blue'
cfelse
cfapplication name=RegularUserApplication sessionmanagement=yes
cfif structKeyExists(session,'user')
cfset variables.localcopyofsession = session (or
structcopy or
duplicate)
cfelse
cfset session.color1 = 'blue'
cfset session.color2 = 'blue'
cfset variables.localcopyofsession = session
/cfif
/cfif
Then, everywhere you currently use session you would use
localcopyofsession.
This would cause the bots to all share the same session values
-Mark
-Original Message-
From: Mark A Kruger [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 07, 2005 3:22 PM
To: CF-Talk
Subject: RE: pseudo-memory leak
Regarding my application name approach - you could then try the following
in botapplication
session = structnew();
session.user = 0
session.id = 0
. etc
It would actually be variables.session - but it would allow your code to
work (assuming you can come up with defaults for all your session vars.)
~|
Logware (www.logware.us): a new and convenient web-based time tracking
application. Start tracking and documenting hours spent on a project or with a
client with Logware today. Try it for free with a 15 day trial account.
http://www.houseoffusion.com/banners/view.cfm?bannerid=67
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:226494
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225680 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Well turns out that CF uses MD5, which is a little different then LM hashes used for windows passwords. I just need to get (or generate) the Rainbow tables first, and then it should be a piece of cake. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 9:31 AM To: CF-Talk Subject: RE: pseudo-memory leak Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225693 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Clocks ticking. ;-) -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 30 November 2005 16:22 To: CF-Talk Subject: RE: pseudo-memory leak Well turns out that CF uses MD5, which is a little different then LM hashes used for windows passwords. I just need to get (or generate) the Rainbow tables first, and then it should be a piece of cake. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 9:31 AM To: CF-Talk Subject: RE: pseudo-memory leak Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant, Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions. Visit our website at http://www.reedexpo.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225695 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Well turns out that CF uses MD5, which is a little different then LM hashes used for windows passwords. I just need to get (or generate) the Rainbow tables first, and then it should be a piece of cake. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 9:31 AM To: CF-Talk Subject: RE: pseudo-memory leak Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225696 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
I believe CF7+ is extensible when it comes to encryption - MD5 and others are now available? Will need to check my CFWACK Advanced to be sure though. Peter Tilbrook ColdGen Internet Solutions Manager, ACT and Region ColdFusion Users Group PO Box 2247 Queanbeyan, NSW, 2620 AUSTRALIA Phone: (02) 6284 2727 Mobile: 0432 897 437 Email: [EMAIL PROTECTED] WWW: http://www.coldgen.com/ http://www.actcfug.com -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: Thursday, 1 December 2005 2:22 AM To: CF-Talk Subject: RE: pseudo-memory leak Well turns out that CF uses MD5, which is a little different then LM hashes used for windows passwords. I just need to get (or generate) the Rainbow tables first, and then it should be a piece of cake. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 9:31 AM To: CF-Talk Subject: RE: pseudo-memory leak Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225697 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
CF also uses non-Microsoft UUID's but maybe there is a UDF at CFLib.org that, just like UUID's, can be used? I've found many UDF's that were designed for CF5 work with CFMX 7. Funny thing also is that many of the UDF's made for CF5 are now actually integrated into MX7. Dang those UDF authors! -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Thursday, 1 December 2005 2:09 AM To: CF-Talk Subject: RE: pseudo-memory leak Clocks ticking. ;-) -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 30 November 2005 16:22 To: CF-Talk Subject: RE: pseudo-memory leak Well turns out that CF uses MD5, which is a little different then LM hashes used for windows passwords. I just need to get (or generate) the Rainbow tables first, and then it should be a piece of cake. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 9:31 AM To: CF-Talk Subject: RE: pseudo-memory leak Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant, Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions. Visit our website at http://www.reedexpo.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225698 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
are you saying if it takes 2 weeks to hack a website, its less hacked than if it takes 2 hours? :P -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: 30 November 2005 16:09 To: CF-Talk Subject: RE: pseudo-memory leak Clocks ticking. ;-) -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 30 November 2005 16:22 To: CF-Talk Subject: RE: pseudo-memory leak Well turns out that CF uses MD5, which is a little different then LM hashes used for windows passwords. I just need to get (or generate) the Rainbow tables first, and then it should be a piece of cake. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 9:31 AM To: CF-Talk Subject: RE: pseudo-memory leak Seems like it is taking him a while ;-) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 21:52 To: CF-Talk Subject: Re: pseudo-memory leak Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant, Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions. Visit our website at http://www.reedexpo.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225700 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
-Original Message- From: Kerry [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 30, 2005 11:35 AM To: CF-Talk Subject: RE: pseudo-memory leak are you saying if it takes 2 weeks to hack a website, its less hacked than if it takes 2 hours? :P Well... sorta. ;^) In this case (from what I've gleaned) you're not hacking the website you're hacking a single user of the website. It's still a breach but a much, much less severe breach. All password-based systems can eventually be cracked, ALL of them. The idea is just to make it difficult enough not to be worth the bother and take long enough to were suggested (or forced) regular password changes would invalidate the results. Jim Davis ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225707 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225507 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
That's really just security by obscurity. If you hash the data, and I know that you've hashed the data, I can set the data that I want and hash that as well.. Your program wouldn't really know the difference. Lets say you were hashing userID's. I would really just need to know the valid range of userID's (Lets say 1 to 10), and then I can hash each one of those using the same exact hash function you're using (Coldfusion), and set my own cookie. Then try accessing your site with it. That's a pretty simple brute force, wouldn't you say? Much easier then trying to guess the password. -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:43 AM To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225544 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
You would still use a hashed password that you wouldnt be able to guess, plus you could also seed the userid before the hash. or like I said before, use a uuid for the userid. You wouldnt be guessing either one. On 11/29/05, Russ [EMAIL PROTECTED] wrote: That's really just security by obscurity. If you hash the data, and I know that you've hashed the data, I can set the data that I want and hash that as well.. Your program wouldn't really know the difference. Lets say you were hashing userID's. I would really just need to know the valid range of userID's (Lets say 1 to 10), and then I can hash each one of those using the same exact hash function you're using (Coldfusion), and set my own cookie. Then try accessing your site with it. That's a pretty simple brute force, wouldn't you say? Much easier then trying to guess the password. -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:43 AM To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225549 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
The point is you have to jump through hoops to make cookies secure... Why not just have a best practice not to store stuff in cookies, and to use client variables instead, so that people not well versed in security can build more secure sites then they would otherwise? -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 10:35 AM To: CF-Talk Subject: Re: pseudo-memory leak You would still use a hashed password that you wouldnt be able to guess, plus you could also seed the userid before the hash. or like I said before, use a uuid for the userid. You wouldnt be guessing either one. On 11/29/05, Russ [EMAIL PROTECTED] wrote: That's really just security by obscurity. If you hash the data, and I know that you've hashed the data, I can set the data that I want and hash that as well.. Your program wouldn't really know the difference. Lets say you were hashing userID's. I would really just need to know the valid range of userID's (Lets say 1 to 10), and then I can hash each one of those using the same exact hash function you're using (Coldfusion), and set my own cookie. Then try accessing your site with it. That's a pretty simple brute force, wouldn't you say? Much easier then trying to guess the password. -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:43 AM To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225582 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
The point is you have to jump through hoops to make cookies secure... Why not just have a best practice not to store stuff in cookies, and to use client variables instead, so that people not well versed in security can build more secure sites then they would otherwise? -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 10:35 AM To: CF-Talk Subject: Re: pseudo-memory leak You would still use a hashed password that you wouldnt be able to guess, plus you could also seed the userid before the hash. or like I said before, use a uuid for the userid. You wouldnt be guessing either one. ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225586 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 09:43 To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225590 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Yea, I mentioned that before in the thread. Theoretically, hashing should be 1 way (so there is no way to turn the hash back into the value). But you could run a bruteforce against a hash, and be able to figure out what the hashed value really is. You can also build a table of all possible hashes, and then it just becomes a linear search. (I know someone who's got the complete rainbow tables for windows passwords, and is able to find any password within a few hours, I believe, if he's got the hash). -Original Message- From: Kerry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 1:14 PM To: CF-Talk Subject: RE: pseudo-memory leak FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 09:43 To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225594 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
-Original Message- From: Kerry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 1:14 PM To: CF-Talk Subject: RE: pseudo-memory leak FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... Actually it does - mostly because hashes aren't unique to the value. You might have been lucky and extracted the same value, but MANY values would end up with the same hash value. So in a security sense the point is not to find the original value but to find ANY value which results in the same hash. This kind of thing is also why a lot of people use salt in their algorithms: longer origin strings are harder to find matches for. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225597 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Alright, so you can find out what the hash is, so you have *your* password. Now how are you going to find the user ID of someone else (especially if it is an uuid) and figure out their password? Plus, once again you can seed the hash if you are worried about it. Sure, you have to think about security a little bit when using cookies, but to me, thats a small price to pay and worth the tradeoff not to use client vars. There just isnt much that I ever want to store in a cookie, the userid and password being one of the few examples. Anything else is just preferences like font size or something silly. But I would much rather think about security and use cookies than client vars. They are just too prone to problems imo. On 11/29/05, Russ [EMAIL PROTECTED] wrote: Yea, I mentioned that before in the thread. Theoretically, hashing should be 1 way (so there is no way to turn the hash back into the value). But you could run a bruteforce against a hash, and be able to figure out what the hashed value really is. You can also build a table of all possible hashes, and then it just becomes a linear search. (I know someone who's got the complete rainbow tables for windows passwords, and is able to find any password within a few hours, I believe, if he's got the hash). -Original Message- From: Kerry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 1:14 PM To: CF-Talk Subject: RE: pseudo-memory leak FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 09:43 To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225605 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
As I've mentioned before, it's not that you have *your* password. It's that someone else can sniff your cookies (which are being sent over on every request, over unencrypted links, since most of us don't build our entire sites on HTTPS). Someone can easily sniff the cookie being sent, and figure out your password. And since a lot of people use the same password for more then one place, now the hacker has access to all the other places where you use the same password. The point is, it's a security hole. And one that doesn't need to be there. I don't see why you would ever want to store sensitive information like userid and password in a cookie, even if it's hashed. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 1:40 PM To: CF-Talk Subject: Re: pseudo-memory leak Alright, so you can find out what the hash is, so you have *your* password. Now how are you going to find the user ID of someone else (especially if it is an uuid) and figure out their password? Plus, once again you can seed the hash if you are worried about it. Sure, you have to think about security a little bit when using cookies, but to me, thats a small price to pay and worth the tradeoff not to use client vars. There just isnt much that I ever want to store in a cookie, the userid and password being one of the few examples. Anything else is just preferences like font size or something silly. But I would much rather think about security and use cookies than client vars. They are just too prone to problems imo. On 11/29/05, Russ [EMAIL PROTECTED] wrote: Yea, I mentioned that before in the thread. Theoretically, hashing should be 1 way (so there is no way to turn the hash back into the value). But you could run a bruteforce against a hash, and be able to figure out what the hashed value really is. You can also build a table of all possible hashes, and then it just becomes a linear search. (I know someone who's got the complete rainbow tables for windows passwords, and is able to find any password within a few hours, I believe, if he's got the hash). -Original Message- From: Kerry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 1:14 PM To: CF-Talk Subject: RE: pseudo-memory leak FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 09:43 To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225613 Archives: http://www.houseoffusion.com/cf_lists
RE: pseudo-memory leak
FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... That's only if you have a weak password. I used a brute force on a 7 character password that had upper/lower alpha, numeric, and a special character. It took my PC 2 weeks to crack it! If you use more than 7 characters, the amount of time grows exponentially. If you seed the hash, it throws another wrench in the hacker's wheels. And like Ryan said, once they do finally get the password (are we talking months now?), they have to start working on the user name. [INFO] -- Access Manager: This transmission may contain information that is privileged, confidential and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. A2 ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225616 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
(I know someone who's got the complete rainbow tables for windows passwords, and is able to find any password within a few hours, I believe, if he's got the hash). LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? -Original Message- From: Russ To: CF-Talk Sent: 29/11/2005 18:22 Subject: RE: pseudo-memory leak Yea, I mentioned that before in the thread. Theoretically, hashing should be 1 way (so there is no way to turn the hash back into the value). But you could run a bruteforce against a hash, and be able to figure out what the hashed value really is. You can also build a table of all possible hashes, and then it just becomes a linear search. (I know someone who's got the complete rainbow tables for windows passwords, and is able to find any password within a few hours, I believe, if he's got the hash). -Original Message- From: Kerry [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 1:14 PM To: CF-Talk Subject: RE: pseudo-memory leak FYI, hashing something doesnt mean that it cant be extracted, why just the other day my little 2Ghz workstation extracted a 5 character password from a hash in about 5 minutes... -Original Message- From: Snake [mailto:[EMAIL PROTECTED] Sent: 29 November 2005 09:43 To: CF-Talk Subject: RE: pseudo-memory leak Normally you would HASH the data so it cannot be extracted and used or changed. -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: 28 November 2005 23:40 To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225618 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? -Original Message- From: Russ To: CF-Talk Sent: 29/11/2005 18:22 Subject: RE: pseudo-memory leak Yea, I mentioned that before in the thread. Theoretically, hashing should be 1 way (so there is no way to turn the hash back into the value). But you could run a bruteforce against a hash, and be able to figure out what the hashed value really is. You can also build a table of all possible hashes, and then it just becomes a linear search. (I know someone who's got the complete rainbow tables for windows passwords, and is able to find any password within a few hours, I believe, if he's got the hash). This e-mail is from Reed Exhibitions (Oriel House, 26 The Quadrant, Richmond, Surrey, TW9 1DL, United Kingdom), a division of Reed Business, Registered in England, Number 678540. It contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s) please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited and may be unlawful. If you have received this communication in error please return it to the sender or call our switchboard on +44 (0) 20 89107910. The opinions expressed within this communication are not necessarily those expressed by Reed Exhibitions. Visit our website at http://www.reedexpo.com ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225620 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225626 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225627 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225630 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225632 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225636 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Ill give you another. Just to make sure its all kosher. Lets say a normal password string, could include numbers and letters, max length of 20, min length of 6. That should narrow it down some for you. No spaces either. 997DA8FE4C40296C21CE8E1EB9BDC5B6 On 11/29/05, Russ [EMAIL PROTECTED] wrote: Well what kind of string am I working with? For all I know, you could've hashed a whole book. Is there a length limit? (as there would very likely be if this was a password) -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:36 PM To: CF-Talk Subject: Re: pseudo-memory leak Tell you what. See how long it takes you to brute force this hash. Post the cleartext when you get it. 6AF59B04BA48B18C15E3CB3ACB2BA75B I want to see how long it takes you. On 11/29/05, Russ [EMAIL PROTECTED] wrote: The passwords in windows are stored as hashes. They are not stored as plaintext. In order to get the password, you would need to brute force the hash. Cracking windows passwords is an old idea with a great set of tools behind it. We are just using that knowledge to show that you shouldn't store passwords in cookies, hashed or not. As far as I understand it, if you store something as a client variable, there is no way for hacker to get at it (unless of course he somehow gets into your database server, in which case all bets are off). But if you store it as a cookie, it's much more vulnerable to foul play. -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 4:14 PM To: CF-Talk Subject: Re: pseudo-memory leak If you are an admin on the machine you could get the passwords even if they weren't in cookies! If someone ever puts in their password at all outside of ssl, you can sniff the password. If someone steals the SAM file, what does it matter where I store the password or how I hash it? what does that have to do with cookies vs client variables and the security impact of the two? On 11/29/05, Russ [EMAIL PROTECTED] wrote: Not, really. There are different ways of getting hashes. One is you can be an admin on the machine, and you can get the passwords of all the users. Another way is to sniff it going across the network. You can also steal the SAM file and get the password that way. The point is, you don't always need to have a login on the system (or physical access to the machine) to get people's passwords off of it. -Original Message- From: Robertson-Ravo, Neil (RX) [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 3:22 PM To: CF-Talk Subject: RE: pseudo-memory leak LOL, isnt that just like saying - I can get into any computer which is locked..if you give me the password? ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225637 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225444 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
I'm not running any servers on BD. How BD handles this counts on what id does internally for client vars and when they are cleaned out. Note that I don't have 100% of the information on this as of yet and the memory structures for client variables might not work as I think or might clean out faster than I think. Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225447 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225448 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
I use them for a persisted signin when someone comes to the site. I can use a cookie instead but As for the issue, think beyond client vars into what is created when your site gets a 'hit'. If you have session vars, these are ramped up. If you use session objects, these are ramped up. My personal story used client vars, but this affects more than just that. I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225450 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
-Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:10 PM To: CF-Talk Subject: Re: pseudo-memory leak I use them for a persisted signin when someone comes to the site. I can use a cookie instead but As for the issue, think beyond client vars into what is created when your site gets a 'hit'. If you have session vars, these are ramped up. If you use session objects, these are ramped up. My personal story used client vars, but this affects more than just that. Exactly. I had the same kind of problems with FirstNight.org sometimes. When the user traffic was high letting a bot start to index the site would kill it. Dead. We didn't use Client Variables on the site. (I solved the issue by putting a restrictive robots.txt on the site for the busy times.) If Yahoo (or Google or whoever) hits your site even, say, 100 times an hour that's a 100 extra sessions (or whatever) that are created and have to be dealt with. If it's more aggressive (as its clear Yahoo has become) you're looking at tens of thousands of extra do nothing user sessions. A lot of people load balance for expected user traffic... but really should also consider load balancing for additional search engine traffic as well. Jim Davis ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225451 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Well in that case couldnt you look for the robot in the useragent string? I know googlebot at least has a specific user agent you can look for. Im sure yahoo does too. If you find that useragent, then dont create the client or session vars/objs. On 11/28/05, Jim Davis [EMAIL PROTECTED] wrote: -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:10 PM To: CF-Talk Subject: Re: pseudo-memory leak I use them for a persisted signin when someone comes to the site. I can use a cookie instead but As for the issue, think beyond client vars into what is created when your site gets a 'hit'. If you have session vars, these are ramped up. If you use session objects, these are ramped up. My personal story used client vars, but this affects more than just that. Exactly. I had the same kind of problems with FirstNight.org sometimes. When the user traffic was high letting a bot start to index the site would kill it. Dead. We didn't use Client Variables on the site. (I solved the issue by putting a restrictive robots.txt on the site for the busy times.) If Yahoo (or Google or whoever) hits your site even, say, 100 times an hour that's a 100 extra sessions (or whatever) that are created and have to be dealt with. If it's more aggressive (as its clear Yahoo has become) you're looking at tens of thousands of extra do nothing user sessions. A lot of people load balance for expected user traffic... but really should also consider load balancing for additional search engine traffic as well. Jim Davis ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225452 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Ryan, you're right on, mainly. The typical progression in developers, and/or in large projects, is, start with client variables in the registry. Learn quickly not to do that, switch to cookies until they can be stored in a database. With traffic, you will eventually learn that your database / db server can't handle the load, or the communication between CF and your DB is becoming too great. Switch back to cookies until you can find a permenant client var work-around. Hopefully by this time client variable calls aren't too integrated into your site, or making the switch will be a huge problem. Meanwhile, if you store wddx in client variables, you will quickly learn about the maximum size of a cookie, and the adverse effects it has on different versions of popular browsers when that limit is reached. To make a long story short, don't do it: http://www.dopefly.com/techblog/entry.cfm?entry=77 Of course, not everyone will have these problems. If you have a small site with little traffic, even storing your client variables in the registry may not hurt anything, and can be fine for years and years. But when you build a popular site or get a few million hits a month, you're in for a ride. -nathan strutz http://www.dopefly.com/ On 11/28/05, Ryan Guill [EMAIL PROTECTED] wrote: I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225453 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
That's exactly what my example code did. It was in the second email and in the blog. Well in that case couldnt you look for the robot in the useragent string? I know googlebot at least has a specific user agent you can look for. Im sure yahoo does too. If you find that useragent, then dont create the client or session vars/objs. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225454 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
sorry, guess I haven't gotten the second email.. and no, i didnt look at the blog. On 11/28/05, Michael Dinowitz [EMAIL PROTECTED] wrote: That's exactly what my example code did. It was in the second email and in the blog. Well in that case couldnt you look for the robot in the useragent string? I know googlebot at least has a specific user agent you can look for. Im sure yahoo does too. If you find that useragent, then dont create the client or session vars/objs. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225455 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Ohh, nevermind, I see it now. My applogies. On 11/28/05, Ryan Guill [EMAIL PROTECTED] wrote: sorry, guess I haven't gotten the second email.. and no, i didnt look at the blog. On 11/28/05, Michael Dinowitz [EMAIL PROTECTED] wrote: That's exactly what my example code did. It was in the second email and in the blog. Well in that case couldnt you look for the robot in the useragent string? I know googlebot at least has a specific user agent you can look for. Im sure yahoo does too. If you find that useragent, then dont create the client or session vars/objs. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225456 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
Not a worry. :) Once I have some more information on specifics I'll have a full paper written up for Fusion Authority. Ohh, nevermind, I see it now. My applogies. On 11/28/05, Ryan Guill [EMAIL PROTECTED] wrote: sorry, guess I haven't gotten the second email.. and no, i didnt look at the blog. On 11/28/05, Michael Dinowitz [EMAIL PROTECTED] wrote: That's exactly what my example code did. It was in the second email and in the blog. Well in that case couldnt you look for the robot in the useragent string? I know googlebot at least has a specific user agent you can look for. Im sure yahoo does too. If you find that useragent, then dont create the client or session vars/objs. ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225460 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225468 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
In that case, wouldn't you want to store the password in the cookie too? Perhaps hashed? -Original Message- From: Russ [mailto:[EMAIL PROTECTED] Sent: Tuesday, 29 November 2005 12:46 p.m. To: CF-Talk Subject: RE: pseudo-memory leak Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225469 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
Re: pseudo-memory leak
You would always hash any information that the user could mess with, no matter what it is. And you should have validation on all of it too. the same as if you had url variables. Use an uuid for a userid if you are worried about them changing it. 10 bucks says they dont guess anyone right but their own in 10 tries. ;) On 11/28/05, Russ [EMAIL PROTECTED] wrote: Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225471 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
The point is with client variables... There is no way that the user can mess with it... Hashed or not... And even UUID's can be guessed... Not very easily... But possible... But I guess it's sort of like trying to guess sessions at that point... I still don't know how hashing something helps... Security by obscurity? If you take a userID 123456 and you hash it and it becomes ABCDEF (or whatever the hash function produces), why can't a smart user has a userID 123457 using CF and set the cookie? I mean he'd have to know that you're hashing the userID and storing it in his cookie, but this is easily guessable... -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 7:03 PM To: CF-Talk Subject: Re: pseudo-memory leak You would always hash any information that the user could mess with, no matter what it is. And you should have validation on all of it too. the same as if you had url variables. Use an uuid for a userid if you are worried about them changing it. 10 bucks says they dont guess anyone right but their own in 10 tries. ;) On 11/28/05, Russ [EMAIL PROTECTED] wrote: Cookies are not very secure now, are they? Lets say I was going to let the user be logged in, and I wanted that to persist... So I would do.. Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Russ -Original Message- From: Ryan Guill [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 2:04 PM To: CF-Talk Subject: Re: pseudo-memory leak I have never really found a need for client variables. What benefit do they really offer? The only time I could see using them is when you had something that you might think about storing in a cookie. I rarely come across a need like that where I dont really want a cookie, and if I do I usually just store it in the session. Am I missing something there? On 11/28/05, Russ [EMAIL PROTECTED] wrote: Are you still running another server on BD? How is BD handling this issue? -Original Message- From: Michael Dinowitz [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 1:38 PM To: CF-Talk Subject: pseudo-memory leak I've written up my thoughts on what looks like the problem that the House of Fusion server was facing for the last few weeks. It's a problem that probably affects others but I'm not going to comment on how wide spread it is until the full write-up on Fusion Authority. These are just my notes and thoughts. http://www.blogoffusion.com/index.cfm/2005/11/28/pseudomemory-leak ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225472 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
why can't a smart user has a userID 123457 using CF and set the cookie? Because you'd hash the password and store that too. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225474 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... If your site is running on any kind of traffic, you should probably be using session variables for this kind of thing anyway. Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Using an ID in a cookie in combination with something else, like a unique session hash cookie that changes upon login and gets checked against the database on every page load, you would be okay. Session variables are still more efficient in most cases though. -Justin Scott ~| Discover CFTicket - The leading ColdFusion Help Desk and Trouble Ticket application http://www.houseoffusion.com/banners/view.cfm?bannerid=48 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225501 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
The client variables would be used in case the user checks something like 'Remember Me' checkbox upon loggin in. Otherwise, of course you would be using session variables (Unless you're on a load balanced server using CF Standard, which doesn't have session replication). In that case, it would be better to use client variables instead of session variables. -Original Message- From: Justin D. Scott [mailto:[EMAIL PROTECTED] Sent: Tuesday, November 29, 2005 12:07 AM To: CF-Talk Subject: RE: pseudo-memory leak Client.userId=123456 Now, the user has no way to change that... Now, lets say I store it in the cookie... If your site is running on any kind of traffic, you should probably be using session variables for this kind of thing anyway. Cfcookie name=userId value=123456 Now, the user can examine their cookies and know their userid. Worse, they can change the userid, and be logged in as a different user. Using an ID in a cookie in combination with something else, like a unique session hash cookie that changes upon login and gets checked against the database on every page load, you would be okay. Session variables are still more efficient in most cases though. -Justin Scott ~| Find out how CFTicket can increase your company's customer support efficiency by 100% http://www.houseoffusion.com/banners/view.cfm?bannerid=49 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225504 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
RE: pseudo-memory leak
This should work... But then lets say that you encrypt your login page using SSL. And the rest of the site is not (as it should be). The password hash gets passed with every request, which makes it very likely that it can be sniffed. Once the hacker has the hash, he can do a brute force attack on it and figure out the user's password. Even worse, he doesn't even need the password, as the hash is enough for him to get into the account. Now, a hacker being able to sniff someone's session would probably be able to fake the CF session cookies and hijack the session anyway, but at least he wouldn't be able to figure out the password. -Original Message- From: Matthew Walker [mailto:[EMAIL PROTECTED] Sent: Monday, November 28, 2005 8:05 PM To: CF-Talk Subject: RE: pseudo-memory leak why can't a smart user has a userID 123457 using CF and set the cookie? Because you'd hash the password and store that too. ~| Logware (www.logware.us): a new and convenient web-based time tracking application. Start tracking and documenting hours spent on a project or with a client with Logware today. Try it for free with a 15 day trial account. http://www.houseoffusion.com/banners/view.cfm?bannerid=67 Message: http://www.houseoffusion.com/lists.cfm/link=i:4:225505 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4 Donations Support: http://www.houseoffusion.com/tiny.cfm/54
