exactly, since the browser is used for so much of our sensitive network activity, I think we should be using the most secure technologies available to define its code that processes information from the network (pretty much everything). You are essentially running a program that is going to run arbitrary code in a sandbox on your machine. That sandbox MUST be airtight. In an evolving code base I don't think vigilance is enough to keep the sandbox well sealed. Too much is at stake to rely on dilligence. We need to be working at the correct level of abstraction to keep it secure. Its 2009, lets at least remove buffer overflow from the list of potential cracks in the sandbox.

While Java/.NET and other modern languages are not without security flaws, I don't see how any of their past vulnerabilities can compare to using a language where every single string operation is a chance for a lack of diligence to open an attack vector. I'm not trying to start some kind of holy war here, but it just seems like most of the time we see one of these flaws it comes down to the language providing insecure ways of handling string operations. No doubt it has libraries that allow for safe manipulation, but it requires constant vigilance by the developers to prevent security holes. Developers should be concentrating on the more sophisticated attacks that are possible against these engines, not worrying about how safely they are handling their strings.

What modern language would have been open to this attack vector. Browsers are important. They should not be written in c/c++, whatever the performance gains. Lets just not do it anymore.

This needs to become about Strong Authentication, not strong passwords. Changing a password often just frustrates users and doesn't help against base level attacks like keylogging. And if your password only changes every month or two then its still valid for quite a while if it is discovered. We should instead be using multple password factors for all secure scenarios. Something you know AND something you have (some sort of One Time Password, certificate, or biometric factor). This is less frustrating for the user than having to change their password all the time, and it defeats keyloggers, phishing, etc. Soon the web will have to wake up to this. If some of the big players would start to play ball, and say, support the yubikey token at least, then we might start to get the ball rolling. At least since the identity field is consolidating a bit with infocard and openid, we'll be in a position where all you need is an identity provider that can support multi factor auth.

hmmm... yeah, I suspected there would be some spec for this, but I hadn't checked into it. Thanks for the info.

Yeah, I could see why there might be rollout and adoption problems though.

Mostly I was just lamenting some of the inadequecies of the internet. Especially ones that seem hard to combat without further bootstrapping by governence bodies.