Cart
[Home] [By Thread] [By Date] [Recent Entries]
> Possibly you read a message I missed or interpreted it differently. > Could you please provide the URL to and quote from the specific message > which demonstrates that good security practices conflict with REST? 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) The server cannot trust the client to not modify the session state, and it may have privacy concerns about exposing the entire state to the client in the first place. Therefore the server must encrypt the entire session state (if it even has it all) and encrypt it. It then gives this to the client so that the client can present it back on future requests. (Let's ignore if that's done via Cookies or via querystring parameters in a URL.) In order to do this, we must use public-key encryption. For security (and REST state:) reasons, we cannot use a faster symmetric algorithm like 3DES or AES. We could use https to protect the content, but then we're back to shared state (the SSL context, but maybe REST doesn't care since that's just a transport issue). Therefore, the server has to do a public-key decryption on every single incoming request in order to authenticate the client. That is not scalable. It makes the server completely susceptible to trivial DoS attacks, for example. Does this make sense? Does it seem wrong? /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
|
