Re: Status of SRP
-- Anne & Lynn Wheeler wrote: > part of x9.59 retail payment standard requires the > transaction to be authenticated. another part of the > x9.59 retail payment standard requires that the > account number in x9.59 retail payments can't be used > in non-authenticated transactions. it as been > recognized for a long time that a major source of > account financial fraud has been the data breaches > http://www.garlic.com/~lynn/subpubkey.html#harvest Have any merchants adopted the X9.59 standard? Is it in fact possible for a merchant to today take orders over X9.59? --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG SCLw5bENxW3GhAPjMCCFxAZNTWWplgH3XHfzZejK 4wUo1x4tRVdskoDX1ZgiomicCYwgwFPLepwR04i2a - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
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
James A. Donald wrote: The concept of trusted computing is an attempt to address this problem - each application has exclusive access to certain data, a trusted path to interact with the user, and the ability to prove to servers what code is being executed on the client. so they aren't exactly unrelated. re: http://www.garlic.com/~lynn/aadsm23.htm#45 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#53 Status of SRP the financial standards x9a10 working group had been given the requirement to preserve the integrity for all retail payments. the result was the x9.59 payment standards for all retail payments. http://www.garlic.com/~lynn/x959.html#x959 part of x9.59 retail payment standard requires the transaction to be authenticated. another part of the x9.59 retail payment standard requires that the account number in x9.59 retail payments can't be used in non-authenticated transactions. it as been recognized for a long time that a major source of account financial fraud has been the data breaches http://www.garlic.com/~lynn/subpubkey.html#harvest and resulting fraudulent use of account numbers ... this is somewhat my old posting on security proportional to risk http://www.garlic.com/~lynn/2001h.html#61 in effect, account numbers have been overloaded. on one hand, knowledge of account numbers have been sufficient for doing fraudulent transactions. as a result they have to be treated as shared secrets, kept confidential and never divulged. on the other hand, account numbers are required in a large number of business process as the fundamental cornerstone for transaction execution ... and are required to be widely available. as a result of these totally opposing requirements, i've periodically observed that the planet could be buried under miles of cryptography used in hiding account number, and it would still be unable to prevent leakage of account numbers. the x9.59 business rule recognizes this and changes the paradigm, eliminating the severe financial fraud vulnerability associated with divulging account numbers (and/or data breaches involving account numbers). another part of x9.59, in addition to providing for transaction digital signature as part of transaction authentication (and trying to close some of the barn door with the overloaded requirements placed on account numbers) was allowing for a second digital signature by the environment that the transaction originated in. this would provide the relying party additional information for performing risk assessment related to authorizing the transaction. so later when this software company wanted to come up with something for content providers, they hired the chair of the x9a10 financial standards working group to move to redmond to be director of development. for other drift on trusted computing ... there are capability based operating systems ... current example is capros ... which was spawned from eros, which was sort of spawned from keykos, which was spawned from gnosis ... recent post mentioning some capros, eros, keykos, gnosis, et all (and other related lore regarding secure and/or capability-based operating systems ... going back to deployments by commercial time-sharing service bureaus in the late 60s and their connections to some of the current efforts ... as well as connections to what i was doing as an undergraduate in the 60s) http://www.garlic.com/~lynn/2006k.html#37 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
Jeffrey Altman wrote: 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. 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, and if it ever spots the user entering said login/password into a different website, brings up some form of dialog alerting the user to a potential phishing attack. 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). J. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
Florian Weimer wrote: You mean something like remote attestation? I find it hard to believe that this capability is available today in a relatively open environment, on a platform supporting multiple applications developed by different applications. re: http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP http://www.garlic.com/~lynn/aadsm23.htm#50 Status of SRP i got involved in tracking down a virus/trojan like problem in the 70s on the internal network http://www.garlic.com/~lynn/subnetwork.html#internalnet basically if you are going to allow loading of stuff that can do its own execution w/o many safeguards ... you are going to be extremely vulnerable to numerous kinds of attacks. either you have to very tightly control what applications are loaded or possibly do a fixed function deployment that can support multiple different applications ... possibly based on some form of data driven architecture (i.e. the data specification possibly adapts the functional operation to different applications w/o requiring loading of executable code). we had done the AADS chip strawman was done this way ... basically single function operation w/o any ability to load executable code ... that was adaptable to a large number of different applications http://www.garlic.com/~lynn/x959.html#aads another possible solution is very strong partitioning of any loadable executable content that is allowed extremely limited/controlled capability. in the 60s as an undergraduate, i had done a lot with extremely controlled partitioning ... which i learned much later got used in various environments that had extremely high integrity requirements ... random drift http://www.nsa.gov/selinux/list-archive/0409/8362.cfm i had this discussion with the general manager of the business unit that included java and java virtual machine (when it was in its very early infancy) ... turns out that I had done some work with the person (general manager) nearly 20 years earlier in a different life. many of the modern generation of POS terminals are trying to cope with this problem ... getting all sorts of frequent application downloads of various kinds ... and still attempting to operate within constraints of their trusted security module implementation. basically if finread http://www.garlic.com/~lynn/subpubkey.html#finread is countermeasure to widely acceptable PC vulnerabilities (many that arise because of the ease and common practice of loading executable content) ... then if you deploy such a finread terminal that is operated using similar conventions ... then it will acquire similar vulnerability characteristics (as the environment that it is suppose to be a countermeasure for). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
* Anne & Lynn Wheeler: > Florian Weimer wrote: >> FINREAD is really interesting. I've finally managed to browse the >> specs, and it looks as if this platform can be used to build something >> that is secure against compromised hosts. However, I fear that the >> support costs are too high, and that's why it hasn't caught on in >> retail online banking. > > if they can build a $100 PC ... you think that they could build a > finread terminal for a couple bucks. sometimes there are issues with > volume pricing ... you price high because there isn't a volume and > there isn't a volume because you price high. The problem is not hardware costs, but support costs. You really don't want to outsource this to the cheapest call center in the world. Even relatively simple changes like the indexed TAN rollout are rather expensive as a result. > there is one issue missing from the actual FINREAD specification. > > when we were doing X9.59 financial standard ... we allowed for a > digital signature for authentication as well as for a digital > signature from the environment that the transaction was performed > in. the issue from a relying party standpoint ... is what assurances > do they have as to the actual environment that a transaction was > executed in. consumers could claim they were using a FINREAD terminal > when they weren't. counterfeit FINREAD terminals could be out in the > wild. You mean something like remote attestation? I find it hard to believe that this capability is available today in a relatively open environment, on a platform supporting multiple applications developed by different applications. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
James A. Donald wrote: > -- > Jeffrey Altman wrote: >> 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. > > With SRP, the web site cannot be spoofed, for it must > prove it knows the user's secret passphrase. James, SRP can only prevent spoof's of successful authentications and it can only prevent spoof's when it is actually used. It cannot prevent spoof's of unsuccessful authentications and that is where a huge part of the problem lies. Consider the reaction of many individuals when they receive a page that indicates that their username and/or password are incorrect? Sites that offer the common secret question(s) can be spoofed. The attacker spoof's sits in the middle, captures the question from the real site, the answer from the user, and if the real site says that the new password is being sent, puts up a new page indicating that the password should be changed online along with prompts for private information that the attacker wants. Stopping phishing with successful authentication is not even half the problem. Jeffrey Altman smime.p7s Description: S/MIME Cryptographic Signature
Re: Status of SRP
Anne & Lynn Wheeler wrote: if they can build a $100 PC ... you think that they could build a finread terminal for a couple bucks. sometimes there are issues with volume pricing ... you price high because there isn't a volume and there isn't a volume because you price high. re: http://www.garlic.com/~lynn/aadsm23.htm#49 Status of SRP another aspect was that there was a program in the past to give away smartcards and card readers to consumers as part of doing smartcard financial transactions. the issue at the time was that deployed support for pc/sc standard only supported pc serial port interfaces ... and therefor the free card reader was a serial port device. there was an ensuing disaster as consumers tried to get the serial port device operational ... lots of stories of BSOD, having to re-install everything from scratch, etc. as the dust was settling, there was a quickly spreading opinion that smartcards (or at least smartcard readers) were not viable in the consumer market segment. it was during this period that m'soft even canceled its smartcard operating system project. recent post discussing the subject: http://www.garlic.com/~lynn/aadsm23.htm#43 Spring is here - that means Pressed Flowers - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
Florian Weimer wrote: FINREAD is really interesting. I've finally managed to browse the specs, and it looks as if this platform can be used to build something that is secure against compromised hosts. However, I fear that the support costs are too high, and that's why it hasn't caught on in retail online banking. if they can build a $100 PC ... you think that they could build a finread terminal for a couple bucks. sometimes there are issues with volume pricing ... you price high because there isn't a volume and there isn't a volume because you price high. there is one issue missing from the actual FINREAD specification. when we were doing X9.59 financial standard ... we allowed for a digital signature for authentication as well as for a digital signature from the environment that the transaction was performed in. the issue from a relying party standpoint ... is what assurances do they have as to the actual environment that a transaction was executed in. consumers could claim they were using a FINREAD terminal when they weren't. counterfeit FINREAD terminals could be out in the wild. part of the x9.59 financial standard looked at the assurance/integrity that a relying party might have with regard to the actual authentication ... one factor, two factor, three factor ... and the actual assurance/integrity of the associated factors (or conversely, how vulnerable were the factors to compromise). this somewhat led into also having to consider the assurance/integrity environment that the authentication took place in (and what assurances would a relying party have with regard to the environment). part of it has been some past inclination to just specify some standard ... w/o regard to how a relying party might actual have assurances as to whether some standard or another was being followed in an open environment (and considering threat scenarios that might involve compromise/impersonation of various components). for instance, there was a recent scenario in the UK where crooks were impersonating maint. people and were updating secure POS terminals with compromised components. - 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
* Anne & Lynn Wheeler: > 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. You say that as if that assumption were unrealistic. Transaction-rewriting malware is out in the wild. 8-( FINREAD is really interesting. I've finally managed to browse the specs, and it looks as if this platform can be used to build something that is secure against compromised hosts. However, I fear that the support costs are too high, and that's why it hasn't caught on in retail online banking. > 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 interesting part is that it's possible to create an application that runs exclusively on the trustworthy component and presents the actual transaction data to the user before it is signed. Previous card readers/smart card combinations relied on host software to provide the display contents, without any way to check that it matches the blob that was to be signed. Of course, it's still possible to develop a FINREAD application that behaves that way, perhaps in order to cut down development costs. As usual, just because it's FINREAD, it's not automatically secure (and a "transparent mode" exists as well). - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
* Ka-Ping Yee: > 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. I'm not sure if this can't be defeated by something like a "Choose a new funny icon for your security button!" offer. 8-( However, this points to a more general problem: We have no real-world studies how users make their day-to-day trust decisions when using the Internet. For example, if I need to judge the trustworthyness of a web page, a large factor is the way I got there. If it was a link from an email message that looks like spam, or something that was returned by a search engine, I'm rather sceptical. This is why those "80% can't tell a phishing page apart from the real one" web-base studies are quite worthless. They simply do not present enough context. | The field for entering your master password isn't labelled "Enter | your password:" - instead, it's labelled "Enter Betty's secret:". | Since the persona differs from user to user, it's hard to even ask | for the password because the spoofer doesn't know what to call it. I suppose this can be circumvented if you you use email to lure the victim to the fake web page and have obtained names matching the email addresses. Even if you want to present the full address to the victim, you can buy this data from direct marketing companies, I think. - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
-- Lance James wrote: > Here's where SRP fails: > > 1) SSL is built into the browser - doesn't stop > phishers SSL protects true names, SRP protects true relationships. Protecting true names turned out to be not very useful. > "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". They set up their SRP account through the chrome, not through a webpage. This attack fails to mimic what is routine. Phishing relies on mimicry and habit. The poorer the mimicry, the less people are likely to fall for it. Certainly some people will fall for it, there is a sucker born every minute, but right now we are seeing phishing attacks that quite sophisticated people fall for. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG 7hBodKZ++GbmAsbf7YHZGQsErgEpvrEN+jMzkRVJ 4jFzcd0zA2X0mdrrP52Wb9NZEOfARFgb0RMwwJCL7 - The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]
Re: Status of SRP
-- Jeffrey Altman wrote: > 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. With SRP, the web site cannot be spoofed, for it must prove it knows the user's secret passphrase. Now Wagner keeps complaining that the users are complete morons, who could be taken in by a very shoddy spoof, and no doubt that is true, but right now it is possible to make a very good spoof, and that can be fixed. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG K0DkzvBcnUAkU1t725Cg9Fmh6awjA9b9S8SmmanA 4HYHXPVEWxmojVTOmRDh7L/Eu6KRWMz3WCh5tL2Eq - 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]
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 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]
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 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 SRP
* James A. Donald: > -- > 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. All browsers I've tested permit overriding chrome in the default configuration as a deliberate design decision. 8-( >> 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. 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. - 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
-- 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
-- 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 - 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: > 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 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
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
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
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
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: 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]
