> The above is NOT an option, no one in their right mind would use > it either, unless the site is intended for people who know what > that ugly and scary error message really means.
True, but it is still an option in many cases - see below. > OK, your site has SSL, do all your clients have SSL? If not, is > the process used secure enough? Or you just don;t care then > because they are not using SSL? No not all our client *need* SSL, in fact only a couple of them do. Ok a bunch of them have an admin system that lets the login & change content. Does that need SSL protection? In most cases no. Others have an admin that they just log into to pick up a CSV file of feedback comments or orders. Again is SSL required? Usually no, ask yourself if you would be happy to fax or post this information. We try to be very clear on the level of security that we are providing. "See that log in? That's just like a private property sign on the gate." If client are not happy with this we outline the other options and provide associated costs. So in what cases is security warranted? Money transactions obviously, anything that provides enough access to the server itself to cause serious damage (like file system or service access) or anything that would cause major problems if information was tampered with (like various voting apps). There are a bunch more but the main idea is - You don't usually need security on a basic web site, but if you do you better be using SSL or something of that standard. I should also add that SSL does not provide "total security" on its own. There are lots of other ways that apps can be insecure. > I have about 12 sites, none should be related, 12 X 200 = 2.400 > US a year, 3.100 AUSD... Do all these sites really need SSL? Maybe only some parts of some apps do. Could you get a cert for one domain and then use sub domains to access the secure bits of each site via SSL. For example - get a cert for mydomain.com and then setup client1.mydomain.com, client2.mydomain.com and so on to provide secure access to your server for each of your clients. (Is it possible to get a cert that covers a whole server not just a domain? Not sure.) > Mmmm, I don't know why you don't see the use of trying to work on > a more secure process that can be used by any website that can't > afford SSL? The reason I don't see the use of trying is because I know for a fact that I am not capable of implementing a better solution even if I had the time or inclination to try. This is not "the little engine that could" (I think I can, I think I can) - its like me saying I am not able to perform brain surgery or design a working space craft. On the topic of affordability - SSL itself is completely free. As I pointed out before you can go and use it without paying anyone anything. What you are paying for is "trust" from a "certificate authority" (CA). This means that the CA has verified that you are who you are - this does not add "security" it adds "trust". Basically it prevents you & me from saying we are Westpac. If you just need security for your clients to login & administer your sites then "trust" is not an issue, you don't need Verisign involved & you shouldn't have to pay anything. Just explain to them that they need to accept your cert the first time they hit the site. If you go into IE & go Tools/Internet Options/Content/Certificates/Trusted Root Certificate Authorities you'll see a list of CAs that IE trusts automatically. All of these CAs cut deals with M$ so that they could then reseller that "trust". That is the only thing you are paying for - not "security". > But as I said, security has always been a BIG issues > and people are scared talking about or doing anything about it, > publicly anyway.. I agree that security is a BIG issue. Regarding people not wanting to discuss it publicly - most sensible people will be happy to talk about it publicly. I do remember that conversations have in effect been shut down on this list before, but I think (hope) that was more to do with the way things were being discussed rather than the way in which it was being discussed. Yes this is a fine line & I think I'm leaning more towards your point of view on this one. See http://en.wikipedia.org/wiki/Security_through_obscurity again. Some people think that not talking about a vulnerability (like SQL injection) makes it less of a problem. I completely disagree with that idea. Cheers Mark ------------------ Mark Stanton Technical Director Gruden Pty Ltd Tel: 9956 6388 Mob: 0410 458 201 Fax: 9956 8433 http://www.gruden.com --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
