4 ms·

Here is how it generally works. This method provides a salt along with a nonce. In general, only the actual user knows the password. Start: User registers for

Here is how it generally works. This method provides a salt along with a nonce. In general, only the actual user knows the password. Start: User registers for a service and submits a username + password. The password is salted and hashed in the browser and then sent to the server over a secure connection along with other info. like username etc... Then when somebody wants to so log in: Server sends a random nonce and keeps track of nonce for all requests when the initial login page is sent to the browser. Then the user enters username + password to the browser. The browser computes hash(nonce + hash(salt(password))) and sends the result to the server along with username info. The server looks up the password hash associated with the username and compares hash(nonce + stored-hash) vs. the info. sent by the browser. If there is equality, the user is authenticated and interaction proceeds as normal. Note that only the user actually knows the password. Even the server only has the hash of a salted version of the password. Next, even this salted hash is never sent directly over the network. A decent implementation will randomize the nonce so that packet sniffing attacks don't work.

tptacek 18y ago
You're not thinking this through. Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. If attackers don't have access to raw traffic, sending over the plaintext password is just fine, because attackers don't have access to raw traffic. I'm sorry, but security isn't an obstacle course. For evidence, go research what percentage of online bank transactions in Brazil were fraudulent in 2007. There is no clever solution to this problem. Send passwords over SSL, or don't care about the password you send.
- cperciva 18y ago
  Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. No. It's entirely possible for an attacker to have access to your data (say, because they compromise a system which has been dumping packets for offline analysis) without being able to rewrite packets in transit. I'm not saying that the suggested mechanism is a good idea, but let's be honest in our security analyses, ok?
  - tptacek 18y ago
    Colin, attackers aren't sniffing SprintNet with sunsniff to get access to traffic anymore. They're knocking over one of the 15-odd points where they can substitute their IP for COMCAST.NET. Personally, I think you do a grave disservice to developers by dignifying the notion that "passive-only attacks" are a reasonable threat model.
    - cperciva 18y ago
      I didn't say that "passive-only attacks" were a reasonable threat model. In fact, I explicitly stated that I was not saying that the suggested mechanism was a good idea. But even if only 0.0001% of attackers are limited to passive-only attacks (and I suspect the actual value is higher -- more like 0.1%) then the suggested mechanism is 0.0001% more secure than transmitting the password in plaintext -- which invalidates your assertion that it "provides no additional security".
      - tptacek 18y ago
        No, because you're ignoring the fact that one of the 15-odd places that an attacker can bust up to redirect traffic to their own servers is the "observe all packets" vantage point, which allows them to predict DNS XIDs and source ports. I know you're smarter than this, Colin. I think you're being pedantic. Would you advise anyone on this message board any differently than me? I think you already said "no".
        cperciva 18y ago
        Would you advise anyone on this message board any differently than me? I think you already said "no". There are two parts to giving advice: Helping people with their immediate question, and helping people better understand the field in question so that they won't need your advice the next time. You told people that what they were talking about doing was a bad idea, which I agree with; but the explanation you gave was misleading. I agree with your recommendation of "don't do that"; but I think it's important for people to understand WHY they shouldn't do that -- and claiming that it's "no more secure" rather than explaining that it's very slightly more secure obfuscates rather than elucidates.
- xirium 18y ago
  > bank transactions in Brazil Banks in Brazil routinely issue each customer with a duress PIN to mitigate the situation of a customer being frogmarched to an ATM at gunpoint. This is in addition to ATMs being unavailable in early hours due to the majority transactions being theft at gunpoint. Initial implementations of the duress PIN displayed an identical withdrawal limit and led to customers being shot. Subsequent implementations provide a reduced limit. I discovered this after lending a trifling amount to a Brazilian ex-colleague in the UK. He retained his Brazilian bank account and, to repay me, he had calculate the timezone differences for ATM use.

tptacek 18y ago

You're not thinking this through. Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. If attackers don't have access to raw traffic, sending over the plaintext password is just fine, because attackers don't have access to raw traffic. I'm sorry, but security isn't an obstacle course. For evidence, go research what percentage of online bank transactions in Brazil were fraudulent in 2007. There is no clever solution to this problem. Send passwords over SSL, or don't care about the password you send.

cperciva 18y ago
Either attackers have access to the raw traffic or they don't. If they do, and you don't use SSL with CA-anchored keys, attackers will rewrite the Javascript in transit, and your scheme provides no additional security. No. It's entirely possible for an attacker to have access to your data (say, because they compromise a system which has been dumping packets for offline analysis) without being able to rewrite packets in transit. I'm not saying that the suggested mechanism is a good idea, but let's be honest in our security analyses, ok?
- tptacek 18y ago
  Colin, attackers aren't sniffing SprintNet with sunsniff to get access to traffic anymore. They're knocking over one of the 15-odd points where they can substitute their IP for COMCAST.NET. Personally, I think you do a grave disservice to developers by dignifying the notion that "passive-only attacks" are a reasonable threat model.
  - cperciva 18y ago
    I didn't say that "passive-only attacks" were a reasonable threat model. In fact, I explicitly stated that I was not saying that the suggested mechanism was a good idea. But even if only 0.0001% of attackers are limited to passive-only attacks (and I suspect the actual value is higher -- more like 0.1%) then the suggested mechanism is 0.0001% more secure than transmitting the password in plaintext -- which invalidates your assertion that it "provides no additional security".
    - tptacek 18y ago
      No, because you're ignoring the fact that one of the 15-odd places that an attacker can bust up to redirect traffic to their own servers is the "observe all packets" vantage point, which allows them to predict DNS XIDs and source ports. I know you're smarter than this, Colin. I think you're being pedantic. Would you advise anyone on this message board any differently than me? I think you already said "no".
      - cperciva 18y ago
        Would you advise anyone on this message board any differently than me? I think you already said "no". There are two parts to giving advice: Helping people with their immediate question, and helping people better understand the field in question so that they won't need your advice the next time. You told people that what they were talking about doing was a bad idea, which I agree with; but the explanation you gave was misleading. I agree with your recommendation of "don't do that"; but I think it's important for people to understand WHY they shouldn't do that -- and claiming that it's "no more secure" rather than explaining that it's very slightly more secure obfuscates rather than elucidates.
xirium 18y ago
> bank transactions in Brazil Banks in Brazil routinely issue each customer with a duress PIN to mitigate the situation of a customer being frogmarched to an ATM at gunpoint. This is in addition to ATMs being unavailable in early hours due to the majority transactions being theft at gunpoint. Initial implementations of the duress PIN displayed an identical withdrawal limit and led to customers being shot. Subsequent implementations provide a reduced limit. I discovered this after lending a trifling amount to a Brazilian ex-colleague in the UK. He retained his Brazilian bank account and, to repay me, he had calculate the timezone differences for ATM use.