Hacker News Reader

Comment by yread | Hacker News Reader

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...

View on HN

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/

Thanks for the two-factor suggestion and the recommendation. Duo looks excellent.

Duo is Dug Song and Jon Oberheide. You really couldn't find a better team to get your back on authentication.

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.

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) ?

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.

It's not tied to a Google account, it has a better end-user experience, a better developer experience, and an extremely credible team behind it. That said, if you were using Google Auth and I assessed your application, I wouldn't ding you for using it.

Google Authenticator isn't tied to a Google account, and developing for it involves implementing a single algorithm.

Well the Google Authenticator application is just an implementation. I can use any TOTP generator to get access to my Google Account, or alternatively if I use the PAM module they've provided, I can use whatever I want to generate my codes to log in to my Linux machine. It just so happens that they use this mechanism for their two factor auth for Google Accounts.

I definitely hear you on the better user/dev experience. That's very clear from the variety of methods and slick screenshots they've got.

http://www.rcdevs.com/products/openotp/compare.php

https://tiqr.org/

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.

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.

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.

Absolutely, authentication is not bullet-proof. That's why certificate authorities have to invalidate certificates from time-to-time.

True, and of course they can only revoke the ones they know are fake. And the browser/client has to respect the revocation list.

that's what I'm trying to say, too. I meant that you're not safe even with DH and have to use SSL

Reply on news.ycombinator.com