The encrypted connection (at least w. mysql) uses the OpenSSH libs. If the libs are b0rked, using ssh probably isn't going to be much of an improvement.
Certainly from a health risk point of view, that makes more sense (and no, I don't smoke anything - never could stand the smell, and I prefer to waste my money on chocolate. Better a couple of pounds extra than one lung less:-)
Mysql supports encrypted connections, and another poster pointed out that so does postgresql. For mysql, you can REQUIRE that remote client connections be encrypted.
You can also limit the hosts, etc., from which you allow connections, and you can give them read-only access to only certain fields, etc.
That said, I ssh into my home server when I'm at the office - its just drop-dead easy. I wouldn't normally consider accessing the db directly from a client app for end users as being a "good thing", but all this hand-waving over an open port, as if that is by itself a huge security risk, well, that gets my goat. Any decent db can be locked down pretty tight.
Funny thing is, where I'm working, the bias is against older people. "We tried a half-dozen, and they all had issues." Since then, we've gone through I don't know how many people in the 20-to-40 age bracket, but I'm still here:-)
In the last year, the bias has shifted back to the over-50 group in larger businesses, because, IF they've been in the field for a couple of decades, they're worth it, and generally don't have the "need" to get into "pissing contests" about who knows what - they've had a couple of decades to work it out of their systems, or they use slashdot to proxy their luser abuse:-)
DB engines support encrypted connections via SSL Here's how for mysql - you can REQUIRE the connection be secure.
MySQL allows encryption to be enabled on a per-connection basis. You can choose a normal unencrypted connection or a secure encrypted SSL connection according the requirements of individual applications.
Secure connections are based on the OpenSSL API and are available through the MySQL C API. Replication uses the C API, so secure connections can be used between master and slave servers.
the db engine can restrict the type of access via type of connection, ip, host, user, password, time of day, db, table, fields accessed, functions accessed, types of operations, etc. This is all built in - not something you have to code separately and hope you "got it right".
The "researchers" who claimed that an open port is, in and of itself, a security risk, need to realize that an open port is just that - an open port. It means nothing if you don't know how the machine is configured.
If you don't care who accesses it for read permissions, leave it open. You can set access rules in any half-decent database that allows only write/update permissions from specific ips, domains, users, etc. And you can always encrypt your connection. Getting your underwear all in a twist when the security provided by the database is better than most web apps... well, think about it - this is just a knee-jerk reaction.
No, thinking that everything is so important that it needs to be totally secure and have a gajillion layers of "protection", each with their own leaks, is retarded. Somehow, I don't think that a list of shared bookmarks, bor example, is "need-to-know" stuff.
You can lock down access by client domain, by ip, by database, by password, by user, by table, by time of day, by field, by lookup in another field, whatever. A heck of a lot more options than an ftp or http server, and there's no reason you can't encrypt the session.
"if you leave the DB port open, you must give your application/applet the necessary credentials to log in to the database;"
The user can supply the credentials even with access to the db via an application (not an applet - that's for web browsers).
Remember, part of the access permissions for most databases is the host/ip, and all permissions can be very fine-grained - right down to individual fields in individual tables. It defaults to localhost, but you can add other hosts as well.
Well, don't forget the story this weekend about the guy who was a 26-year-old IT professional working for an IT security company who pled guilty to using a botnet of 250,000 PCs - customer machines - to do numerous frauds.
Ethics has nothing to do with age.
My point was that the basic premise of the article - that the presence of the open port in and of itself was a sufficient metric to be able to say "OMG INSECURE" - is not valid in and of itself.
One good example - we have an app that sits on port 80. To the world it looks like a web server, but its not. Why would you run something other than a web server on port 80? Well, first, its usually open, hence accessible w/o having to change anything on the client end. We could just as easily run it on port 3306, 22, 443, or whatever, just by changing the config file.
"Any internet company providing services within Europe is subject to European law. This applies to Google just as well as any other site that has a presence in Europe. Even if a site's servers are not physically located in Europe, if they are commonly accessed by Europeans, then they are providing a service in Europe and are subject to European laws."
You're wrong on that last bit - as long as there is no "commercial interest", no server outside the EU is bound by EU law. This is why, for example, you can have a site in the US that sells Nazi memorabilia, and there's nothing the EU can do, until someone in Germany tries to buy - and then its the German purchaser who is in trouble.
Same with sites that promote hate speech (Aryan Nation) - shut down by the courts when it was operated in Canada, but when the site was moved to a server in the US, it was no longer under Canadian jurisdiction - and the courts so noted.
The same argument could be made about ANY service/port, including http, ftp, etc. The premise of the article - that "port open == bad all by itself" - is junk.
And as we have repeatedly seen, accessing your db through a web server gives 2 different attack vectors - flaws in the web server, and flaws in the middleware.
Nothing except an unplugged box with the hard drive removed will ever be 100% secure.
Think for 2 secs... each kw of electricity eventually gets converted to heat. Resistive heating generates ~ 3,400 btus per kilowatt, so multiplying electrical consumption by pi gives you a decent cooling capacity. Add an extra 10% and you're good to go (you *DO* remember to add in a fudge factor of between 10 and 20% for "future expansion", right?)
In the winter, if you heat with electricity, you can basically run your computer for free, since its waste heat reduces the amount of heat needed to be generated by resistance heaters.
Believe it or not, but in one of those "life coincidences", pi is a safe approximation. Take the number of watts your equipment, lighting, etc., use, multiply by pi, and that's the # of btus of cooling. Don't forget to include 100 watts per person for body heat.
It'll be 90F degrees outside, and you'll be a cool 66F.
"The Android Developer Challenge is open to individuals, teams of individuals, and business entities. While we seek to make the Challenge open worldwide, we cannot open the Challenge to residents of Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) because of U.S. laws. In addition, the Challenge is not open to residents of Italy or Quebec because of local restrictions."
>"A. Employee shall promptly and fully disclose in writing to [Company] any inventions, improvements, discoveries, operating techniques, or "know-how", whether patentable or not (hereinafter referred to as "Inventions"), conceived or discovered by Employee, either solely or jointly with others, during the course of Employee's employment with [Company], or within six (6) months thereafter. "
This means that you are granting them the rights (which you can't legally do) to stuff you create for a future employer for up to 6 months after you leave.
Have they offered you a concomittant pay raise for changing the terms of your employment and making you unemployable for 6 months after you leave? Didn't think so.
Tell them you can't sign it, and start looking for another job.
Slashdot Mirror
The encrypted connection (at least w. mysql) uses the OpenSSH libs. If the libs are b0rked, using ssh probably isn't going to be much of an improvement.
"i think it was made pretty clear that this is a by cisco, for cisco, there aint nothing in the world but cisco book."
Yep. Those Crisco people are sure greasy!
Better to cut the fat and switch to leanux.
Certainly from a health risk point of view, that makes more sense (and no, I don't smoke anything - never could stand the smell, and I prefer to waste my money on chocolate. Better a couple of pounds extra than one lung less :-)
Mysql supports encrypted connections, and another poster pointed out that so does postgresql. For mysql, you can REQUIRE that remote client connections be encrypted.
You can also limit the hosts, etc., from which you allow connections, and you can give them read-only access to only certain fields, etc.
That said, I ssh into my home server when I'm at the office - its just drop-dead easy. I wouldn't normally consider accessing the db directly from a client app for end users as being a "good thing", but all this hand-waving over an open port, as if that is by itself a huge security risk, well, that gets my goat. Any decent db can be locked down pretty tight.
Funny thing is, where I'm working, the bias is against older people. "We tried a half-dozen, and they all had issues." Since then, we've gone through I don't know how many people in the 20-to-40 age bracket, but I'm still here :-)
In the last year, the bias has shifted back to the over-50 group in larger businesses, because, IF they've been in the field for a couple of decades, they're worth it, and generally don't have the "need" to get into "pissing contests" about who knows what - they've had a couple of decades to work it out of their systems, or they use slashdot to proxy their luser abuse :-)
"they email it to themselves over the Internet."
Lovely - so, knowing most people, google/microsoft/yahoo have a copy :-(
I just ssh into my home box :-)
I needed a 300 meg file from my home box earlier this week - sftp to the resuce.
Either you believe your people are trustworthy and won't give the data to competitors, or, if you can't trust them, you should fire them.
The "researchers" who claimed that an open port is, in and of itself, a security risk, need to realize that an open port is just that - an open port. It means nothing if you don't know how the machine is configured.
If you don't care who accesses it for read permissions, leave it open. You can set access rules in any half-decent database that allows only write/update permissions from specific ips, domains, users, etc. And you can always encrypt your connection. Getting your underwear all in a twist when the security provided by the database is better than most web apps ... well, think about it - this is just a knee-jerk reaction.
Not all data is all that important.
No, thinking that everything is so important that it needs to be totally secure and have a gajillion layers of "protection", each with their own leaks, is retarded. Somehow, I don't think that a list of shared bookmarks, bor example, is "need-to-know" stuff.
You can lock down access by client domain, by ip, by database, by password, by user, by table, by time of day, by field, by lookup in another field, whatever. A heck of a lot more options than an ftp or http server, and there's no reason you can't encrypt the session.
"if you leave the DB port open, you must give your application/applet the necessary credentials to log in to the database;"
The user can supply the credentials even with access to the db via an application (not an applet - that's for web browsers).
Remember, part of the access permissions for most databases is the host/ip, and all permissions can be very fine-grained - right down to individual fields in individual tables. It defaults to localhost, but you can add other hosts as well.
Well, don't forget the story this weekend about the guy who was a 26-year-old IT professional working for an IT security company who pled guilty to using a botnet of 250,000 PCs - customer machines - to do numerous frauds.
Ethics has nothing to do with age.
My point was that the basic premise of the article - that the presence of the open port in and of itself was a sufficient metric to be able to say "OMG INSECURE" - is not valid in and of itself.
One good example - we have an app that sits on port 80. To the world it looks like a web server, but its not. Why would you run something other than a web server on port 80? Well, first, its usually open, hence accessible w/o having to change anything on the client end. We could just as easily run it on port 3306, 22, 443, or whatever, just by changing the config file.
"Any internet company providing services within Europe is subject to European law. This applies to Google just as well as any other site that has a presence in Europe. Even if a site's servers are not physically located in Europe, if they are commonly accessed by Europeans, then they are providing a service in Europe and are subject to European laws."
You're wrong on that last bit - as long as there is no "commercial interest", no server outside the EU is bound by EU law. This is why, for example, you can have a site in the US that sells Nazi memorabilia, and there's nothing the EU can do, until someone in Germany tries to buy - and then its the German purchaser who is in trouble.
Same with sites that promote hate speech (Aryan Nation) - shut down by the courts when it was operated in Canada, but when the site was moved to a server in the US, it was no longer under Canadian jurisdiction - and the courts so noted.
The same argument could be made about ANY service/port, including http, ftp, etc. The premise of the article - that "port open == bad all by itself" - is junk.
And as we have repeatedly seen, accessing your db through a web server gives 2 different attack vectors - flaws in the web server, and flaws in the middleware.
Nothing except an unplugged box with the hard drive removed will ever be 100% secure.
That's not true.
For example, you may have a stand-alone java app at multiple locations that can query the database directly, so you'd definitely open up the port.
This is just another example of "OMFG LOOK AT ME!!! I FOUND TEH SECURITY HOLE!" bullshit. Same as "your computer is broadcasting its IP address."
Not everything has to go through a bloody web server.
Their "idea" of a vulnerability was if the port was open - not if they could gain access.
>"There's not really much you can do about it other than require an ID for everyone regardless of age"
You can always just ban cigarette vending machines ... other places have done it.
Think for 2 secs ... each kw of electricity eventually gets converted to heat. Resistive heating generates ~ 3,400 btus per kilowatt, so multiplying electrical consumption by pi gives you a decent cooling capacity. Add an extra 10% and you're good to go (you *DO* remember to add in a fudge factor of between 10 and 20% for "future expansion", right?)
Just don't do it in a closed room. And don't dip your finger in it to see if its "cool enough".
In the winter, if you heat with electricity, you can basically run your computer for free, since its waste heat reduces the amount of heat needed to be generated by resistance heaters.
Believe it or not, but in one of those "life coincidences", pi is a safe approximation. Take the number of watts your equipment, lighting, etc., use, multiply by pi, and that's the # of btus of cooling. Don't forget to include 100 watts per person for body heat.
It'll be 90F degrees outside, and you'll be a cool 66F.
"this is great news indeed....lets just hope we don't see an equal number of returns/exchanges in a month or two.."
I'm sure if someone actually returns one, there'll be someone else happy to take it off their hands, esp. with a $20 "open box" discount.
Throw an extra stick of ram in it (what, $50) and run your windows apps under wine.
Yep - you have to pay a "license fee" of 10% of the potential prize to the government as a "permit" - even if nobody wins.
Of course, the simple way around that is to submit it via the web, naming a relative in another province/state.
"The Android Developer Challenge is open to individuals, teams of individuals, and business entities. While we seek to make the Challenge open worldwide, we cannot open the Challenge to residents of Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) because of U.S. laws. In addition, the Challenge is not open to residents of Italy or Quebec because of local restrictions."
Mama Mia! Tabernak!
>"A. Employee shall promptly and fully disclose in writing to [Company] any inventions, improvements, discoveries, operating techniques, or "know-how", whether patentable or not (hereinafter referred to as "Inventions"), conceived or discovered by Employee, either solely or jointly with others, during the course of Employee's employment with [Company], or within six (6) months thereafter. "
This means that you are granting them the rights (which you can't legally do) to stuff you create for a future employer for up to 6 months after you leave.
Have they offered you a concomittant pay raise for changing the terms of your employment and making you unemployable for 6 months after you leave? Didn't think so.
Tell them you can't sign it, and start looking for another job.
"Illegal file-sharing is not proper theft but it is without a doubt a fraud, as you are getting a service (entertainment) without paying for it."
Wrong. Canadians DO pay for it, via a levy on recording materials (blank CDs, etc) that goes back to the recording industry, so its not even "fraud."