[
Lists Home |
Date Index |
Thread Index
]
> 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
|
