Re: Two-factor auth for Bugzilla
On 7/02/11 2:38 AM, Florian Weimer wrote: * Gervase Markham: Goal: fix bug 570252. Provide 2-factor authentication for some Bugzilla accounts. https://bugzilla.mozilla.org/show_bug.cgi?id=570252 The IP address restriction is a pretty strong factor. Basically, it means that a potential attacker would have to compromise a device quite close to the user (possible the terminal itself). If you deal with such attackers, very few reliable options exist. For Bugzilla, things are extraordinarily difficult because you don't want to protect transactions, but read access to certain bugs. If your threat target is read access to certain bugs, then the low hanging fruit might be to use client certs. You already have all the tech, it's just a matter of using it. Asking the security people to get a client cert, and registering it by hand in the code, is no biggie. As a result, extending the IP address restrictions, possibly using crypto tunnels such as OpenVPN, are probably a better investment than hardware tokens. You also need usage how the key material is to be handled by users. IP address restrictions are a bit of a facade. Techies register their online servers, and hop through there, as they tend to connect in from different places. They might still be worth doing, though. It will certainly not help against malware which captures server responses, but none of the technologies under consideration will. iang PS: fwiw, I've got a few conceptual notes on how to use client certs here: https://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Two-factor auth for Bugzilla
On 02/06/2011 05:38 PM, From Florian Weimer: The IP address restriction is a pretty strong factor. Florian, tell me what your IP is and I'll log into Bugzilla next time with that IP. Getting to know your IP is fairly easy too. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 02/06/2011 07:11 PM, From Zack Weinberg: I'm going to ask you the same question I asked Nelson: In a hypothetical world where DNSSEC+TLSA completely supersedes DV (but people still use OV/EV for high-value sites) what do you see as having been lost? Or, turning it around, what value do you see DV signatures from CAs as providing over and above that provided by DNSSEC+TLSA? One of the points to consider is anti-phishing and flagging features built into CAs systems (not all, but some). Ability to revoke certificates by a responsible third party is however probably a strong point in favor for CA issued certificates, CA provided warranties on top yet another. There is certainly more into what CAs do, provide and stand for besides the mere "point to point authentication". I see a value in DV like IV/OV provide others. It all depends on the intended purpose. I believe in using the added capabilities of DNSSEC for CA issued certificates once it gets to adopted to a usable level, I don't believe that "just keys" in DNS can provide something that third parties can rely on (also entirely from a technical point of view). And having a CA take responsibility is obviously not only a technical solution to a certain problem. -- Regards Signer: Eddy Nigg, StartCom Ltd. XMPP:start...@startcom.org Blog:http://blog.startcom.org/ Twitter: http://twitter.com/eddy_nigg -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Two-factor auth for Bugzilla
* Marsh Ray: > My personal opinion is that IP source addresses are not actually a > particularly strong factor. Here are some reasons: It really depends on what you're dealing with. Mozilla shouldn't disclose that to the general public, so it's difficult to make good recommendations. >> As a result, extending the IP address restrictions, possibly using >> crypto tunnels such as OpenVPN, are probably a better investment than >> hardware tokens. > > What does a VPN get you that a solid SSL/TLS setup does not? Current malware does not capture OpenVPN keys. Client certificates are sometimes extracted, and are certainly indicative of an interesting target. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: TLS server keys in DNS: client policy proposal
On 02/05/2011 02:55 PM, Eddy Nigg wrote: However probably the optimal approach will be CA issued certs in DNS that also make use of DNSSEC to validate the former (DV). Eventually I believe that this will emerge as the real improvement and most useful approach for software vendors and CAs alike - providing real value for what DV is supposed to do and by closing the entire circle. I'm going to ask you the same question I asked Nelson: In a hypothetical world where DNSSEC+TLSA completely supersedes DV (but people still use OV/EV for high-value sites) what do you see as having been lost? Or, turning it around, what value do you see DV signatures from CAs as providing over and above that provided by DNSSEC+TLSA? zw -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Two-factor auth for Bugzilla
On 02/06/2011 09:38 AM, Florian Weimer wrote: The IP address restriction is a pretty strong factor. Basically, it means that a potential attacker would have to compromise a device quite close to the user (possible the terminal itself). We end up in a deep discussion about this every few weeks at work. My personal opinion is that IP source addresses are not actually a particularly strong factor. Here are some reasons: * IP source addresses are basically self-reported by the unauthenticated sender. Source address authentication is built on the hope that it is hard for the attacker to inject or observe packets on the target network so he will be unable to originate a TCP connection. * Originally IP did not attempt to provide any security properties and IP routing is not always configured with these attacks in mind. Even backbone routing is essentially an environment of implicit trust. There have been notable cases of unfriendly parties taking over netblocks which supposedly belonged to others. * Bad guy only needs to pwn one box or app on the "trusted" network. Often he can choose from hundreds to attack. * A misconfigured (or with out-of-date firmware) blue-box Linksys home router/firewall on the internal net could be leveraged for its NAT * DNS rebinding attacks * An HTTP CONNECT proxy could find its way onto the trusted LAN without anyone realizing it * Often, there is Wifi open, crackable, or having a weak password * Minor point: hardcoding IPv4 addresses into configs may not be the best long-term plan considering that we're officially out of them So probably it can be useful on a very carefully-managed network, but even minor mistakes will tend to result in a silent vulnerability. If you deal with such attackers, very few reliable options exist. For Bugzilla, things are extraordinarily difficult because you don't want to protect transactions, but read access to certain bugs. Yeah that makes it much harder. The bad guy doesn't necessarily even need to originate his own TCP connection. He can entice the target user to visit a web page which loads an image that makes the http request. The user's browser may have a cached session cookie. In the absence of SSL, he may be able to view the response. As a result, extending the IP address restrictions, possibly using crypto tunnels such as OpenVPN, are probably a better investment than hardware tokens. What does a VPN get you that a solid SSL/TLS setup does not? Sometimes adding more moving parts can just make things worse. For example, an attacker can often leverage a VPN login into access to a website if the VPN client and the web server support a compatible auth protocol like MS-CHAPv2/NTLMv2. - Marsh -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: Two-factor auth for Bugzilla
* Gervase Markham: > Goal: fix bug 570252. Provide 2-factor authentication for some > Bugzilla accounts. > https://bugzilla.mozilla.org/show_bug.cgi?id=570252 The IP address restriction is a pretty strong factor. Basically, it means that a potential attacker would have to compromise a device quite close to the user (possible the terminal itself). If you deal with such attackers, very few reliable options exist. For Bugzilla, things are extraordinarily difficult because you don't want to protect transactions, but read access to certain bugs. As a result, extending the IP address restrictions, possibly using crypto tunnels such as OpenVPN, are probably a better investment than hardware tokens. You also need usage how the key material is to be handled by users. It will certainly not help against malware which captures server responses, but none of the technologies under consideration will. -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
