[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

  • To: Elliotte Rusty Harold <elharo@m...>
  • Subject: Re: Re: Cookies at XML Europe 2004 -- Call for Participation
  • From: Rich Salz <rsalz@d...>
  • Date: Tue, 6 Jan 2004 20:51:15 -0500 (EST)
  • Cc: xml-dev@l...
  • In-reply-to: <p06010201bc20baea0c99@[192.168.254.4]>

ssl cookie
> >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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.