Re: once more, with feeling.
Peter Gutmann wrote: If this had been done in the beginning, before users -- and web site designers, and browser vendors -- were mistrained, it might have worked. Now, though? I'm skeptical. For existing apps with habituated users, so am I. So how about the following strawman: Take an existing browser (say Firefox), brand it as some special- case secure online banking browser, and use the new developments solution above, i.e. it only talks mutual-auth challenge-response crypto and nothing else. At that point you've reduced Reformat user and reinstall browsing habits to Train users to only use safe-browser when they do their banking, i.e. 'Never enter banking details using anything other than safe-browser'. Even if you only get a subset of users doing this, it's still a massive attack surface reduction because you've raised the bar from any idiot who buys a phishing kit to having to perform a man-in-the-browser attack. We've been debating this a lot at Google lately. One argument that I have increasing sympathy with is that SSO (or if you want to be modern, federated login) provides an opportunity to change the playing field sufficiently that we can reprogram users to be less vulnerable to phishing - or just switch them to protocols that make phishing irrelevant. To that end, we've released some usability research... http://google-code-updates.blogspot.com/2008/09/usability-research-on-federated-login.html Obviously the end game here is that the user only has to protect his login to a small number of sites - i.e. those that provide the IdP. Once we get there, perhaps users can be persuaded to authenticate to those sites using something stronger than username/password. A sidenote that provides me with some amusement: although the modern trend is towards using OpenID, no-one wants to use it in the mode it is designed for, i.e. where the user can pick any old IdP and the RP will just trust it. In practice where we seem to be headed is that RPs will trust some smallish number of trusted IdPs. This is, of course, exactly what the Liberty guys have been working on all along. I predict that over time, most of the elements of Liberty will be incorporated into OpenID. Which makes me think that if Liberty had done what it claimed to be doing when it started, i.e. be a community-based, open-source-friendly protocol suite, it would have worked much better. Cheers, Ben. -- http://www.apache-ssl.org/ben.html http://www.links.org/ There is no limit to what a man can do or how far he can go if he doesn't mind who gets the credit. - Robert Woodruff - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: For existing apps with habituated users, so am I. So how about the following strawman: Take an existing browser (say Firefox), brand it as some special- case secure online banking browser, and use the new developments solution above, i.e. it only talks mutual-auth challenge-response crypto and nothing else. At that point you've reduced Reformat user and reinstall browsing habits to Train users to only use safe-browser when they do their banking, i.e. 'Never enter banking details using anything other than safe-browser'. Even if you only get a subset of users doing this, it's still a massive attack surface reduction because you've raised the bar from any idiot who buys a phishing kit to having to perform a man-in-the-browser attack. We did a version of this for CEAS this year (paper here: http://www.parc.com/research/publications/details.php?id=6496). I agree, I think it's not hard to come up with an architecture that increases user security, while reducing the amount they have to learn. Though, as per Perry's comment, you do need to be able to say that *some* (not all) of the software on your machine is not totally borked... (an interesting question is: how much, and what). --Diana - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Combining several replies into one... Nicolas Williams [EMAIL PROTECTED] writes: On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote: The major obstacle is that the government would want a strong binding between sim cards and true names, which is no more practical than a strong binding between physical keys and true names. I've a hard time believing that this is the major obstacle. [...] First, there's a business model problem. Every one wants in: the cell phone manufacturer, the software developer, the network operators, and the banks. With everyone wanting a cut of every transaction done through cell phones the result would likely be too expensive to compete with credit cards, even after accounting for the cost of credit card fraud. In my experience that's the brontosaurus in the room. There are vendors out there that'll do cellphone auth (basic SMS-based out-of-band transaction authorisation), the technology's in place, the problem is that once everyone has taken their cut it's no longer economical. To some extent the technology still sucks quite a bit (e.g. RSA's SMS-based system takes the bank-side information Request authorisation for transfer of $10,000 from your bank account to the bank account of J.Random Retailer and turns it into Enter the following PIN to unlock all further debits from your account until it's empty), but we're getting there. The killer is the cost involved. Access to the mobile networks is expensive enough that I've seen solutions in some countries like buying SMS capacity in bulk from foreign providers (it's cheaper to send the texts from a provider on the other side of the world than to do it locally) to the extreme step of setting up (or perhaps buying up) your own cellular network. James A. Donald [EMAIL PROTECTED] writes: There is always the give-your-password-over-the-phone attack, but the fact that phishers seeking WoW gold actually have to use the give-your-password- over-the-phone attack against WoW players shows the potency of a deliberately non standard, difficult to forge, user interface. Can you describe the WoW interface? It sounds like they've taken advantage of the greenfields approach and built something different that's secure from the start, but I'm not familiar with how it works. We need a similarly concise yet precise statement of what is wrong with the sort of things we are now doing - a list of principles of cryptography that working systems exemplify, and failed systems violate. It's already been done, in situation-specific ways: Marcus Ranum's Six Dumbest Ideas in Computer Security, http://www.ranum.com/security/computer_security/editorials/dumb/index.html Microsoft/Scott Culp's Ten Immutable Laws of Security, http://technet.microsoft.com/en-us/library/cc722487.aspx My own Ten Inescapable Truths of Security UI, http://www.cs.auckland.ac.nz/~pgut001/pubs/stupid.pdf (last three slides) IanG [EMAIL PROTECTED] writes: I think if there is a lot of money in it, there are some innovative solutions to making the obvious advice easier. I particularly like the Dutch central bank's approach here: https://financialcryptography.com/mt/archives/001059.html ... if you can stand the clickfest that's required to get there with FF3 (sigh). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Leichter, Jerry [EMAIL PROTECTED] writes: The sitation today is (a) the decreasing usefulness of passwords - those anyone has a chance of remembering are just to guessable in the face of the kinds of massive intelligent brute force that's possible today and (b) the inherently insecure password entry mechanisms that we've trained people to use. It's actually not that bad, we have some really good password managers that can take care of this for us, alongside quite a bit of research from HCI people that examine their effectiveness. By password manager I mean one that generates a strong password for you and supplies it as required, not the noddy managers built into things like web browsers, look at something like Roboform for an example of what I mean. The problem is that I don't know of any application that natively uses them, there are between half a dozen and a dozen Firefox plugins and third-party apps (it varies over time) that all provide enhanced password-handling capabilities but the browser itself still has the incredibly clunky 1.0 manager that it's always had (not specifically picking on FF here, all the others are just as bad, the difference is that FF has a pile of functioning plugins and usability research that demonstrate how to get it right). The problem isn't with passwords, it's with developers: Passwords are insecure because developers have chosen to make them insecure. We have mechanisms to address a lot of the problems with passwords but no-one ever uses them. Even suggesting some of these things is hard ehough, the response to What about using security measure X which addresses problem Y isn't to use measure X but to find some obscure corner case where X won't work, declare the problem unsolveable, and keep on doing the same thing that already didn't work the last 100 times we tried it. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Leichter, Jerry wrote: The problem is what that something else should be. Keyfobs with one-time passwords are a good solution from the pure security point of view, but (a) people find them annoying; (b) when used with existing input mechanisms, as they pretty much universally are, are subject to MITM attacks. The equivalent technology on a USB plugin is much easier on the user in some circumstances, but is subject to some bad semantic attacks, as discussed here previously. Also, it's not a great solution for mobile devices. DoD/government uses smartcards, but that's probably not acceptable to the broad population. There's been some playing around with cellphones playing the role of smartcard, but cellphones are not inherently secure either. Cellphones are not inherently secure, but *could* be inherently secure. Each cellphone sim card has a unique identity. It is possible to guarantee that a message goes to or from a cellphone containing a particular sim card - but present phone software provides no means to do this. If a cellphones has nfc communications capable of talking to a pc, then the whole interaction could be made painlessly automatic - touch your cellphone to the pc nfc sensor to login to the website, touch it to the security door to unlock the security door, touch it to the cash register, observe the indicated payment on the cellphone screen, and press OK, touch it to the screenless, keyboardless atm, and the interaction comes up on your phone screen instead of the ATM screen, touch cellphones to pay money from one individual to another. The major obstacle is that the government would want a strong binding between sim cards and true names, which is no more practical than a strong binding between physical keys and true names. Absent useful cellphone software, passwords must suffice. With a limit on the number of guesses before people get locked out, passwords *do* suffice - but then we need a means to unlock the account, and a means of password recovery. Although cellphones and email are insecure, a use once short lived password emailed or instant messaged to the user is secure enough. Trouble is, what happens if the user's email account is stolen? I had this problem. I was using my hotmail account as the password recovery account for various high value domain names. Someone called up hotmail's password recovery, and human engineered a password reset out of the hotmail staff, and then used email based password recovery to seize my domain names. I eventually got them back, using reset passwords snail mailed to my physical post office box, and now the email account associated with my domain names is at a service that provides no password recovery mechanism - and therefore provides an attacker with a very large number of opportunities to guess, requiring an insanely strong password. Snail mail to a post office box is a secure password reset mechanism, short of a well timed physical attack on the post office. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: The problem is that the default has always been to be insecure, and there's no effective way to get people to move to the secure non-default, or at least none that isn't relatively easily circumvented by a bit of creative thinking and/or social engineering. If the user is used to logging in by a user interface that is not easy for forge remotely - click on bookmark to bring up a user interface that is difficult to remotely forge - then this does indeed work. There is always the give-your-password-over-the-phone attack, but the fact that phishers seeking WoW gold actually have to use the give-your-password-over-the-phone attack against WoW players shows the potency of a deliberately non standard, difficult to forge, user interface. WoW security does not stop phishing, but it makes phishers work for their money. WoW keeps telling users never give your password to another person, no one at WoW will ever ask you for your password. Obvious advice, easy to understand and follow. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
On Mon, Sep 22, 2008 at 08:59:25PM -1000, James A. Donald wrote: The major obstacle is that the government would want a strong binding between sim cards and true names, which is no more practical than a strong binding between physical keys and true names. I've a hard time believing that this is the major obstacle. We all use credit cards all the time -- apparently that's as good a strong binding between [credit] cards and true names and as the government needs. (If not then throw in cameras at many intersections and along freeways, add in license plate OCR, and you can tie things together easily enough. Wasn't that a worry in another recent thread here?) More likely there are other problems. First, there's a business model problem. Every one wants in: the cell phone manufacturer, the software developer, the network operators, and the banks. With everyone wanting a cut of every transaction done through cell phones the result would likely be too expensive to compete with credit cards, even after accounting for the cost of credit card fraud. Credit card fraud and online security, in any case, are pretty low on the list of banking troubles these past few weeks, and not without reason! Second, there's going to be standard issues. Third the nfc technology has to be commoditized. Fourth there's cost of doing an initial rollout of the POS nfc terminals and building momentum for the product. Once momentum is there you're done. And there's risk too -- if you fail you lose your investment. ... Trouble is, what happens if the user's email account is stolen? Touble is: what happens if the user's cell phone is stolen? Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
James A. Donald [EMAIL PROTECTED] writes: If the user is used to logging in by a user interface that is not easy for forge remotely - click on bookmark to bring up a user interface that is difficult to remotely forge - then this does indeed work. It might have been secure enough back in the days before almost every machine was infected by things like drive-by malware. Now that the hardware the user is on can no longer be trusted, this would only raise the bar slightly, and cause the bad guys, who already own half the machines on the net, to work a few more hours. I won't say such a thing would be bad if it already existed, but it seems like it would no longer be enough. Perry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
On Sun, 21 Sep 2008, Eric Rescorla wrote: | - Use TLS-PSK, which performs mutual auth of client and server | without ever communicating the password | Once upon a time, this would have been possible, I think. Today, | though, the problem is the user entering their key in a box that is | (a) not remotely forgeable by a web site that isn't using the | browser's TLS-PSK mechanism; and (b) will *always* be recognized by | users, even dumb ones. Today, sites want *pretty* login screens, | with *friendly* ways to recover your (or Palin's) password, and not | just generic grey boxes. Then imagine the phishing page that | displays an artistic but purely imaginary login screen, with a | message about NEW! Better naviation on our login page! | | This is precisely the issue. | | There are any number of cryptographic techniques that would allow | clients and servers to authenticate to each other in a phishing | resistant fashion, but they all depend on ensuring that the | *client* has access to the password and that the attacker can't | convince the user to type their password into some dialog | that the attacker controls. That's the challenging technical | issue, but it's UI, not cryptographic. The sitation today is (a) the decreasing usefulness of passwords - those anyone has a chance of remembering are just to guessable in the face of the kinds of massive intelligent brute force that's possible today and (b) the inherently insecure password entry mechanisms that we've trained people to use. Perhaps the only solution is to attack both problems at the same time: Replace passwords with something else, and use a different, more secure input mechanism at the same time. The problem is what that something else should be. Keyfobs with one-time passwords are a good solution from the pure security point of view, but (a) people find them annoying; (b) when used with existing input mechanisms, as they pretty much universally are, are subject to MITM attacks. The equivalent technology on a USB plugin is much easier on the user in some circumstances, but is subject to some bad semantic attacks, as discussed here previously. Also, it's not a great solution for mobile devices. DoD/government uses smartcards, but that's probably not acceptable to the broad population. There's been some playing around with cellphones playing the role of smartcard, but cellphones are not inherently secure either. There's also the related problem of scalability to multiple providers: I only need one DoD card, which might be acceptable, but if every secure web site wants to give me their own, I have a problem. Of course, various federated identity standards are already battling it out, but uptake seems limited. Besides, that can only be one element of the solution - if I use a traditional password to get to my federated identity token, I've made the old problem much worse, not better. Some laptops and keyboards and even encrypted USB memory sticks are getting fingerprint scanners as standard hardware. *If* these actually work as advertised - not a good bet, based on history so far - these could be an interesting input mechanism. Since there are no expectations today that the fingerprint data will be available to any web site that asks, one could perhaps establish a standard for controlling this in an appropriate way, with a built-in, unforgeable display. With microphones and, increasingly, cameras as widely-available components, one might define a similar special input mode around them and look to voice or face recognition. Or maybe we could even leverage the increasing interest in special outside-the-main-OS basic displays one sees on laptops. (I'm sure it just thrills Microsoft to see Dell putting a tiny Linux implementation in each laptop) These are all just possibilities, and whether any of them (or some other approach) actually gains broad acceptance is, of course, totally up in the air. Right now, while in the aggregate the problems with ID theft are bad and getting worse, relatively few individuals feel the pain, nor is there much in the way to offer them. Until one or the other of these changes - and most likely, both - the old password in some window or another model will likely stick around. -- Jerry - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
On Thu, 18 Sep 2008 17:18:00 +1200 [EMAIL PROTECTED] (Peter Gutmann) wrote: - Use TLS-PSK, which performs mutual auth of client and server without ever communicating the password. This vastly complicated phishing since the phisher has to prove advance knowledge of your credentials in order to obtain your credentials (there are a pile of nitpicks that people will come up with for this, I can send you a link to a longer writeup that addresses them if you insist, I just don't want to type in pages of stuff here). Once upon a time, this would have been possible, I think. Today, though, the problem is the user entering their key in a box that is (a) not remotely forgeable by a web site that isn't using the browser's TLS-PSK mechanism; and (b) will *always* be recognized by users, even dumb ones. Today, sites want *pretty* login screens, with *friendly* ways to recover your (or Palin's) password, and not just generic grey boxes. Then imagine the phishing page that displays an artistic but purely imaginary login screen, with a message about NEW! Better naviation on our login page! If this had been done in the beginning, before users -- and web site designers, and browser vendors -- were mistrained, it might have worked. Now, though? I'm skeptical. --Steve Bellovin, http://www.cs.columbia.edu/~smb - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
At Sat, 20 Sep 2008 15:55:12 -0400, Steven M. Bellovin wrote: On Thu, 18 Sep 2008 17:18:00 +1200 [EMAIL PROTECTED] (Peter Gutmann) wrote: - Use TLS-PSK, which performs mutual auth of client and server without ever communicating the password. This vastly complicated phishing since the phisher has to prove advance knowledge of your credentials in order to obtain your credentials (there are a pile of nitpicks that people will come up with for this, I can send you a link to a longer writeup that addresses them if you insist, I just don't want to type in pages of stuff here). Once upon a time, this would have been possible, I think. Today, though, the problem is the user entering their key in a box that is (a) not remotely forgeable by a web site that isn't using the browser's TLS-PSK mechanism; and (b) will *always* be recognized by users, even dumb ones. Today, sites want *pretty* login screens, with *friendly* ways to recover your (or Palin's) password, and not just generic grey boxes. Then imagine the phishing page that displays an artistic but purely imaginary login screen, with a message about NEW! Better naviation on our login page! This is precisely the issue. There are any number of cryptographic techniques that would allow clients and servers to authenticate to each other in a phishing resistant fashion, but they all depend on ensuring that the *client* has access to the password and that the attacker can't convince the user to type their password into some dialog that the attacker controls. That's the challenging technical issue, but it's UI, not cryptographic. -Ekr - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
IanG [EMAIL PROTECTED] writes: Any evidence of that? [People buying certs using stolen credit cards] I don't know if anyone tracks the exact count (apart from the 2005 figure of (at least) 450 recorded incidents of secure phishing) but every now and then you get reports of particular ones that stand out, e.g. the Sunbelt discussion of the Gromozon distributors signing their malware, http://www.haloscan.com/comments/alexeck/6460991926610320702/ (the cert purchase was eventually traced back to a victim in Florida)... sorry, I don't catalogue them all, just watch them drift by every now and then and that one came to mind. In fact didn't our esteemed moderator mention running into one of these via spammed email just a few months back? In any case with the assistance of services like http://scanlab.name/ for the ID and any one of the incorporation brokers operating in the US (I particularly like the appropriately-named http://www.startanamericancompany.com/, you can do it for far less via US brokers but then if you're paying with soemone else's credit card cost isn't really an issue) how long do you think it'd take to create an official US corporation that qualifies for an EV cert? I think the main reason we haven't seen more of this is: - There's no need for it, usability evaluation tests have shown that EV certs have no effect on security so there's no point in going to the trouble (cybercrooks are cheapskates). - It's much easier to use an exploit toolkit like MPACK or whatever to hit an EV-certified site for a genuine organisation than it is to bother with your own EV cert. Since an EV cert only says that the CA did a little bit more than almost no checking at all of credentials but doesn't tell you anything about the site, the easiest way to get an EV cert is to use someone else's (AV vendors report peaks of up to 10,000 fresh malware infection sites via legit compromised servers a day, which is bad news for the only enter your credit card details on sites you trust education effort). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Dirk-Willem van Gulik [EMAIL PROTECTED] writes: As to technical options to accomplish this The mechanisms for this actually already exist, they're just not used. First of all, you need to admit that you have a problem: SSL certs by themselves are more or less useless in providing assurance, the phishers are buying genuine CA-issued certs for soundalike domains using stolen credit cards just as easily as legit sites are buying certs for genuine domains, and no amount of signature checking and CRLs and other PKI paraphernalia will fix that. As Matt Blaze once said, A commercial CA will protect you from fraud by anyone whose money it refuses to accept, which was meant tongue-in-cheek at the time but given current practice by phishers that's exactly what a commercial CA will do, and no more. It's only once developers have accepted this that you can start looking for a real solution: - Use TLS-PSK, which performs mutual auth of client and server without ever communicating the password. This vastly complicated phishing since the phisher has to prove advance knowledge of your credentials in order to obtain your credentials (there are a pile of nitpicks that people will come up with for this, I can send you a link to a longer writeup that addresses them if you insist, I just don't want to type in pages of stuff here). - Implement key-continuity at the client, i.e. warn if submitting a password or credit card number to a site you've never visited before; display the password in cleartext if submitting over a non-SSL connection (this is better than any explicit warning); (insert standard list, I have a whole pile of these, including responses to objections). - Use a service like Perspectives, http://www.cs.cmu.edu/~perspectives/index.html, to catch here-today-gone- tomorrow phishing sites (this is actually a service that someone like Google could provide, they crawl the web anyway so keeping track of how long a server key's been in use should be a relatively minor change to the existing process. Anyone from Google security reading this list?). - ... and many more, I won't list them all here. So it's a two-step process, the first of which is to admit that you have a problem. As EV certs have shown, we haven't really even reached that first step yet. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Dirk-Willem van Gulik wrote: ... discussion on CA/cert acceptance hurdles in the UI I am just wondering if we need a dose of PGP-style reality here. We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst they all appear use the same technology - the assurances, UI, operational regimen, 'investment' and user expectations are way different: ^^^ I seriously doubt that even a single digit percentage of end users out on the internet know anything about the different types of certificates used in SSL/TLS and what they mean. I know none of my family (other than my wife: but given she worked for a large CA doing authentication and verification) knows what SSL really means never mind what the different types of cert are supposed to indicate and what to do about them, yet they buy stuff on the internet. It doesn't mean they are ignorant it is just the normal case. So my take is that it is pretty much impossible to get the UI to do the right thing - until it has this information* - and even then you have a fair chunk of education left to do :). Even if you got the UI to do the right thing it still doesn't mean anything real about trust all it really means is how much money was invested in getting the cert and setting up the correct information about the company identity behind it. -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
... discussion on CA/cert acceptance hurdles in the UI I am just wondering if we need a dose of PGP-style reality here. We're really seeing 3 or 4 levels of SSL/TLS happening here - and whilst they all appear use the same technology - the assurances, UI, operational regimen, 'investment' and user expectations are way different: A) Symbolic Locks (think bicycle locks in Amsterdam, or the little plastic luggage locks people use) - just a bit of reassurance that snooping is not trivial. = so you'd just want your browser to indicate something about SSL, just like you causally mention mime-type or port-number. B) Some sort of assurance that you are talking to whom you think you are talking to - and that such is the case next time round. And in a grown up sort of way - but no need to go the investment to have some paid minder reassuring you that there is no monster under the bed. E.g. some privacy, say on an online forum. = so in this case you'd probably want a near friction less or perhaps even invisible initial persistent accept and some sort of low-key warning if the cert or chain changed over time beyond some range. C) Fair assurance that you are talking with whom you think you are talking to - is really that entity - and some trust. E.g. the canonical credit card payment case. = behaviour as we have today. D) Proper TLS; where both each end of the connection has a well defined idea of the reliability. E.g. the authenticate properly with an x509 to a server with a cert against an explicit list of CA's which are carefully selected by the 'powers that be' and with full CRLs. Unfortunately there is currently no way for the server to indicate any of this; or the user to indicate what his or her expectations are. So my take is that it is pretty much impossible to get the UI to do the right thing - until it has this information* - and even then you have a fair chunk of education left to do :). But without it - the entire discussion is moot. As to technical options to accomplish this - it would not be hard to *_socialise_* a few small technical hints: i.e if it is a straight self-signed server, certificate, with minimal data - assume A; case C is easy; and in case 'D' one would care enough to have a proper set-up. That just leaves case B - and distinguishing it from a failed C. And that is hard. Especially as a messy B should not compromise a C. So I guess that needs some very clear marker from the site owner. Which could be as simple as insisting on things like an funky DN, a CN with the FQDN set to something like 'ad-hoc', a concept that a certificate with just a CN, but no other O, OU, L or C fields. And obviously one could try to boil the ocean; write a small RFC detailing some OID to put in the certificate for case A B :) - and include the fewlines of openssl in the document to make your own 'B' certificate. Key would not be the technical aspect - but socialising it with enough webmaster folks** that there is enough of a mass to tempt them browser boys. And that is the going to be the very hard part :) Dw *) I strongly think that the current plug-ins which check if a certificates fingerprint is the same from multiple vantage points around the internet is really quite orthogonal to this issue. So no solace there. **) And capitalise on the fact that they need to recreate their certificates as most folks seem to stick to the default 365 days. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
James A. Donald [EMAIL PROTECTED] writes: Visualize Obama, McCain, or Sarah Palin setting up your network security. Then realize that whoever they appoint as Czar in charge of network security is likely to be less competent than they are. You're think about this from the wrong angle. We don't need to legislate network security because, as you say, we'll never get a workable law, and even if we did we really have no idea how to build secure systems that users would actually want to use (although there are some good hypotheses out there). What we need is real-world controls (that have nothing to do with computers) to rein in the free hand that computerisation has given to attackers. Credit freezes are the first step, although even then it's been a massive battle and most likely Congress will eventually pass a law that neutralises the various state laws, as it has for numerous other laws in the past (and even some of the state laws have been watered down with thaw provisions that take you right back to square one). Some examples that come to mind immediately for fighting phishing: - Credit freezes that are real freezes, and require a physical bank visit with ID to thaw. - COB and credit-limit-increase freezes that require physical presence to change (the first thing phishers do when they get your CC info is to wind the credit limit up to max and change the billing address). The once a blue moon that you might want to change these details it's really not to hard to drop by a bank for a minute or two to authorise things. - Ability to specify floor limits for spending independent of the credit limit, e.g. with a credit limit of $10K you can't spend more than $2K domestically and $1K internationally. I think that should give you a general idea of where this is going. At the moment the banks' fraud-guessing systems are really just that, guessing systems, and from numerous reports and assorted anecdotal evidence they're not very effective. The user holds the position of the interior, they know better than any guessing system what's appropriate and what isn't for their financial transactions. The rampant exploitation of the banking system by crooks works because all of the above are totally uncontrolled, and banks have no interest in controlling them. That's what we need legislation for, not to require two-factor-authentication-that-isn't and other gimmicks but to get the banks and credit-reporting agencies to install effective internal controls. Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Darren J Moffat wrote: Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). One thing that concerns me is that in the new release of firefox, there appears to be NO way to get to a site that has a bad certificate (or self signed certificate) other than overriding the warning permanently - no ok let me see it, I have seen the warning and want to look just this once that the remember mismatched domains plugin for 2.x gave you. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
At 11:21 PM +0100 9/9/08, Dave Howe wrote: Darren J Moffat wrote: Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). One thing that concerns me is that in the new release of firefox, there appears to be NO way to get to a site that has a bad certificate (or self signed certificate) other than overriding the warning permanently - no ok let me see it, I have seen the warning and want to look just this once that the remember mismatched domains plugin for 2.x gave you. That may concern you, but I consider it a feature. Instead of teaching users to always click through the damn dialog boxes, FF3 says if you fell for it once, you're going to always fall for it so we won't teach you bad habits. There are arguments for either strategy. Given that few or none of us on this list are actually trained interface experts, I'm sure we could debate this until Perry pulls the moderator switch again. The salient point is that people who have more stake in the game (Mozilla Inc.) have spent longer thinking about this than we give them credit for and come to the design decisions that they have. --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Dave Howe wrote: One thing that concerns me is that in the new release of firefox, there appears to be NO way to get to a site that has a bad certificate (or self signed certificate) other than overriding the warning permanently - no ok let me see it, I have seen the warning and want to look just this once that the remember mismatched domains plugin for 2.x gave you. I'm running Firefox 3.0.1 on (Gentoo) Linux and had coincidentally just gone through this process. When adding an exception for a site with an invalid security certificate there is a checkbox at the bottom of the Add Security Exception window that gives you the option to permanently store the exception. It is checked by default, but the option not to do so is there (and works!) Joss - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
James A. Donald wrote: Peter Gutmann wrote: Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements I agree. I'm sure this is a world-wide problem, and head-in-the-sand cyber-libertarianism has long prevented better solutions. The market doesn't work for this, as there is a competitive *disadvantage* to providing improved security, and it's hard to quantify safety. Remember automotive seat-belts? Air-bags? Engineers developed them, but the industry wouldn't deploy because the market failed to demand safety. That is, long-term safety would cut into short-term profits. The corporate world actually led the public to believe (through advertising) that they were sufficiently safe without them. Only legislation and regulation resulted in measurably greater safety. M$ has long advertised (falsely) that safety was their concern, and their systems were already safe. We all know how that worked out The average cryptographic expert finds it tricky to set up something that is actually secure. The average bureaucrat could not run a pie stand. Legislation and so forth requires wise and good legislators and administrators, which is unlikely. So, what campaigns are you working on currently to improve this? I've educated dozens of U.S. legislators over the years Indeed, the original funding for my NSFnet work 20 years ago was funded by the Michigan House Fiscal Agency, and my early IETF work was funded by the Levin (Senate) and Carr (House) campaigns. Visualize Obama, McCain, or Sarah Palin setting up your network security. Then realize that whoever they appoint as Czar in charge of network security is likely to be less competent than they are. The problem, as always, is enough folks that are competent in both computer security *and* political action. Cannot say much about McCain/Palin, but the Obama folks have been fairly computer literate from the beginning. Not always as security conscious as I'd like, but some seem to be receptive. Unlike McCain (who needs help to get his email), Obama himself seems from reports to be tech-savvy. We either have to educate more political folks about computer security, or more security folks have to become active in politics. The former is the never-ending long-term problem, while the latter is an effective sort-term solution. At the IETF, we used to have a t-shirt, with 9 layers instead of 7. The top was Political, with you are here next to it. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
[Moderator's note: with my other hat on, let me say that although I'm a libertarian, I do not want to have this mailing list fill with libertarianism vs. statism arguments. I'm going to cut this off pretty quickly. --Perry-as-moderator] William Allen Simpson [EMAIL PROTECTED] writes: I agree. I'm sure this is a world-wide problem, and head-in-the-sand cyber-libertarianism has long prevented better solutions. The market doesn't work for this, as there is a competitive *disadvantage* to providing improved security, and it's hard to quantify safety. I have to disagree, for a wide number of reasons. I'll avoid getting too deeply into them them here. The average cryptographic expert finds it tricky to set up something that is actually secure. The average bureaucrat could not run a pie stand. Legislation and so forth requires wise and good legislators and administrators, which is unlikely. So, what campaigns are you working on currently to improve this? I've educated dozens of U.S. legislators over the years Indeed, the original funding for my NSFnet work 20 years ago was funded by the Michigan House Fiscal Agency, and my early IETF work was funded by the Levin (Senate) and Carr (House) campaigns. And yet, in spite of the efforts people make, we still have significant problems, don't we? It doesn't take great genius to understand why current spam legislation is flawed, but I haven't seen it fixed even though you will be hard pressed to find many people who claim to love spam. We have lots of legislation against various forms of computer crime and yet we have virtually no prosecutions even though something like half of the computers in the country have been broken in to. We also used to have quite reasonable wiretap laws in this country which were blown out of the water when political expediency demanded it. I contend that none of this is an accident, or particularly easy to change. Visualize Obama, McCain, or Sarah Palin setting up your network security. Then realize that whoever they appoint as Czar in charge of network security is likely to be less competent than they are. The problem, as always, is enough folks that are competent in both computer security *and* political action. I don't see how that is going to change. One can hope for an ideal, substantially superior world, but generally speaking human beings have to live with the world that we have, and most importantly with the behavior patterns of real people. The core of the libertarian view on this and many other topics is not that it wouldn't be wonderful if we had perfect legislation enforced by perfect policemen, but that we must acknowledge that in the real world we will get the result of a very flawed and problematic political process which will be enforced humans rather than angels. On the political process side, large companies with powerful interests will be immediately involved once the topic of mandatory security standards comes to the fore. Many of those companies will see lobbyists as cheaper than IT infrastructure. There will also be those who see legislation as an opportunity to cash in -- they will try to twist the laws in such a way as to make a buck, by mandating solutions they think will profit them. Some people in our profession may even decide to do what cosmetologists, private investigators and even doctors have done in the past, and reduce competition by requiring licensing as a way of preventing others from entering in to their field. We will also find that the people writing the regulatory standards may very well be the sort who are not entirely right minded -- not everyone in this field can even understand why http: is a bad transport for bank login pages, so we can't expect that everyone in the field can recognize good regulations. I suspect the difference between one's aspirations and the output of this process will be much like the difference between a dog before and after it falls into a meat grinder. Much of the underlying material remains, but the parts are no longer arranged into something you would consider a faithful pet. On the enforcement side, we will suddenly find ourselves in a situation where people who are far from the best technically will be asked to examine extremely complicated computer systems and to decide whether to penalize firms for failing to properly comply with very complicated regulations. I will not belabor the point -- having seen the results of this in much less technical areas, like finance, I must say that I do not have very high hopes for the outcome of the process. Again, it is easy to say there ought to be a law!, and it is much harder to get the right law into place, and even then almost impossible to get it properly enforced. I have very few hopes for this path. Perry -- Perry E. Metzger[EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending
Re: once more, with feeling.
On Wed, Sep 10, 2008 at 01:29:32PM -0400, William Allen Simpson wrote: I agree. I'm sure this is a world-wide problem, and head-in-the-sand cyber-libertarianism has long prevented better solutions. The market doesn't work for this, as there is a competitive *disadvantage* to providing improved security, and it's hard to quantify safety. Or maybe there's a civil liability law issue that causes the market to fail in this instance. Nico -- - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Paul Hoffman wrote: At 11:21 PM +0100 9/9/08, Dave Howe wrote: Darren J Moffat wrote: Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). One thing that concerns me is that in the new release of firefox, there appears to be NO way to get to a site that has a bad certificate (or self signed certificate) other than overriding the warning permanently - no ok let me see it, I have seen the warning and want to look just this once that the remember mismatched domains plugin for 2.x gave you. That may concern you, but I consider it a feature. Instead of teaching users to always click through the damn dialog boxes, FF3 says if you fell for it once, you're going to always fall for it so we won't teach you bad habits. There are arguments for either strategy. True enough, but the clickthru bandits will just see a button that reads to them make this error go away then next time will forget they did it - and will take the fact that they went straight into the site to mean the problem was fixed or simply not remember there ever was a problem. In the meantime, a choice I *used to have* is now taken from me, in the interests of selling more EV certificates. Given that few or none of us on this list are actually trained interface experts, I'm sure we could debate this until Perry pulls the moderator switch again. The salient point is that people who have more stake in the game (Mozilla Inc.) have spent longer thinking about this than we give them credit for and come to the design decisions that they have. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
On Mon, 8 Sep 2008, Adam Shostack wrote: What makes now the perfect time to address an issue which has been present for quite soem time? I'd turn that question around, and ask what makes now such a bad time to address an issue that's been present (and not addressed) for quite some time... ? Surely the recent DNS fiasco was enough of an illustration of the merits of not worrying about something that's been a well known issue for ages... cheers! == A cat spends her life conflicted between a deep, passionate and profound desire for fish and an equally deep, passionate and profound desire to avoid getting wet. This is the defining metaphor of my life right now. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Darren J Moffat [EMAIL PROTECTED] writes: I believe the only way both of these highly dubious deployment practices will be stamped out is when the browsers stop allowing users to see such web pages. Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements rather than big-business- bought legislation like UCITA/UCC or easily-circumvented recommendations like the FFIEC ones (the banks quickly discovered that by redefining two-factor auth to mean twice as much one-factor auth they could meet the requirements without having to do anything to improve security). I'm saying that under the influence of Zero Day Threat by Byron Acohido and Jon Swartz, which looks at some of the financial and credit-reporting industry practices that make identity fraud possible. If you haven't read this already, go and get it now, apart from the annoyingly frequent context- switching between threads (one every few pages instead of the more usual one per chapter) it's a very scary read. Given what it reveals about how the US financial/credit reporting industry works it should really be subtitled We're all going to die, since there's no obvious handbrake mechanism present in the system to slow down identity theft - the rate-limiting step is the fact that the crooks simply can't use all the stolen identities they have, not any security measures that may be present. If you don't believe me, visit any of the hits from the following search: http://www.google.com/search?q=fullz+dumps (that's the easiest way to demo the problem to the masses without requiring people to learn to read cyrillic first :-). Yup, we're all going to die. So that there becomes a directly attributable financial impact to the sites that deploy in that way. The financial impact point is the key word, at the moment it's cheaper and easier for the banks/credit reporting companies to be non-compliant/insecure than it is for them to be secure. I'm not sure that the browser is the most effective way to hit them over this though. Discuss :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann writes, in part: -+ | ... - the rate-limiting step is the fact that | the crooks simply can't use all the stolen identities | they have, not any security measures that may be present. | ... To my knowledge, you are correct. It seems that the price of stolen credentials (on the black market) is falling, which, as with the street price of heroin, would tend to indicate that the opposition is winning. I have a slide for this somewhere (not on this machine) and will dig it up if needed, but the disparity between actual crime and a naive estimate of the opportunity for crime seems to be widening. If correct, then such a disparity would either indicate that our countermeasures are winning -or- the predators are leaving prey on the field. I'm sadly of the opinion that it is the latter. In their Internet Security Threat Report, Symantec used to publish the number of bots detected. The last one of those I have at hand showed a leveling out of the number found de novo per unit interval (per month). Again, this permits two interpretations; on the one hand, we are winning in that we are preventing the problem from worsening while on the other hand it can be read to mean that as fast as we remove bots from hosts that other hosts are botted and, as such, the supply of bots being stable implies that it is easy enough to replace them that the lost of an individual host does not slow down our opposition. What does (in the Symantec graphs) vary is the variance of in-and-out-flow, but not the fraction that are botted. This would tend to strengthen the argument that any periodic sweep of bots off networks is compensated for relatively quickly. In public health, widely varying incidence (new infection rate) but stable prevalence (infected fraction) tends to indicate a high degree of infectability and not a particularly effective immune response. We see this in a way in the AIDS data -- every advance in treatability seems to be followed by increases in risky behavior while prevalence remains to a degree stable. This idea of replacement of cured machines by infected machines seems corroborated in a different way as well. The opposition seems to have lately decided that the advantages of stealth outway the advantages of persistence, which is to say that in-core-only infection is now the preferred mechanism and not writing to disk so as to preserve infected status through a reboot cycle. If this is correct, then it signals that the opposition can replace machines lost through reboot easily enough that the availability of penetrated machines can be better enhanced through making infections harder to find (latent, in medical parlance) than through making a once penetrated machine stay penetrated as to do the latter you have to expose yourself to periodic clean-up of that which is persistent (on disk). For anyone looking ahead, the interaction between this phenomenon (if it is indeed a phenomenon) and the growing role of virtual machines should be of intense interest. Inferentially yours, --dan - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Peter Gutmann wrote: Unfortunately I think the only way it (and a pile of other things as well) may get stamped out is through a multi-pronged approach that includes legislation, and specifically properly thought-out requirements rather than big-business- bought legislation like UCITA/UCC or easily-circumvented recommendations like the FFIEC ones (the banks quickly discovered that by redefining two-factor auth to mean twice as much one-factor auth they could meet the requirements without having to do anything to improve security). The average cryptographic expert finds it tricky to set up something that is actually secure. The average bureaucrat could not run a pie stand. Legislation and so forth requires wise and good legislators and administrators, which is unlikely. Visualize Obama, McCain, or Sarah Palin setting up your network security. Then realize that whoever they appoint as Czar in charge of network security is likely to be less competent than they are. I'm saying that under the influence of Zero Day Threat by Byron Acohido and Jon Swartz, which looks at some of the financial and credit-reporting industry practices that make identity fraud possible. If you haven't read this already, go and get it now, apart from the annoyingly frequent context- switching between threads (one every few pages instead of the more usual one per chapter) it's a very scary read. Given what it reveals about how the US financial/credit reporting industry works it should really be subtitled We're all going to die, since there's no obvious handbrake mechanism present in the system to slow down identity theft - the rate-limiting step is the fact that the crooks simply can't use all the stolen identities they have, not any security measures that may be present. If you don't believe me, visit any of the hits from the following search: http://www.google.com/search?q=fullz+dumps (that's the easiest way to demo the problem to the masses without requiring people to learn to read cyrillic first :-). Yup, we're all going to die. So that there becomes a directly attributable financial impact to the sites that deploy in that way. The financial impact point is the key word, at the moment it's cheaper and easier for the banks/credit reporting companies to be non-compliant/insecure than it is for them to be secure. I'm not sure that the browser is the most effective way to hit them over this though. Discuss :-). Peter. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED] - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Perry E. Metzger wrote: I was shocked that several people posted in response to Peter Gutmann's note about Wachovia, asking (I paraphrase): What is the problem here? Wachovia's front page is only http protected, but the login information is posted with https! Surely this is just fine, isn't it? [snip] (I won't be forwarding followups to this unless they are unusually interesting.) Hopefully this is interesting enough to get forwarded on... Sadly this practice is all too common, and often goes hand in hand with the other cardinal sin of https that of mixed http/https pages. I believe the only way both of these highly dubious deployment practices will be stamped out is when the browsers stop allowing users to see such web pages. So that there becomes a directly attributable financial impact to the sites that deploy in that way. As much as I like Firefox Safari [ the only two browsers I use now ] this has to be led by Microsoft with Internet Explorer since that will have the biggest impact, given IE 8 is in beta this seems like a perfect opportunity to get this in as a change for the next version. Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). -- Darren J Moffat - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
At 4:16 PM +0100 9/8/08, Darren J Moffat wrote: Hopefully this is interesting enough to get forwarded on... Ditto. :-) Warnings aren't enough in this context [ whey already exists ] the only thing that will work is stopping the page being seen - replacing it with a clearly worded explanation with *no* way to pass through and render the page (okay maybe with a debug build of the browser but not in the shipped product). It depends on how we think change can be achieved. Until now, people designing pages using bad security practices balanced their laziness with the fact that their content would be displayed anyway so whatever. You are proposing moving to the other extreme. Given how easy your solution would be for browser vendors to implement, we have to assume that they have considered it and rejected it. A less extreme solution would be to make the warning the user sees on a mixed-content page more insulting to the bank. This page contains both encrypted and non-encrypted content and is inherently insecure. The owner of this web site has clearly made a very poor security decision in showing this page to you. It is likely that other pages on this site also have similarly poor security. Knowing this, do you wish to continue anyway? --Paul Hoffman, Director --VPN Consortium - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Paul Hoffman wrote: A less extreme solution would be to make the warning the user sees on a mixed-content page more insulting to the bank. This page contains both encrypted and non-encrypted content and is inherently insecure. The owner of this web site has clearly made a very poor security decision in showing this page to you. It is likely that other pages on this site also have similarly poor security. Knowing this, do you wish to continue anyway? A more optimal solution is to have this vulnerability accepted by the OWASP community as a Top 10 security vulnerability; it will have the appropriate intended effect since mitigation to the OWASP defined vulnerabilities is required in PCI-DSS: 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html http://www.owasp.org/index.php/Top_10_2007 Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Arshad Noor wrote: A more optimal solution is to have this vulnerability accepted by the OWASP community as a Top 10 security vulnerability; it will have the appropriate intended effect since mitigation to the OWASP defined vulnerabilities is required in PCI-DSS: 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines Isn't this vulnerability already in the Top 10, specifically A7 - Broken Authentication and Session Management ( http://www.owasp.org/index.php/Top_10_2007-A7)? From the Protection section for A7: Do not allow the login process to start from an unencrypted page. Always start the login process from a second, encrypted page with a fresh or new session token to prevent credential or session stealing, phishing attacks and session fixation attacks. Best regards, Darren Lasko Principal Engineer Advanced Development Group, Storage Products Fujitsu Computer Products of America - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
Darren Lasko wrote: Arshad Noor wrote: 6.5 Develop all web applications based on secure coding guidelines such as the Open Web Application Security Project guidelines Isn't this vulnerability already in the Top 10, specifically A7 - Broken Authentication and Session Management ( http://www.owasp.org/index.php/Top_10_2007-A7)? I was just informed of this 10 minutes ago, privately. Not sure how I missed this the last time I read the document (perhaps because I was focusing on remediating an application related to two other vulnerabilities on a project), but the bank examiners also apparently missed this for Wachovia. While login pages are not required to be PCI-DSS compliant (since they generally do not deal with credit card numbers, it has been my impression that many companies are adopting OWASP guidelines for all their web-projects. Perhaps its taking time for some more than others. Arshad Noor StrongAuth, Inc. - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
Re: once more, with feeling.
On Mon, Sep 08, 2008 at 04:16:46PM +0100, Darren J Moffat wrote: | | I believe the only way both of these highly dubious deployment practices | will be stamped out is when the browsers stop allowing users to see such | web pages. So that there becomes a directly attributable financial | impact to the sites that deploy in that way. | | As much as I like Firefox Safari [ the only two browsers I use now ] | this has to be led by Microsoft with Internet Explorer since that will | have the biggest impact, given IE 8 is in beta this seems like a perfect | opportunity to get this in as a change for the next version. Not speaking for my employer here. Most browser vendors try to display pages as best they can. Both end users and businesses get very upset at browser makers who push security improvements by breaking existing practices. If such changes were to happen, then they should either be emergency (seems unlikely, given how long this has been around) or planned and communicated. Adding something high impact after beta 2 doesn't seem like good communication. What makes now the perfect time to address an issue which has been present for quite soem time? Adam - The Cryptography Mailing List Unsubscribe by sending unsubscribe cryptography to [EMAIL PROTECTED]
