[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Cookies at XML Europe 2004 -- Call for Participation
> >All the state must be in the client: > > http://groups.yahoo.com/group/rest-discuss/message/3594 (Baker) > > http://groups.yahoo.com/group/rest-discuss/message/3583 (Fielding) > > That's an oversimplification. The resources referred to by the URI > can have state and this state is stored on the server. The server > does not have to expose the complete resource state to the client. I'm not (and haven't been) talking about the URI state. I'm talking about login credentials. Using a cookie to refer to state maintained inside the server that identifies who the client is. (I know it's hard to keep track with so many participants in this thread.:) In that context, I don't think I'm over-simplifying. > In a properly designed system, it doesn't have to encrypt very much. That's wrong. Anything signed or encrypted will be at least as big as the RSA key size, which will be at least 1Kbits. Throw in base 64 and you're talking at least 170 bytes. For example, let's say my identity is a SAML document/assertion. If I push that out to the client, rather than use a cookie to refer to identity cached in the server, than that SAML document must either be signed or encrypted. Adding multiple kilobytes (say 2k up to maybe 10k) of data to every request is not scalable. Requiring the server to re-validate that data on every request is not scalable. > What feels wrong about this to me is that there are scalable, secure > sites in existence today that use SSL to encrypt sensitive > transactions. ... where the risk is ultimately absorbed by the credit card company. :) Those sites are scalable only because SSL does what REST doesn't allow: it maintains a cache of state (session key) between client and server. Without that shared state, SSL is too expensive and impractical, as it requires a public-key operation on the server for every connection, and good random bits from the client. > But digest authentication does not require the encryption of > everything, so it's cheaper than decrypting the entire page, and you > can still use HTTP over SSL with basic authentication if you prefer. Both of those are *VERY* bad security practices, because they use the long-term "login password" on every connection. Yes, everyone does it. That doesn't make it right. Just to keep the MEME going: REST's statelessness prohibits good security practices. /r$ -- Rich Salz Chief Security Architect DataPower Technology http://www.datapower.com XS40 XML Security Gateway http://www.datapower.com/products/xs40.html XML Security Overview http://www.datapower.com/xmldev/xmlsecurity.html
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|