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]
Re: Status of SRP
On 5/30/06, Derek Atkins <[EMAIL PROTECTED]> wrote: 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. Seconded. When I was doing some software development, we investigated strong password solutions, and to my knowledge they were all under the shadow of patents. In the end, it didn't matter, since I was using it in a distributed IDS system, and users weren't necessarily going to be present, even at boot. For machine-to-machine authentication, they're irrelevant (assuming a good source of unpredictability). For everything but first-time authentication between the browser and the site, and key changes, they can be ignored in favor of cached keys (a la ssh) if you can design a UI that presents them in an easy-to-understand manner. Rumor has it that Vista will send every URL visited to Microsoft for vetting against a blacklist ostensibly to protect users against phishing*, which I suppose trades one problem for another, although for most people's concerns it's probably a win, since they're running a MS product in the first place. It can allegedly be turned off. [*] When it was announced that the low-cost Asian version of Windows would only be able to run a limited number of programs at once (I think it was four), MS's PR department described the limit as being there to "reduce confusion". That's either insulting to all Asian's intelligence, or everyone's, depending on how credulous you are. I wonder how much they get paid to come up with things like that. -- Scientia Est Potentia -- Eppur Si Muove Security "guru" for rent or hire - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of opportunistic encryption
-- James A. Donald: > > My understanding is that SSH when using GSS KEX does > > not cache the keys, which strikes me as a amazingly > > stupid idea, Victor Duchovni > 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. In an organization with hundreds of administrators managing tens of thousand of machines, what goes wrong with trusting your key store? And who administers Kerberos? Don't they have a problem with tens of thousands of machines? > Workable DNS-SEC exists, what lacks now is the will > and political muscle to make it happen. I was unaware of this. So I googled for DNSSEC. Reading the DNSSEC documents I found : : "In order to support the larger DNS message : : sizes that result from adding the DNSSEC RRs, : : DNSSEC also requires EDNS0 support ([RFC : : 671]). " and : : "its authentication keys can be authenticated : : by some trusted means out of band from the : : DNS protocol." This does not sound workable to me. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG N8PPaaHAyVJ5X84mwrNura/s/6xoxBy1I4SsvYnN 4dTYtTbKIKIX2zUmbNeTi6z5NYSRZW+LcplUU9tST - 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
-- 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
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]
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
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 > : : 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]
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
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
