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? Unfortunately, SRP is not the solution to the phishing problem. The phishing problem is made up of many subtle sub-problems involving the ease of spoofing a web site and the challenges involved in securing the enrollment and password change mechanisms. SRP would allow a client to know that a service is in fact the correct service when the authentication succeeds. However, it would not help in the situation when the authentication fails. This could be because the user is not sure of what the password is or even sure which account name was being used. Solving the phishing problem requires changes on many levels: (1) Some form of secure chrome for browsers must be deployed where the security either comes from a trusted desktop or by per-user customizations that significantly decrease the chances that the attacker can fake the web site experience. (Prevent the attacker from replicating the browser frame, toolbars, lock icons, certificate dialogs, etc.) (2) Reducing the number of accounts and passwords (or other identifiers) that end users need to remember. With a separate identifier for each and every web site it is no surprise that my extended family can never remember what was used at each site. Therefore, it is not much of a surprise when a site says that the authentication failed. (3) Secure mechanisms must be developed for handling enrollment and password changing. Only then can we truly address the phishing problem. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Status of opportunistic encryption
On Thu, Jun 01, 2006 at 01:47:06PM +1200, Peter Gutmann wrote: Grab OpenVPN (which is what OpenSWAN should be), install, point it at the target system, and you have opportunistic encryption. Forgive my doltishness, but could you expand on that just a bit, please (or point at the right place in the docs)? I've used openvpn to set up dedicated tunnels, but it isn't immediately obvious to me how it would be configured to do opportunistic encryption. -- Kent Crispin [EMAIL PROTECTED]p: +1 310 823 9358 f: +1 310 823 8649 [EMAIL PROTECTED] SIP: [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
Here's where SRP fails: 1) SSL is built into the browser - doesn't stop phishers 2) Chrome or no chrome good luck getting it in there and having every user understand it. 3) Traditional phishing works, but if you force them to change, the malware propagation will only be higher than it is now, and I can give you the numbers on how much data is stolen with malware (over 2 million credit cards have been acquired since January via trojan software - how do I know this, I monitor their blind drops constantly and one group's daily take is over 150 megs of credentials on average. SRP suffers from a rollback attack, chrome or no chrome - humans don't know enough about this, and if the phisher does: Hi, we're having a problem with your account system as our SRP database was corrupted, please login through the webpage to verify your information and reset your SRP account to working order. Surprisingly, many would fall for this. My 2 cents. -Lance James A. Donald wrote: -- 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 -- 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]
Trusted path (was: status of SRP)
On Thu, 1 Jun 2006, James A. Donald wrote: 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. I think you might be overestimating the attentiveness and discrimination abilities of most people. A scheme that makes a real login form *technically* discriminable from a fake login form (i.e. there is some rule you can follow that will give you 100% accuracy as to which is which, such as check for presence of the taskbar) will not necessarily achieve a 100% fraud prevention rate because the rule will not always be followed. Different kinds of discrimination will yield different rates of success. Some rules are more difficult to follow than others; some rules are easier to forget than others. Depending on the scheme, even a highly technical user such as you or me might fail to notice a spoof when we're in a hurry to complete the transaction or we're distracted by other things. This is the trusted-path problem. Some examples of proposed solutions to trusted-path are: - Dim the entire screen. - Use special window borders. - Use flashing window borders. - Use specially shaped windows. - Attach a warning label to all untrusted windows. - Display a customized word or name. - Display a customized image. - Overlay a semitransparent customized image. - Require the user to press a secure attention key. - Require the user to click a customized button. I'm interested in people's thoughts on what works better or might work better. (Feel free to add to the list.) -- ?!ng - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
On Thu, 1 Jun 2006, Florian Weimer wrote: That is an all purpose argument that is deployed selectively against some measures and not others. If you've deployed two-factor authentication (like German banks did in the late 80s/early 90s), the relevant attacks do involve compromised customer PCs. 8-( Just because you can't solve it with your technology doesn't mean you can pretend the attacks don't happen. You're both right. The problem is that we are talking about solutions but haven't yet agreed on a threat model to discuss. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
-- Ka-Ping Yee wrote: 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. This seems like a promising tactic, since a first step in any process is look for the button. If user does not see the button, will be troubled, will stop and think. Any customization is an effective anti phishing measure: Observe that eBay resists phishing by starting its emails by addressing each user by logon name, and Amazon resists phishing by extensively customizing its web page to each user - by supplying non cryptographic evidence of an existing relationship. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG O37xiq0aPJeqGc7fQTWWTY85hPPktIPGAwbDifVD 4bDTmZTlI9gWsmLu9xhSdisgc26xogVtQOnIi5/DI - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
-- Ka-Ping Yee wrote: 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-ph ishing/ This seems like a highly effective cure for phishing, and one that can be implemented on the individual level - and unlike my proposed solution, your solution does not require competent web masters, who tend to be in short supply. When do you hope to release an actual working passpet? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 2XJ1hBQB4Lh88oartvxNB9R47imTGm9ijr/vCQ5S 4tw2qTJbgf91cRjr3IilUO+alJWC4QViGoIqSUjWI - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: Status of SRP
Florian Weimer wrote: If you've deployed two-factor authentication (like German banks did in the late 80s/early 90s), the relevant attacks do involve compromised customer PCs. 8-( Just because you can't solve it with your technology doesn't mean you can pretend the attacks don't happen. EU finread terminal was countermeasure to (widely held impression that) PCs are extremely vulnerable to compromise. card authentication required pin entry to work ... and finread terminal had its own PIN-pad distinct the vulnerable PC keyboard. orientation was towards transaction authentication ... with the finread terminal also having its own display of what was being authentication. the transaction authentication orientation was countermeasure to session authentication orientation where PC compromises could operate within the boundaries of any authenticated session. part of thread in sci.crypt mentioning finread terminal as countermeasure to (widely held view of) the ease of PC compromises http://www.garlic.com/~lynn/2006k.html#46 Keylogger resistance http://www.garlic.com/~lynn/2006k.html#52 Keylogger resistance - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
