Secure Password Authentication

Secure Password Authentication is a protocol used to authenticate with a Simple Mail Transfer Protocol (SMTP) server. The protocol is attributed to Microsoft, but it is not an original protocol, but based on the NTLM authentication scheme.

NTLM Authentication Scheme for HTTP

Introduction

This is an attempt at documenting the undocumented NTLM authentication scheme used by Microsoft's browsers, proxies, and servers (Internet Explorer and IIS). This scheme is also sometimes referred to as the NT challenge/response (NTCR) scheme. Most of the info here is derived from three sources:
*Paul Ashton's work on the [http://www.argo.demon.co.uk/nt/ntie.html NTLM security holes]
* [http://de.samba.org/samba/ftp/docs/htmldocs/ENCRYPTION.html Encryption documentation] from [http://samba.anu.edu.au/samba/ Samba]
*Network snooping

Since most of this info is reverse engineered it is bound to contain errors; however, at least one client and one server have been implemented according to this data and work successfully in conjunction with Microsoft's browsers, proxies and servers.

This scheme is not as secure as digest access authentication and some other schemes; however, it is slightly better than the basic authentication scheme. This scheme is not an HTTP authentication scheme, it is a connection authentication scheme which happens to (mis-)use HTTP status codes and headers (and even those incorrectly).

NTLM Handshake

When a client needs to authenticate itself to a proxy or server using the NTLM scheme then the following 4-way handshake takes place (only parts of the request and status line and the relevant headers are shown here; "C" is the client, "S" the server):

1: C --> S GET ... 2: C <-- S 401 Unauthorized WWW-Authenticate: NTLM 3: C --> S GET ... Authorization: NTLM <base64-encoded type-1-message>

4: C <-- S 401 Unauthorized WWW-Authenticate: NTLM <base64-encoded type-2-message> 5: C --> S GET ... Authorization: NTLM <base64-encoded type-3-message> 6: C <-- S 200 Ok

Messages

The three messages sent in the handshake are binary structures. Each one is described below as a pseudo-C struct and in a memory layout diagram. byte is an 8-bit field; short is a 16-bit field. All fields are unsigned. Numbers are stored in little-endian order. Struct fields named zero contain all zeroes. An array length of "*" indicates a variable length field. Hexadecimal numbers and quoted characters in the comments of the struct indicate fixed values for the given field.

The field flags is presumed to contain flags, but their significance is unknown; the values given are just those found in the packet traces.

Type-1 Message

This message contains the host name and the NT domain name of the client.

struct { byte protocol [8] ; // 'N', 'T', 'L', 'M', 'S', 'S', 'P', '