Having a strong password is not really relevant. If it complies to the basic rules of password strength, it's good enough. Because cybercriminals will not try to guess or crack your password. They'll hack the server or your computer, probably via malware or an exploit. What's more important is: did the website developer stored the password in a secure way and did you use a different password for every website?
First, know that it's not that I think all CAs are bad and evil. It's just that I don't know them and I don't know their procedures. Every CA that I 'trust' but has issued certificates only to websites that I never visit is a potential threat. Because that trust can be broken but I don't suffer from removing them from my list.
If you want to do this right, request a list of issued certificates from every CA and check if you ever need a secure connection with any of those websites. If you do, keep the CA. If not, remote it. Because this is quite some work, the best thing to do is remove the obvious ones, like CAs from China, Turkey, Taiwan and other countries from which you don't visit websites, keep the ones you clearly need (likely CAs from your own country) and make your own choice about the rest.
I encourage you to try PolarSSL. It's really good and easy to learn. I replaced OpenSSL with PolarSSL in my own open source project within a few days and the only thing I regret is not doing it earlier.
From a technological point of view, it's a good protocol. It works and when implemented correctly, it's very secure. However, a PKI is not much about technology. It's mostly about organisation. In other words, it's not about PK, but all about I.
And that's were most things go wrong. Yes, Heartbeat was about technology, but people who paid attention moved away from OpenSSL a long time ago. There are more than enough alternatives. GnuTLS and PolarSSL for example. Apple's gotofail was also about technology, but name me one piece of software that is 100% bug free.
The real problem with HTTPS is how it's organized. When I install a browser (or get one via the OS), I also get a shit load of CA's which I'm supposed to trust. CA's from China, Turkey, Taiwan and other countries from which I don't even speak the language. I will never need a certificate from one of those CA's, because I will never need a secure connection with any website protected by their certificates. If the people from Iran were wise enough to realize that they don't need Diginotar because they don't speak Dutch, they would never be at risk because of Diginotar's epic failure. The first thing I do when installing a web browser is get rid of all the irrelevant CA's. Just to be sure, just to be safe.
And that's what's wrong with HTTPS. That's what needs to be fixed. Trust shouldn't be imposed by a browser maker. Trust should be earned.
It seems that the Hiawatha webserver is not vulnerable for this exploit, because it doesn't URL decode environment variables. Wise decision (CGI's seem to work fine without it) or just luck? Is there a standard which says that CGI environment variables should be URL decoded?
Choosing a programming language that best suites the needs of your company it totally different from pointless bashing a programming language you don't even use. In that case, those opinions are irrelevant to everybody.
That's good for you, but it's still an opinion. I don't think that PHP works against the programmer. Talking about Django, I don't like it. I've takens a look at it, but I think it's too much hustle to get a simple website running. I've created my own framework, the Banshee PHP framework. It's fast, secure and easy to use. The websites you can make with Banshee are just as good as the one you can make with Django.
You're missing my point. I'm only saying: if you don't like it, don't use it. But don't bug other people with oppinion, because it's irrelevant to the .
It's not a bad knife. It's just that *you* think that it's a bad knife. I think it's a fine knife. I'm not saying perfect, but no knife is. I know its good sides, I know its bad sides, which allows me to handle it well. The things I create with it are really up any challenge.
it's the cook that prepares the food. It's not the camera, it's the photographer that shoots the picture. It's not the racing car, it's the driver that wins the race. It's not the programming language, it's the programmer that creates the application.
All you whiners can bash PHP like you want. But a PHP website will still beat your Perl website if the PHP programmer is better than you. So, unless your coding skills are 100% perfect, you better start looking at your own flaws instead of wasting time at whining about a programming language that simply isn't your pick of choice. Please, it's time to grow up.
You expect and want the US to stick it's nose into every corner of the world?
It already has been doing that for the last decades.
Don't we have a UN? Can't Europe look after itself?
I'm not say that *only* the US president should be doing something. EVERY world leader should be doing something. If you think that this is only a local incident, you don't understand the situation there and what just has happend.
... the priority is investigating whether U.S. citizens were involved.
Seriously, is that really what matters now? What an arrogant *****. What really matters is who did it and why. What's the risk for other planes. If it were the rebels, how did they get their hands on such advanced weaponry. 298 people died. Who they were is something to find out by the airliner company. A president, and specially one from the USA, should really have other things to worry about.
Don't focus on a language only. Also look at a good framework. My advice is the Banshee PHP framework. It mainly focuses on security, which is the only important thing these days. I know this will be seen as spam, but do yourself a favor and just take a look at it for 15 minutes.
It should be dead
on
Perl Is Undead
·
· Score: 1, Insightful
Whatever it is now, it should be dead. For the simple reason that Perl allows this kind of code:
Yeah, tell that to the firewall administrator who thinks that opening an extra port is far more insecure than to tunnel that extra connection via HTTP. The IT world is defined by a mass amount of incompetent administrators and developers.
The biggest problem with SPDY is that it's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit from it. In my free time, I'm writing an open source webserver and by doing so, I've encountered several bad things in the HTTP and CGI standard. Things can be made really more easy and thus faster if we, for example, agree to let go of this rediculous pathinfo, agree that requests within the same connection are always for the same host and make the CGI headers work better with HTTP.
You want things to be faster? Start by making things more simple. Just take a look at all the modules for Apache. The amount of crap many web developers want to put into their website can't be fixed by a new HTTP protocol.
We don't need HTTP/2.0. HTTP/1.3 with some things removed, fixed or at least have some vague things be specified more clearly, would be more than enough for 95% of all the websites.
Your story isn't about you messing up. It's about your boss failing hard at proper risk management. He's the one who should be fired for allowing a process in the company in which one person could do so much damage.
Unfortunately, this happens still too often. Companies in which the mistake of one single person, the error of one single machine or the failure of one single process starts a chain reaction which causes heavy damage. Just take a look a look at the company you work for. I'm sure everybody can point out a machine or a person that will cause serious problems if that machine or person is not available for a certain amount of time.
Slashdot Mirror
Having a strong password is not really relevant. If it complies to the basic rules of password strength, it's good enough. Because cybercriminals will not try to guess or crack your password. They'll hack the server or your computer, probably via malware or an exploit. What's more important is: did the website developer stored the password in a secure way and did you use a different password for every website?
First, know that it's not that I think all CAs are bad and evil. It's just that I don't know them and I don't know their procedures. Every CA that I 'trust' but has issued certificates only to websites that I never visit is a potential threat. Because that trust can be broken but I don't suffer from removing them from my list.
If you want to do this right, request a list of issued certificates from every CA and check if you ever need a secure connection with any of those websites. If you do, keep the CA. If not, remote it. Because this is quite some work, the best thing to do is remove the obvious ones, like CAs from China, Turkey, Taiwan and other countries from which you don't visit websites, keep the ones you clearly need (likely CAs from your own country) and make your own choice about the rest.
I encourage you to try PolarSSL. It's really good and easy to learn. I replaced OpenSSL with PolarSSL in my own open source project within a few days and the only thing I regret is not doing it earlier.
From a technological point of view, it's a good protocol. It works and when implemented correctly, it's very secure. However, a PKI is not much about technology. It's mostly about organisation. In other words, it's not about PK, but all about I.
And that's were most things go wrong. Yes, Heartbeat was about technology, but people who paid attention moved away from OpenSSL a long time ago. There are more than enough alternatives. GnuTLS and PolarSSL for example. Apple's gotofail was also about technology, but name me one piece of software that is 100% bug free.
The real problem with HTTPS is how it's organized. When I install a browser (or get one via the OS), I also get a shit load of CA's which I'm supposed to trust. CA's from China, Turkey, Taiwan and other countries from which I don't even speak the language. I will never need a certificate from one of those CA's, because I will never need a secure connection with any website protected by their certificates. If the people from Iran were wise enough to realize that they don't need Diginotar because they don't speak Dutch, they would never be at risk because of Diginotar's epic failure. The first thing I do when installing a web browser is get rid of all the irrelevant CA's. Just to be sure, just to be safe.
And that's what's wrong with HTTPS. That's what needs to be fixed. Trust shouldn't be imposed by a browser maker. Trust should be earned.
Never mind my previous post. The weblog article has been changed, so the claim of not being vulnerable seems to be false.
It seems that the Hiawatha webserver is not vulnerable for this exploit, because it doesn't URL decode environment variables. Wise decision (CGI's seem to work fine without it) or just luck? Is there a standard which says that CGI environment variables should be URL decoded?
Oh, wait. Elliptic curve cryptography, never mind my previous post.
... consists of 64 hex characters. This gives a 256 bit public key. Not very strong or am I missing something?
Choosing a programming language that best suites the needs of your company it totally different from pointless bashing a programming language you don't even use. In that case, those opinions are irrelevant to everybody.
That's good for you, but it's still an opinion. I don't think that PHP works against the programmer. Talking about Django, I don't like it. I've takens a look at it, but I think it's too much hustle to get a simple website running. I've created my own framework, the Banshee PHP framework. It's fast, secure and easy to use. The websites you can make with Banshee are just as good as the one you can make with Django.
You're missing my point. I'm only saying: if you don't like it, don't use it. But don't bug other people with oppinion, because it's irrelevant to the .
It's not a bad knife. It's just that *you* think that it's a bad knife. I think it's a fine knife. I'm not saying perfect, but no knife is. I know its good sides, I know its bad sides, which allows me to handle it well. The things I create with it are really up any challenge.
But tell me, how's your cooking?
Thank you for proving my point.
If you don't like PHP, that's fine. But please, stop wasting other people's time with your whining about it. Really, nobody cares!
it's the cook that prepares the food. It's not the camera, it's the photographer that shoots the picture. It's not the racing car, it's the driver that wins the race. It's not the programming language, it's the programmer that creates the application.
All you whiners can bash PHP like you want. But a PHP website will still beat your Perl website if the PHP programmer is better than you. So, unless your coding skills are 100% perfect, you better start looking at your own flaws instead of wasting time at whining about a programming language that simply isn't your pick of choice. Please, it's time to grow up.
prick
You expect and want the US to stick it's nose into every corner of the world?
It already has been doing that for the last decades.
Don't we have a UN? Can't Europe look after itself?
I'm not say that *only* the US president should be doing something. EVERY world leader should be doing something. If you think that this is only a local incident, you don't understand the situation there and what just has happend.
In the US, the truth shall set you free,
Omg, how brainwashed one can be. The US is one big lie itself.
... the priority is investigating whether U.S. citizens were involved.
Seriously, is that really what matters now? What an arrogant *****. What really matters is who did it and why. What's the risk for other planes. If it were the rebels, how did they get their hands on such advanced weaponry. 298 people died. Who they were is something to find out by the airliner company. A president, and specially one from the USA, should really have other things to worry about.
Don't focus on a language only. Also look at a good framework. My advice is the Banshee PHP framework. It mainly focuses on security, which is the only important thing these days. I know this will be seen as spam, but do yourself a favor and just take a look at it for 15 minutes.
Whatever it is now, it should be dead. For the simple reason that Perl allows this kind of code:
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map{$_%16or$t^=$c^=( $m=(11,10,116,100,11,122,20,100)[$_/16%8])$t^=(72,@z=(64,72,$a^=12*($_%16 -2?0:$m&17)),$b^=$_%64?12:0,@z)[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h =5;$_=unxb24,join"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$ d=unxV,xb25,$_;$e=256|(ord$b[4])
A very good part: Banshee PHP framework.
I know this post will be flagged as spam. But if you like PHP, I challenge you to give this framework a try. At least take a look at the online demo.
Yeah, tell that to the firewall administrator who thinks that opening an extra port is far more insecure than to tunnel that extra connection via HTTP. The IT world is defined by a mass amount of incompetent administrators and developers.
The biggest problem with SPDY is that it's a protocol by Google, for Google. Unless you are doing the same as Google, you won't benefit from it. In my free time, I'm writing an open source webserver and by doing so, I've encountered several bad things in the HTTP and CGI standard. Things can be made really more easy and thus faster if we, for example, agree to let go of this rediculous pathinfo, agree that requests within the same connection are always for the same host and make the CGI headers work better with HTTP.
You want things to be faster? Start by making things more simple. Just take a look at all the modules for Apache. The amount of crap many web developers want to put into their website can't be fixed by a new HTTP protocol.
We don't need HTTP/2.0. HTTP/1.3 with some things removed, fixed or at least have some vague things be specified more clearly, would be more than enough for 95% of all the websites.
http://regmedia.co.uk/2014/05/... says it all. Thinking that encrypting everything makes the internet more secure is really naieve.
Your story isn't about you messing up. It's about your boss failing hard at proper risk management. He's the one who should be fired for allowing a process in the company in which one person could do so much damage. Unfortunately, this happens still too often. Companies in which the mistake of one single person, the error of one single machine or the failure of one single process starts a chain reaction which causes heavy damage. Just take a look a look at the company you work for. I'm sure everybody can point out a machine or a person that will cause serious problems if that machine or person is not available for a certain amount of time.