Chui’s counterpoint

Not my two-cents, actually, in response to Pat Hellands Every Noun can be Verbed

[Objects|Closures] are just a poor man’s [closures|objects] via via

It’s been a few years since Mark Pilgrim wrote up the WSSE authentication on XML.com. There has been little exposition of it, bar Ezra from MovableType who explained that the OASIS scheme requires passwords to be stored in clear text on the server. The WSSE scheme doesn’t really define any extensions which specify that a hash password is stored on the server.

Wikipedia entry on HTTP Digest Authentication on the same issue makes a rather weak suggestion that the Realm could hold the salt. This scheme almost requires all passwords to use the same salt. Not the way to go.

Meanwhile, over at MSDN, there’s an article explaining the security risks of the WSSE profile. For instance, the passwordDigest can still be brute forced using offline dictionary attack. Even if crypted passwords are used, an offline attack will obtain a hash that could be used, even if it doesn’t match the original password. The article goes on to advocate a “salted, iteratively hashed account database”. There’s also some discussion of it over at Keith Brown’s Security Briefs blog.

At this point, I’m really tired and haven’t read on further. Got to sleep. (Also a chance to plug my wife’s blog on insomnia)

technorati tags:wsse, atom, authentication, security

This couldn’t be REST could it?

BBC API aka FLICKR API

<?xml version="1.0" encoding="utf-8" ?>
<rsp stat="fail">
    <err code="[error-code]" msg="[error-message]" />
</rsp>

via Second p0st

I hope old Auntie doesn’t start doing that.

Question for Mark Baker:

Suppose I have a resource which is an ordered list of other resources. What’s a suitable protocol to swap two elements around?

What happens if the list is 1,500 elements?

Can we do this with GET, PUT, POST or DELETE?

Thanks!

Update for other readers: Thanks to Mark, I learnt something new today. Stefan Tilkov had a link to HTTP PATCH RFC but that appears to be dead. There’s an expired version of the HTTP PATCH RFC over at Greenbytes.

I’m not entirely satisfied with the outcome though. If we have to extend HTTP specs, I’d rather an extension be provided so that multiple resource operations can be expressed over a single HTTP call / transaction. Server operations are always going to be hard to express, regardless of whether one uses SOAP or REST style APIs. WebDAV operations is an example. Life gets tricky, quickly.

How about specifying a minimal set of composable OPCODEs that a server can implement? This is kind of a compromise between REST and SOAP. At least then we end up with a pattern that every one can speak?

Jim Waldo on language independent means of transporting data:

First of all, it means that you need to have a language-independent mechanism for passing data from one place to another. But there is no more a language-independent way of expressing data than there is a language-independent way of expressing objects. If I tell you that a data type is an int, you don’t know its size unless you know if it is an int in Java, of C (well, even then you won’t necessarily know) or C++. But you do know that I’m not talking about COBOL; but if you want to talk COBOL you need to know how to translate my int into your PIC 9(x) for some value of x.

The language of integration should be based around the language of humans, not the language of computers. Here’s a check list for anyone crafting an interface for integration that humans can understand.

• Integers - if range is not specified, then it is the entire universe of possible integers
• Date and time - either use UTC or timezone and daylight savings information
• Currency - specify units and timestamp
• Floating point - don’t use this! use decimals instead

Anything else I missed?