>I know it sounds good, but has it ever worked? Has any vendor ever been >successfully attacked through a > weak demo system, and then rolled out a new one *which happened to be > prepared in time for this eventuality* ?
Not a shining example of secure protocol design, but here's one example: http://developers.facebook.com/blog/post/497 Although I'm not aware of FB applying proactive incentive models for users of the legacy auth prior to simply announcing an EOL. And while there is no history of exploitation against unsigned carts I know of, Google Checkout did deploy both protocols simultaneously and to this day maintains both APIs; one "requires only a working knowledge of HTML" while the other "requires API programming experience." http://checkout.google.com/seller/integrate_custom.html And I'm not saying put two modes in the protocol. I'm saying put two modes in your business model, and use a distinct protocol for each. The business model is where the pressure for multiple modes comes from, so expect it and manage it at that layer, instead of letting it pollute your protocol. H3 is great advice from a very narrow perspective of crypto protocol design, but for a great many systems it either pretends that business pressures relating to complexity don't exist, or that the business people answer to the crypto people. [I know it sounds good, but has it ever worked? ;) ] -Brad _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
