Re: Status of SRP
On Wed, 7 Jun 2006, John Brazel wrote: > What we really need is something similar to the built-in "remember > my password" functionality of current web browsers: the browser keeps > track of a login/password/certified (ie TLS certificate-backed) DNS name > tuple... [...] > The downside, of course, is that: > > a) It wouldn't handle password changing, > b) Some people use the same login and password *everywhere*, > c) Once you change browsers or computers, all bets are off (because the > new browser doesn't know anything about which passwords you use where). If you haven't looked at this yet, i think you'll find it interesting: http://usablesecurity.com/2006/02/08/how-to-prevent-phishing/ These design ideas are intended to address exactly the things you've just mentioned. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
On Thu, 1 Jun 2006, Jeffrey Altman wrote: > Solving the phishing problem requires changes on many levels: I agree. > (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. What do you think of the various trusted-path ideas that have been proposed? In particular i'm curious what you think of the solution i currently favour (the customized toolbar button), but some of the others certainly seem promising (such as PwdHash's special hotkey at the beginning of a password). > (2) Reducing the number of accounts and passwords (or other identifiers) > that end users need to remember. Password hashing is one way to deal with this. In Passpet's case, the password is generated by hashing a master secret with a label that you provide for each site. > (3) Secure mechanisms must be developed for handling enrollment and > password changing. With Passpet, you would click the button to fill in the password on a new account registration form, which generates a unique password for the site. To change your password, you would go to the site's account settings page, click the button to fill in your old password, edit the site label, then click the button again to get a new password. Does that address the issues you had in mind, or were you thinking of other situations? -- ?!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]
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, 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]
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]
Re: [Anti-fraud] Re: the limits of crypto and authentication
On Sun, 10 Jul 2005, Amir Herzberg wrote: > But... crypto and authentication, imho, are the best tools to prevent > such malware from being installed. I disagree. Limited authority is the best way to prevent such malware from being installed (and, if installed, from causing harm). The premise that all software can be divided into categories of "good" and "evil" is a deeply flawed foundation on which to build security. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: massive data theft at MasterCard processor
On Fri, 17 Jun 2005, Steven M. Bellovin wrote: > Designing a system that deflects this sort of attack is challenging. > The right answer is smart cards that can digitally sign transactions, > but that would require rolling out new readers to all the merchants. I was amazed to hear of the UK's fast progress in rolling out their Chip-and-PIN system. I would not have guessed that they could get about 85% of cardholders to switch and 75% of retail equipment upgraded by the end of 2004, only 15 months after the beginning of the rollout. http://www.chipandpin.co.uk/reflib/super_barometer_2004.pdf Naturally, conditions are different in the United States, but it's still an impressive result. -- ?!ng - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
