Quote - I doubt staff have access to email address or credit card info.

They don't have to, as long as the servers do. The CC info I don't know how they handle - it could be a temp session file, it could be stored. Either way, it could be an inside job, but I doubt it... PHP has enough weaknesses that all it would take is the right exploit and a listener script (or simpler, a set of DB queries) to catch the data. it would take a bit more sophistication to scrounge temp sessions (if you have shell access to a PHP-running web server, take a peek in /tmp (the default temp file location) sometime - busy sites can get packed in a hurry. :) ) > Quote - You would have more of a chance of losing money in an Online Bank that any merchants online they fortunalely are more savvy and up to date with webpages than the online banks are.

Sometimes that's the case, but nowhere near all the time, or even most of the time in my experience. I still keep my money with a bank in Utah (used to live there - in Oregon now) because their web security is just That Damned Good. I haven't had to be there in person since February, and only had to telephone them 3 times (to let them know my new address when I moved twice, and once because my idiot ex-wife had her tax return direct-deposited to my savings account). IMHO, the most secure websites are the high-end established pornography sites. They have no choice but to be secure, becuase they've had to put up with theives and cracking attempts for far, far longer than any bank has. (In fact you'll find the best bank security rigs were prolly built and maintained by former pr0n administrators). > Quote - I say let the techs find the little pest that is lose, Nuke it and strength security, as  putting the balme here there and everywhere is a distraction.

I agree, which is why I was wondering a bit at all this official spouting off about trojans and MCSE's instead of digging through the logs and patch lists. To her credit, at least Stacey was [i]trying[/i] to do something productive (though IMHO I find that the process can often overshadow the solution... the times add up; it needs to be looked into). > Quote - They will notice it as they know exactly which code they have written for this site.

Actually, as a guy who has done the debug thing, and the troubleshooting thing, the time it takes to find out what might be amiss will vary. Scripts* are usually spread around by areas of responsibility - not everybody is going to know every line. Also, familiarity can often be more of a hindrance than a help (peek at, say, a 1500-line script sometime... even if you yourself wrote it, you will tend to subconciously gloss over the bits you think aren't part of the problem, when it could well be lurking there). Also, it could be outsourced - it's easier to take a module or functionality and hire someone to either write it, or customize one they have for inclusion. In terms of work saved by not re-inventing the wheel, it can be a benefit at times. In short - it's going to take a little time. > Quote - Unfortunaltey these things happen all the time, its good of us to point it out, but I dont like to point the finger at one person or a group of people, like I have said before these Guys employ hackers to do these kind of  things, they have Billions at their disposal.

Crackers and Script Kiddies have many achilles' heels - their efforts are omnidirectional, most will simply (and blindly) copy the efforts (and tools) of the few who do know what they're doing, and quite frankly, their biggest salvation is the fact that PHP is almost as full of swiss cheese as Microsoft IIS. *(a silly pet peeve of mine - please don't call it "code"; there's no compiling there. Sorry, but it kinda irks when I see it). /P