5 ms·

From the first answer > The only (currently practical) way to protect against login interception (packet sniffing) during login is by using a certificate-based

by yread 15y ago

From the first answer > The only (currently practical) way to protect against login interception (packet sniffing) during login is by using a certificate-based encryption scheme (e.g. SSL) or a proven & tested challenge-response scheme (e.g. the Diffie-Hellman-based SRP). I'm no security expert but if you take into account man in the middle attack where the attacker can actually change the page/javascript you're not safe even with DH. Attacker can just drop all your fancy code and send the password in the clear and intercept it later...

wisty 15y ago
Yep, if it's not https (including all sources and iframes) you can get some nasty JS injected into the page, and you can't do anything about it.
JVerstry 15y ago
No, that is not exactly true. If you use SSL, there will be authentication. Eve-in-the-middle cannot craft certificates or feed the browser with her fake certificates. No 3rd party HTML/Javascript/whatever code can change this. So there is a higher level of security with SSL.
- yread 15y ago
  that's what I'm trying to say, too. I meant that you're not safe even with DH and have to use SSL
- rjbond3rd 15y ago
  Definitely true but this scenario worries me: 1. Get a signed cert from a recognized CA (fraudulently - not impossible). 2. Hijack the DNS (e.g., get their GoDaddy password, or point them to a DNS server you control)>. 3. The user is directed to the fake server with the fraudulently obtained cert, and does not receive a warning.
  - JVerstry 15y ago
    Absolutely, authentication is not bullet-proof. That's why certificate authorities have to invalidate certificates from time-to-time.
    - rjbond3rd 15y ago
      True, and of course they can only revoke the ones they know are fake. And the browser/client has to respect the revocation list.
tptacek 15y ago
I'm a security professional focusing on exactly this issue and you are exactly correct. It is, notably, not enough to safeguard the JS code with HTTPS/TLS (which, if you do that, SRP is of virtually no utility anyways). To protect the Javascript runtime, you'd also need to ensure that no element of the page was ever cached from a non-HTTPS connection, that no element of the page is currently fed from a non-HTTPS connection, and that the page is free from any and all DOM or CSS corruption issues. Obviously, you'd also need to implement SRP safely, which very few people do; more than half of the SRP implementations I've ever tested have been trivially bypassed due to math flaws. SRP is a terrible suggestion for generalist devs and for authentication in a web setting. If you want to do something advanced, go two-factor; I like Duo Security, which will be easier for you to integrate than SRP anyways: http://www.duosecurity.com/ http://www.duosecurity.com/
- stephenemslie 15y ago
  Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.
  - tptacek 15y ago
    Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.
    - lhnn 15y ago
      Though they might be the best people, and though I have Duckduckgo on my side, it might be useful to post a citation. EDIT: To practice what I preach: Duo Song has made an impressive network sniffer and some other cool stuff, and Jon apparently is a security guru who, among other things, has found several security related Android bugs.
- drivebyacct2 15y ago
  Why would I want to use this instead of using Google Authenticator with RFC4226 or TOTP (http://tools.ietf.org/id/draft-mraihi-totp-timebased-06.txt http://tools.ietf.org/id/draft-mraihi-totp-timebased-06.txt) ? Looks like Duo has more options for receiving the code as well as the ability to enable manual approve/deny for another user role. It also looks like a private service I have to rely on though.

by yread 15y ago

wisty 15y ago

Yep, if it's not https (including all sources and iframes) you can get some nasty JS injected into the page, and you can't do anything about it.

JVerstry 15y ago

No, that is not exactly true. If you use SSL, there will be authentication. Eve-in-the-middle cannot craft certificates or feed the browser with her fake certificates. No 3rd party HTML/Javascript/whatever code can change this. So there is a higher level of security with SSL.

yread 15y ago
that's what I'm trying to say, too. I meant that you're not safe even with DH and have to use SSL
rjbond3rd 15y ago
Definitely true but this scenario worries me: 1. Get a signed cert from a recognized CA (fraudulently - not impossible). 2. Hijack the DNS (e.g., get their GoDaddy password, or point them to a DNS server you control)>. 3. The user is directed to the fake server with the fraudulently obtained cert, and does not receive a warning.
- JVerstry 15y ago
  Absolutely, authentication is not bullet-proof. That's why certificate authorities have to invalidate certificates from time-to-time.
  - rjbond3rd 15y ago
    True, and of course they can only revoke the ones they know are fake. And the browser/client has to respect the revocation list.

tptacek 15y ago

I'm a security professional focusing on exactly this issue and you are exactly correct. It is, notably, not enough to safeguard the JS code with HTTPS/TLS (which, if you do that, SRP is of virtually no utility anyways). To protect the Javascript runtime, you'd also need to ensure that no element of the page was ever cached from a non-HTTPS connection, that no element of the page is currently fed from a non-HTTPS connection, and that the page is free from any and all DOM or CSS corruption issues. Obviously, you'd also need to implement SRP safely, which very few people do; more than half of the SRP implementations I've ever tested have been trivially bypassed due to math flaws. SRP is a terrible suggestion for generalist devs and for authentication in a web setting. If you want to do something advanced, go two-factor; I like Duo Security, which will be easier for you to integrate than SRP anyways: http://www.duosecurity.com/ http://www.duosecurity.com/

stephenemslie 15y ago
Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.
- tptacek 15y ago
  Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.
  - lhnn 15y ago
    Though they might be the best people, and though I have Duckduckgo on my side, it might be useful to post a citation. EDIT: To practice what I preach: Duo Song has made an impressive network sniffer and some other cool stuff, and Jon apparently is a security guru who, among other things, has found several security related Android bugs.
drivebyacct2 15y ago
Why would I want to use this instead of using Google Authenticator with RFC4226 or TOTP (http://tools.ietf.org/id/draft-mraihi-totp-timebased-06.txt http://tools.ietf.org/id/draft-mraihi-totp-timebased-06.txt) ? Looks like Duo has more options for receiving the code as well as the ability to enable manual approve/deny for another user role. It also looks like a private service I have to rely on though.