Yeah i guess the underlying key is make the login system random behind the scenes but transparent to the user. The best you could hope for then is someone will just get fed up and walk away.
The only people i see sitting down and writing a program for this, are the ones i would class as "talented" and i'm sure using a web form simulation isn't their favoured way of DOS your server. In fact these guys/gals are most likely to take the white gloves off and just hack your OS/Firewall. Scott. (That and keep your username/pwds random use systems like CFLOGIN without the password attribute...heh i remember it was optional in the beta, but in the cfmx release its needed?? what gives) "Toby Tremayne" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > actually another way to prevent any kind of automated attack is to use > the "word in the image" technique common to free sign-up sites like > yahoo. You just have an extra field into which the user types the > word they see in the image (you can get components to generate these > randomly). This is probably going to be too much for a lot of clients > though... > > > > Monday, February 24, 2003, 5:56:15 PM, you wrote: > > SB> Well heres one suggestion (Just a theory). > > SB> 1. You use Javascript to execute your login form, so in way it restricts the > SB> user to a Javascript/Browser friendly program. > SB> 2. You randomly create a session.string value in CFMX (Seed Value); > SB> 3. You set this string value to a Javascript Variable named "foo" or > SB> whatever you want. > SB> 4. You randomly create 3x session.string value in CFMX (1=Key, 2=Username, > SB> 3=Password); > SB> 5. Using these random strings, create 3 form fields on the page (1st Hidden, > SB> 2,3 text); > SB> 6. Make an OnClick to either button type, or image to basically take the > SB> Javascript Seed Value and place it into the hidden form field value. > SB> 7. Make a call to action to a page (that invokes a cfc). > SB> 8. based on your session variables, compare them against to the > SB> form.variables for starters. > SB> 9. If they match then do a database lookup/handshake. > SB> 10. Do a simple 3 strikes and your out system against the session.ip (if > SB> they use a proxy cycler, well log the proxy IP.. eventually you may block > SB> the proxy ips before any damage is done) > > SB> Now this isn't 100% full proof and un-tested, but the theory is, try and > SB> make it a randomly generated form of some kind, in that keep vars names > SB> random so that any text pattern searching on the cfm page aren't allways the > SB> same (even mixup where they lie in response to line positions). > > SB> What this in theory does is basically say to the hacker, if you can: > SB> a) have a attackscript/program that can simulate javascript / or know how to > SB> read the page, find the random field names, then simulate a form post on > SB> those names. > SB> b) have a way to edit/updated your own header packets > SB> c) have a way to map to the correct seed against form values > SB> d) have a way to cycle through proxies > > SB> Then your welcome to hack the shit out of my site :D In a nutshell, its just > SB> a crazy whacky security theory i have had and in truth not allot of thought > SB> has gone into it... > > SB> One theory i also had, and once again this is just a theory is: > > SB> 1. You have a frontline of say 5 call to action pages (cloned off of the > SB> original) that all point to the one package cfc > SB> 2. You rename these files randomly each day > SB> 3. You have 5 login pages (cloned off of the original) that are stored in > SB> randomfolder/randomname.cfm format > SB> 4. These are stored in their own unique application scope that timeout daily > SB> 5. You then redirect the user to one of the 5 each time the user hits the > SB> "login area" > SB> 6. You apply the above to prevent formpost similiators > SB> 7. You pray your client hasn't got a password of "ima/egghead" format. > SB> 8. You hope they don't have ftp access :D > > SB> Like i said all theories, how useful they are is beyond my time :D never put > SB> it into place until Spike scared the shit out of me at the preso of his.. > SB> man i was torn between Spike and Jesse... hard call to make, so i only > SB> caught first half of spikes and last half of jesses... DAMN YOU MXDU :D SO > SB> much to learn so little time. > > > > SB> "Adam Chapman" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > >> > >> Hey Everyone.. > >> > >> At the hack-proofing CFMX session at MXDU, Spike > >> Mentioned a 'dictionary attack' or something similar > >> Where someone will pound your cf templates with lots-o > >> Username/password combos.. > >> > >> What are some of the methods peoples use to try and > >> Safeguard against this kind of thing..? > >> > >> Regards, > >> Adam Chapman > >> > >> Virtualtours.com.au > >> mailto:[EMAIL PROTECTED] > >> Phone: 1300 366 122 > >> (Int: +61 3 9720 5733) > >> Fax: +61 3 9720 6377) > >> > >> > >> > > > > SB> --- > SB> You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > SB> To unsubscribe send a blank email to [EMAIL PROTECTED] > > SB> MX Downunder AsiaPac DevCon - http://mxdu.com/ > > > > > > > > --------------------------------------- > > Life is poetry - > write it in your own words. > > --------------------------------------- > > Toby Tremayne > Technical Team Lead > Code Poet and Zen Master of the Heavy Sleep > Toll Solutions > 154 Moray St > Sth Melbourne > VIC 3205 > +61 3 9697 2317 > 0416 048 090 > ICQ: 13107913 > > > --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MX Downunder AsiaPac DevCon - http://mxdu.com/
