Re: Status of opportunistic encryption
On Wed, May 31, 2006 at 08:56:53AM +1000, James A. Donald wrote: Active attacks are rare, possibly nonexistent except for Wifi. If NSA and the other TLAs were doing active attacks, they would be detected some of the time. They don't like being detected. Active attacks at the network layer are relatively rare, but definitely not non-existent. Spammers occasionally hijack BGP prefixes, send some spam and move on. They can also hijack nameserver IPs, MX host IPs, but for now they prefer sending over receiving. This will likely change, the playbook of organized crime on the net has been expanding steadily when money overtook teen-age dare-do as the most common motivation for active attacks in ~2002. If anyone does an active attack, this is a one off event. If someone routinely and regularly does active attacks, the attack will be detected, the point where they are modifying messages will be detected, and will be bypassed. They keep moving around, some ISPs turn a blind eye in return for the revenue stream. Consequently, also SSH with GSS KEX, is not MITM resistant when the attacker can tamper with DNS responses. My understanding is that SSH when using GSS KEX does not cache the keys, which strikes me as a amazingly stupid idea, No, that's the whole point. What works for the individual administering 10 machines, does not scale to organizations with hundres of administrators managing tens of thousands of machines. With KEX you trust Kerberos, not your key store. The problem is that one also ends up trusting, DNS or NIS or LDAP, ... particularly when SSH key caching has been so successful, and when the user thinks he knows his security comes from key caching. The experience with PKI suggests that it is very difficult to have security without durable cached keys. Quite the converse, the PKI keys are too durable. (Segue to Wheeler Wheeler) the Kerberos online verification model is actually superior, but in practice the implementation runs into issues with insecure nameservices. We need a more secure stack. Attacks on DNS are common, though less common than other attacks, but they are by scammers, not TLA agencies, perhaps because they are so easily detected. Yes, but the scammers are getting into more markets, first spam and advance fee scams, then phishing, now pump and dump scams, they are evolving fast. We are largely standing still. Encrypting DNS is unacceptable, because the very large number of very short messages make public key encryption an intolerable overhead. A DNS message also has to fit in a single datagram. Workable DNS-SEC exists, what lacks now is the will and political muscle to make it happen. Signing is done on update, not on read. To accommodate these constraints, we need DNS certificates sent in the clear, and signed with elliptic curve public keys (which allow both signatures and certificates to be short enough to fit in a datagram). The real question is not how to do DNS-SEC, but how soon, and then how to leverage it in real protocols. Will there be a reasonably comprehensive set of Internet integrated services that work *together* securely in a reasonable fashion, or are we still building the tower of Babel (now in software). A more trustworthy DNS would IMHO be a good foundation. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
On Wed, May 31, 2006 at 09:41:57AM +1000, James A. Donald wrote: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? The obvious solution is perhaps more difficult to deploy in an environment where loss of ubiquitous access trumps security gains. It takes years to *field* new infrastructure. When the designer calls the problem solved, the real work begins, or not, if the market is not yet ready for the solution. -- /\ ASCII RIBBON NOTICE: If received in error, \ / CAMPAIGN Victor Duchovni please destroy and notify X AGAINST IT Security, sender. Sender does not waive / \ HTML MAILMorgan Stanley confidentiality or privilege, and use is prohibited. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
On Wed, 31 May 2006, James A. Donald wrote: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? Phishing can mean a few different things. If by phishing you mean the stealing of passwords, then yes, SRP would help to eliminate that problem, but users could still be fooled into giving away their SRP passwords if the user interface for entering the password is convincingly imitated. Some people use phishing to refer to the online capture of identity-related information in general, in which case SRP falls far short of a complete solution. I think it's a difference in philosophy: some see passwords as the ultimate goal; some see passwords as one of many possible means to the ultimate end, which is identity theft. I'm working on Passpet, a password management tool that tries to address several of the big phishing-related problems including password capture and dictionary attack, and for the authentication part i chose SRP. So that's one place it's getting used, anyway. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Elizabethan traffic analysis
We tend to think of traffic analysis as a modern technique, but it's actually quite old. Here is a message from a spy, observing the activities of two of (English Queen) Elizabeth I's courtiers, whom he suspected of trying to manipulate her successor: many secret meetings are made between them, where, after serious consults, they dispatch messengers and packets of letters, this sometimes twice in a week. This was in 1602. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
James A. Donald wrote: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? I disagree here, I don't think this will stop phishing for many reasons. Please explain how it would. It will stop man-in-the-middle attacks on the protocol, but phishers aren't attacking the protocols themselves. It's still single-auth and I can still obtain the user password via phishing. Please correct me if I'm wrong but phishing is before this protocol will be accessed. if Mallory convinces Carol to log into a spoofed site that looks like Steve not running SRP, then u and x are obtained by Mallory. Mallory simply logs into Steve with U and X. In SRP what is preshared is g^x where x = H(s,p) where s is a salt and p is the password. p would be a weakness here because the user knows it, and in phishing, if the user knows it, the user is vulnerable. My 2 cents. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * http://www.securescience.net/ * ** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
Lance James wrote: James A. Donald wrote: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? I want to clarify, because by typing to fast, i think my variables may be confusing since I was reading the spec of SRP from two diff docs. u and x in my sentence was username and password not x being typical derived secret. what it should be is u and p. please note corrections. Thanks. I disagree here, I don't think this will stop phishing for many reasons. Please explain how it would. It will stop man-in-the-middle attacks on the protocol, but phishers aren't attacking the protocols themselves. It's still single-auth and I can still obtain the user password via phishing. Please correct me if I'm wrong but phishing is before this protocol will be accessed. if Mallory convinces Carol to log into a spoofed site that looks like Steve not running SRP, then u and x are obtained by Mallory. Mallory simply logs into Steve with U and X. In SRP what is preshared is g^x where x = H(s,p) where s is a salt and p is the password. p would be a weakness here because the user knows it, and in phishing, if the user knows it, the user is vulnerable. My 2 cents. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] -- Best Regards, Lance James Secure Science Corporation www.securescience.net Author of 'Phishing Exposed' http://securescience.net/home/news/phishingexposed.html ** * New IntelliFound Service 2 weeks free * * Real-Time Identity Surveillance Service* * http://www.securescience.net/ * ** - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
Quoting James A. Donald [EMAIL PROTECTED]: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? Patents. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
- Original Message - From: James A. Donald [EMAIL PROTECTED] Subject: Status of SRP The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? The problem is that you're attempting to treat the wrong aspect. Yes SRP verifies the server, but requiring even more work on the part of the client will not solve the problem. Attempting to use SRP to solve this problem is basically saying You must be this smart to be worth protecting. Joe - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
* James A. Donald: The obvious solution to the phishing crisis is the widespread deployment of SRP, but this does not seem to happening. SASL-SRP was recently dropped. What is the problem? There is no way to force an end user to enter a password only over SRP. That's why SRP is not effective against phishing (even the mimicry variant). In that regard, the password input field was a huge mistake. Fortunately, it doesn't matter because today, we must assume that the client is thoroughly compromised, which means that entering passwords over SRP isn't safe, either. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
[EMAIL PROTECTED] writes: I am also interested in Opportunistic Encryption. Even if it is not as secure as a manually configured VPN, I am willing to trade that for what it does provide. I have looked at setting up OpenSWAN in OE mode, but frankly it is daunting even for the reasonably geeky and far beyond any kind of mass implementation. Grab OpenVPN (which is what OpenSWAN should be), install, point it at the target system, and you have opportunistic encryption. Anytime I have recommended using STARTTLS to my sysadmin friends, they have always worried about breaking stuff and complained about needed expensive certs. Why do you need expensive certs? It's opportunistic encryption, you generate a self-signed cert on install and you're done. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
-- Ka-Ping Yee wrote: Phishing can mean a few different things. If by phishing you mean the stealing of passwords, then yes, SRP would help to eliminate that problem, but users could still be fooled into giving away their SRP passwords if the user interface for entering the password is convincingly imitated. SRP necessarily runs in the chrome, in the client software, not in the web page, therefore the chrome, should put up an image that cannot be convincingly imitated by html - for example, on windows, a non rectangular login page, as with paradox's keygen, or as with the infocard software, taking over the entire screen, including covering the taskbar, which an html page cannot do. In order to imitate that, the attacker would need control of the client machine I'm working on Passpet, a password management tool that tries to address several of the big phishing-related problems including password capture and dictionary attack, and for the authentication part i chose SRP. So that's one place it's getting used, anyway. Cannot find a web page that presents passpet. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG ybM860Mr+CSlXrrR8xph9v0B91GQWJBI8SAGwuFs 4B8M3YBCebHr5lGeEDBz+TIrbMLygWsXUEGxXWNj5 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
-- James A. Donald wrote: The obvious solution to the phishing crisis is the widespread deployment of SRP Lance James I disagree here, I don't think this will stop phishing for many reasons. Please explain how it would. It will stop man-in-the-middle attacks on the protocol, but phishers aren't attacking the protocols themselves. To be useful, SRP has to be in the browser chrome. Consider a typical e-gold phish : : You have just made a request to transfer all : : the funds in your account. Please click here : : www.e-golb.com/cancel and login to cancel : : this request if it was made by someone other : : than yourself Assume e-gold was using SRP login. The user would attempt to login to www.e-golb.com through SRP, and the login would fail. It's still single-auth and I can still obtain the user password via phishing. How? SRP never reveals the login. It is zero knowledge. Instead, both parties prove to each other than they know the secret, without revealing the secret. The only way you can phish the user is to get him to not use SRP. But if he is attempting to use SRP he is not typing the password into a web page, but into client software running on his own machine, which is going to look visibly different from any web page. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG bhZzlPU6DtnwH9s5+PxwPlwhgvD/8iFEI9LcuRXA 4x54cCglld16xbMxUa/22CBHVIxtb7yqM78rQ9Ul1 - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
-- Florian Weimer wrote: There is no way to force an end user to enter a password only over SRP. Phishing relies on the login page looking familiar. If SRP is in the browser chrome, and looks strikingly different from any web page, the login page will not look familiar. Fortunately, it doesn't matter because today, we must assume that the client is thoroughly compromised, which means that entering passwords over SRP isn't safe, either. That is an all purpose argument that is deployed selectively against some measures and not others. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG FngUFki/IKrJQzXmzcNmvTTH5ZAwHCQkTSIXkWVI 4wPX3iZ25iE0SC3Pk6sdr5enUTiKLhPd829ew/9kX - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
On Thu, 1 Jun 2006, James A. Donald wrote: SRP necessarily runs in the chrome, in the client software, not in the web page, therefore the chrome, should put up an image that cannot be convincingly imitated by html Sure, i agree. I only brought this up to point out that SRP alone doesn't solve the problem; it remains an open question how to best design a password entry field that defeats spoofing. You mentioned several techniques, and there are others, and so far we don't know what works best for most users. Passpet's strategy is to customize a button that you click. We are used to recognizing toolbar buttons by their appearance, so it seems plausible that if the button has a custom per-user icon, users are unlikely to click on a spoofed button with the wrong icon. Unlike other schemes, such as special-looking windows or a custom image shown with the login form, this strategy requires the user to directly interact with the customized UI element. The effectiveness of Passpet's approach is only hypothesized; it has never been formally tested, so i can't claim it works better. Cannot find a web page that presents passpet. See http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/ for the original description of the ideas. The design of Passpet is a bit more refined now and will be published at SOUPS 2006. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
