[hsiung]

There are still ways to add a little extra security for non-ssl logins. One way is by hashing the password via javascript with a random number provided by the server before posting it via HTTP. (see http://pajhome.org.uk/crypt/md5/auth.html)

[tptacek]

That adds no security at all. Security is not an obstacle course.

[thorax]

Security is nothing but an obstacle course. The only time security is not merely an obstacle course is when you completely destroy the thing you're trying to protect.

This is fundamentally something everyone needs to understand about computer security-- it's all about creating bigger and harder obstacles (including literal, physical obstacles). You can never absolutely secure something while it exists.

[tptacek]

That's a fine argument for rejecting all of engineering. An asteroid could always strike the bridge we're building! Why bother making it structurally sound?

[thorax]

I'm not sure why you're treating my comment as an argument to reject security (or to reject anything other than your specific wording choice). I'm just saying that security, fundamentally, is about making obstacles.

There's nothing implied there regarding the importance/unimportance/quality of those obstacles. I don't think understanding its fundamental nature takes anything away from Security.

[tptacek]

That's really not true. I think you're conflating cryptography with security. In crypto, I suppose you could consider algorithms that increase attacker cost as "obstacles", though I think the word loses meaning when the "obstacle" involves summoning more CPU cores than there are atoms in the solar system.

In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles". There are a finite number of vulnerabilities in any piece of code.

[DougBTX]

In practical security, closing a buffer overflow, sanitizing inputs, and proving code paths are not "obstacles".

I think you're being a bit picky over wording, an "obstacle" is just something which makes it harder for some to break your system, examples of which are closing buffer overflows and sanitizing inputs.

You could, possibly, use it as an argument against engineering, but I think you'd be wrong. The same as someone arguing "we're all going to die anyway so lets get it over with now" is wrong: it means that you have to make the most of what you do have.

[thorax]

I'm not referring to cryptography, I'm referring to security in the general sense. Security is fundamentally about placing obstacles between your assets and those who you don't want to use/alter/control those assets.

When you design software, you have all sorts of assets you'd like to protect, even for the simplest cases. Administrative access, general data, CPU cycles, workflow, network bandwidth, and maybe even passwords, secrets, etc. Your job (with a security design hat on) is to place the firmest obstacles you can between those assets and those you don't want to use them (usually prioritized by a combination of probable risk, severity of loss, and cost to protect).

Thinking in terms of assets you need to protect is a highly recommended way to design securely, regardless of whether you're talking about military, bodyguards, buildings, software, cryptography, or systems. You then proceed to put up your best obstacles and then reshore/rebuild/redesign those obstacles when they are known to be compromised or compromisable. All the while ensuring that the system operates as efficiently as you can reasonably manage.

Fixing "a buffer overflow" is just a method for repairing the software obstacles you already had in place. Sanitizing inputs is, indeed, adding an obstacle for attackers. "Proving code paths" takes into account that your obstacles remain in place to protect your data with certain assumptions about the systems involved.

If you're interested in security engineering in general, I recommend picking up some of the latest (last 5-10 years) literature on Threat Modeling as it really can change one's perspective on what security is all about. A lot of engineers I've worked with think of it in terms of "using the best string library", when it's more about designing systems to protect your assets as best as you can and still get your job done.

There are all sorts of practices, tools, fixes, libraries, etc that help improve existing "bricks" in your obstacles, but they're absolutely no replacement for actually understanding what you're trying to protect and having a strategy for preventing those from being compromised. The best security is designing such that you never put your assets at risk than that you use the right libraries to, for example, manage them during transit.

[gojomo]

It adds a little. It means that a passive eavesdropper has to mount a offline dictionary attack before knowing the plaintext password. That's better than nothing.

[tptacek]

No. Respectfully, you too have failed to think this through. Attackers with access to raw traffic can (and routinely do) change the traffic. Attackers will simply rewrite your hashing Javascript in transit.

[gojomo]

That's an active attack. My statement was clear and correct. The number of people who can passively eavesdrop on traffic (eg, on open wifi) is much larger than those who can dynamically change traffic in transit.

[tptacek]

There are no passive-only attackers. Attackers who can observe raw traffic can hijack it (if it's the '90s) or redirect it (if it's 5 years ago, and in Brazil, and money is involved --- just to make it specific).

Look, we're locked in an Internet message board death struggle and neither of us are going to concede anything, so let me just finish with this tangent:

If you tried to sell an app to a Fortune 1000 company that defended against passive-only attackers but left logins open to active attackers, and they contracted out a 1 week 1 person web pen test to make sure your app was safe for peripheral customer data to go inside, you'd get dinged for this and you'd cut a dot release.

If, instead of cutting a dot release you explained why it was worth them moving ahead with a pilot that defended against passive attackers, you would Lose The Sale. Seen it happen.

I don't much care about your Hacker News password, but lots of you write applications, and I've seen some of the most unlikely (message boards, bug trackers, blogs---err, content managers) wind up in security audit hell. My advice, take it or leave it: don't bother with these Javascript hash schemes.

[gojomo]

As should have been clear, I wasn't talking about apps with Fortune 1000 company customer data. I certainly did not suggest the mild javascript-hashing technique would be appropriate for such situations. (So, your 90+ word tangent hypothesizing that I might try to sell such a thing is... obdurate? A strawman? Unfair?)

And, you seriously think there are "no" passive-only attackers? No people happy to merely scan or log traffic, not actively hijacking TCP sessions, but looking for info to exploit later? I suggest both the guy in the wifi cafe running a sniffer, and the NSA hardware in AT&T's room 641A, count as "passive-only attackers". Of course the javascript-hashing technique is only helpful against the former.

[volida]

you are saying that if someone is encrypting the password using RSA in javascript and then using the hash to exchange the password between server/client, is volnerable because someone can interfere in the traffic and change the javascript served to the user, so that the password is sent in plaintext and therefore steal the password?

then why meebo and other sites practise this method without security problems?

[simonw]

Why doesn't it add security? It means the password isn't being transmitted in cleartext (it's using an irreversible hash). For the record, Yahoo! use that exact technique on their login page (though I'm not sure why as it's served over https).

UPDATE: I see from a post further down that you're talking about re-writing the JavaScript in transit. Fair point.

[mfenniak]

The downside to this is that it requires the server to store the password unencrypted and unhashed. The server must have access to the original password to hash with the random number for comparison. In my opinion, this wouldn't be an improvement in the overall security of the system.

Avoid sending a plaintext password by using HTTPS. It's the easiest way.

[hsiung]

You store the password hashed with a salt in the database (just keep track of the salt you used). The server can send the salt to the client, in addition to the random number. So the client is performing two hashes: md5(md5(password+salt)+random_token).