New features:

Stay tuned for more news and examples.

This is what I call write once run anywhere. Great job Eclipse!

Using Basic or Digest is naive.

1. Basic token is a plain Base64 text. To make it worst, you need to send the username and password each time as part of the HTTP packet so any MitM attacker will be able to translate it.

2. The security aspect could be resolved by using Basic over SSL. Yet SSL has it’s performance drawbacks. And in your requirements SSL may not be an option.

3. Using the Digest as being secure, resolves 1 and 2, yet it has disadvantages as:
- The nonce is optional. Skipping the nonce MD5(username:nonce:password) could end up with Digest algorithm of MD5(username:password) which is not secure for simple passwords. Any computer today would be able to reverse engineer a simple password MD5 hash using available dictionaries.
- The Digest is optional. A MitM could tamper the packet and browser could fall back to Basic.

4. Digest and Basic when invoked within a browser environment has the annoying feature of opening a native popup with username/password.

5. Basic/Digest don’t expire. As long as you stole a Basic/Digest security token you can continue with the replay attack.

6. No prevention for tampering. Digest algorithm includes hashing the URI:Method:andBody yet, those algorithms are once again recommendations only and optional.

My prefer approach would be a

Custom Authentication Token a la Amazon

Amazon REST Authentication did a great job of providing a secure REST Authentication. Let’s dissect their token:

Example AWS Call:

GET /photos/puppy.jpg HTTP/1.1
Host: johnsmith.s3.amazonaws.com
Date: Mon, 26 Mar 2007 19:37:58 +0000
Authorization: AWS 0PN5J17HBGZHT7JJ3X82:frJIUN8DYpKDtOLCwo//yllqDzg=

where Authorization algorithm header is:

Authorization = "AWS" + " " + AWSAccessKeyId + ":" + Signature;

and signature:

Signature = Base64( HMAC-SHA1( UTF-8-Encoding-Of( YourSecretAccessKeyID, StringToSign ) ) );

and more:

StringToSign = HTTP-Verb + "\n" +
	Content-MD5 + "\n" +
	Content-Type + "\n" +
	Date + "\n" +
	CanonicalizedAmzHeaders +
	CanonicalizedResource;

CanonicalizedResource = [ "/" + Bucket ] +
	<HTTP-Request-URI, from the protocol name up to the query string> +
	[ sub-resource, if present. For example "?acl", "?location", "?logging", or "?torrent"];

CanonicalizedAmzHeaders = <described below>

Explaining:

• CanonicalizedAmzHeaders: Some special AWS business headers. Skipping..
• CanonicalizedResource: a string concatenating elements from HTTP packet being sent – URI, parameters, Method etc. Reason? Preventing HTTP packet tampering. Assuming an attacker stole the Authentication token, then stolen token could be used only within the current REST call as vital elements of the packet are being injected as part of AWS token.
• StringToSign and Content-MD5 etc.. – more tampering prevention and obfuscation.
• Signature: One way hash encryption of the whole amalgam above.

More  thoughts:

• The token will contain a time stamp so it will expiry on inactivity.
• The token could optionally contain business sensitive data too. userID or any businessID’s.

Lastly, depending on requirements, you may want to consider using OAuth too.

Have a crafty and secure fun!

HTTP4e on Mac OS X Leopard:

HTTP4e on Ubuntu:

Joke aside, have a look on the screenshots. Chinese and Cyrillic characters right on your favorite RESTful client. Cutie, eh?

Opening Wikipedia at http://en.wikipedia.org/wiki/Basic_access_authentication
the following sequence of packet negotiation is being passed across the wire:

Request One:

GET /private/index.html HTTP/1.0
Host: localhost

HTTP/1.0 401 Authorization Required
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:18:15 GMT
WWW-Authenticate: Basic realm="Secure Area"
Content-Type: text/html
Content-Length: 311

blah blah ...

Request Two:

GET /private/index.html HTTP/1.0
Host: localhost
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

HTTP/1.0 200 OK
Server: HTTPd/1.0
Date: Sat, 27 Nov 2004 10:19:07 GMT
Content-Type: text/html
Content-Length: 10476

What does this tell us? Request one is trying to retrieve a resource on server localhost. Receiving a response back with 401 Authorization Required, the client makes second attempt (Request Two) passing this time some magic header and the server seems to like it by giving back 200 OK.  The magic header is “Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==”. The formula of the encoded string is nothing else, but Basic64 encoded text, so any online Base64 tool will decode the text to its human readable “username:password” value.

Back to the original post. How does this relate to HTTP4e? Well the tool doesn’t have the GUI utility to plug this header to the request sending. Yet, this doesn’t mean it doesn’t support Base Authentication. All you need to do is pass that magic header into your requests. So if you construct an HTTP call against server www.abc.com protected by Base authentication with username:password, pass this additional header to to that call.

Authorization: Basic <the Base64 encoded string "username:password">

Thanks for reading this far.

<meta http-equiv="Pragma" content="no-cache" />
<meta http-equiv="Expires" content="-1" />
<meta http-equiv="Cache-Control" content="no-cache" />

I came across this excellent tutorial by Mark Nottingham http://www.mnot.net/cache_docs/. It explains why ”Pragma: no-cache” doesn’t work and why you should use the Cache Control HTTP Headers instead.

Last-Modified
If-Modified-Since
ETag
If-None-Match
Cache-Control: max-age=3600, must-revalidate

Read more