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