5 ms·

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 s

by hsiung 18y ago

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 http://pajhome.org.uk/crypt/md5/auth.html)

tptacek 18y ago
That adds no security at all. Security is not an obstacle course.
- simonw 18y ago
  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.
- gojomo 18y ago
  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 18y ago
    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 18y ago
      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 18y ago
        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.
        volida 18y ago
        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?
        eru 18y ago
        The canned argument is: No known security problem does not mean no security problem.
        tptacek 18y ago
        That's not the argument here, though. The proposed solution --- and the one that Meebo uses, when you don't use their SSL login --- has a glaring security problem.
- thorax 18y ago
  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 18y ago
    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 18y ago
      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 18y ago
        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 18y ago
        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.
mfenniak 18y ago
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 18y ago
  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).

by hsiung 18y ago

tptacek 18y ago

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

simonw 18y ago
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.
gojomo 18y ago
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 18y ago
  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 18y ago
    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 18y ago
      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.
      - volida 18y ago
        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?
        eru 18y ago
        The canned argument is: No known security problem does not mean no security problem.
        tptacek 18y ago
        That's not the argument here, though. The proposed solution --- and the one that Meebo uses, when you don't use their SSL login --- has a glaring security problem.
thorax 18y ago
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 18y ago
  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 18y ago
    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 18y ago
      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 18y ago
        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.

mfenniak 18y ago

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 18y ago
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).