Secure Basic Authentication

Basic Access Authentication and a more secure variant named Digest Access Authentication, are described in RFC 2617, which discusses the security issues with both, including MITM (Man In The Middle) attacks.

Secure Basic authentication combines the simplicity of Basic authentication with the security provided by public-key cryptography. Simplicity is achieved by eliminating the need for a server to explicitly send a challenge as is done by SSH or FIDO when public-key authentication is used. Instead, a passphrase is computed, using a combination of time stamps and public key encryption, and verified by the server. The effect is similar to the use of client certificates, but does not require a certificate authority or some other third party, nor a procedure for obtaining and configuring certificates that most users find too daunting to consider (a program named sbl described below will set up a key pair painlessly and provides buttons to copy data needed by a server to the system clipboard). In addition, client certificates are used when an SSL connection is established, which is problematic for a web site that uses a single TCP socket when only part of the web site should be authenticated.

Secure basic authentication assumes that SSL/TLS will be used for connections between a client and server. As a result,

when a connection is first established, a client will receive a certificate from the server. This certificate is valid for at least the duration of the connection.
the certificate is used to verify that the server to which the client has connected in fact has the private key corresponding to the public key stored in the certificate.
servers are implemented so that the private keys are kept securely. As a result, any attempt a phishing or spoofing will require the use of a different certificate, and specifically a different public key.

The passphrase that secure basic authentication uses is generated by signing a time stamp and the server's certificate's public key along with some additional information. This requires that the server's and client's clocks are synchronized, but that is easily done given that most systems use NTP (Network Time Protocol). Once verified, this password can be used for a more extended period. If that period expired, a new passphrase is generated and revalidated.

The passphrase generated in Secure Basic authentication uses

a private key corresponding to the public key that will be stored on a server.
a user-supplied password that will be stored on the server.
the current time. For clarity, in the following text, this password will be referred to as the "password" and the one generated by using public key encryption will be referred to as the "passphrase".

The passphrase contains several fields:

a 4-octet field containing a timestamp consisting of a 32-bit two's complement integer, stored in little-endian byte order, providing the time the passphrase was created. The time is given by the number of seconds since 1970-01-01T00:00:00Z.
a 4-octet field containing a 32-bit CRC of the first four octets and a UTF-8 encoded password in that order, stored in little-endian byte order. For a denial of service attack with random passwords, the CRC will reduce the number of digital signatures that have to verified by a server by a factor of approximately 4 billion.
a digital signature of
- the first 8 octets of the passphrase,
- the DER encoding of the server's certificate's public key,
- the UTF-8 encoded password used in the CRC,
created using the user's private key and signature algorithm.

This sequence of octets is then base-64 encoded using the URL-safe encoding described in RFC 4648 to create the passphrase that will be sent to the server.

The server stores the user's public key, signature algorithm, and password. To check that a passphrase is valid, the server

decodes the passphrase using a base-64 decoder for the URL-safe encoding,
checks the timestamp stored in the first four octets (octets 1 to 4),
uses the first 4 octets and the stored password in that order to compute a 32-bit CRC and compares that to the one corresponding to the value stored in octets 5 to 8,
uses the public key and signature algorithm to verify that the signature stored in the remaining octets (starting with octet 9) is valid for a document consisting of
- octets 1 to 8,
- the server's SSL certificate's public key represented by its DER encoding,
- the UTF-8 encoded password.

If these tests do not fail, authorization succeeds and the passphrase can be stored in a table of verified passphrases with a key given by the user's name and Internet address. This table also includes an expiration time for the user and address specified by the key, which is updated each time the key provided the expiration time has not been reached. If the expiration time has been passed, the authentication fails and the user must generate a new passphrase.

In addition to providing some protection against denial of service attacks, The password is useful when certificates use subject alternative names, effectively allowing multiple entities to share a single certificate, and where one may want to be logged into one entity but not another.

Typically a client will reuse a passphrase that it has previously generated until that passphrase fails. It that is done, the client should also check that the corresponding certificate has not been changed: otherwise a MITM attack is possible, although that would require compromising the network infrastructure (routers, DNS servers, etc.)

A program, sbl, will generate passphrases and copy them to the clipboard so that they can be pasted into a dialog box provided by a browser that does not support secure basic authentication. The following screenshot shows the user interface:

sbl screenshot

This program is task-oriented, which is why the graphical user interface is primarily a set of buttons. An unusual feature is that, when it opens a browser, sbl will copy a user name and passphrase to the clipboard in such a way that paste operations alternate between the two. Some operations are also accessible via a menu, which provides keyboard shortcuts for frequently used operations.

Realms

Basic authentication defines a "realm" as a name used to define a "protection space" (as defined in RFC 7235, Section 2.2 Secure basic authentication uses a stylized encoding for realms: if a realm sent by a server to a client starts with

[D], a form of digest authentication is used: the passphrase is the URL-safe base64 encoding of the first 8 octets as described above, followed by a SHA-256 message digest of those 8 octets and the UTF-8 encoded password in that order. This option is provided primarily for testing.
[S], the digital signature described above does not include the public key from the server certificate. This option is provided for testing or if for some reason SSL cannot be used and security is not a major concern.
[SC], the digital signature is computed as described above.

Otherwise basic authentication is assumed. The class org.bzdev.swing.AuthenticationPane replaces "[D]", "[S]", and "[SC]" with sequences of one or more emoji when creating a prompt to display. The emoji are used as icons.

The realm is not used when a passphrase is generated for pragmatic reasons: programs such as sbl that generate passphrases may not be able to determine what the realm is (sbl opens an SSL/TLS connection to a server but does not use HTTP or HTTPS, and consequently cannot determine the realm. While the realm could be specified explicitly in an sbl's input file, the realm can be changed by a server at any time, and it is not desirable to burden the user with having to figure out when this has happened (when authenticating, firefox, for example, does not tell users what the realm is).

Timestamps and timeouts

A server should support the following limits and timeouts

lowerTimeDiffLimit. This value must be negative. It is added to the current time to get a lower bound on the timestamp encoded in the first 4 octets of a passphrase. It is negative to account for clocks being slightly out of synchronization. The value is in units of seconds.
upperTimeDiffLimit. This value must not be negative. It is added to the current time to get an upper bound on the timestamp encoded in the first 4 octets of a passphrase. Its value should be large enough to allow for delay and processing time in addition to errors in clock synchronization. The value is in units of seconds.
passphraseTimeout. Once a passphrase has been authenticated, the passphrase will typically be kept in a table that maps a given user name and Internet address to a passphrase and expiration time. The expiration time will be the sum of the current time and the value of passphraseTimeout, both in units of seconds. If a new authorization request arrives before the expiration time for the same user and Internet address, the corresponding expiration time is reset to the sum of the new current time and the value of passphraseTimeout.

The use of timestamps prevents old passphrases from being reused, even though, with SSL/TLS, it would be very difficult to obtain one.

Key pairs

Key pairs and signature algorithms are those that Java supports. The default uses elliptic key cryptography. The elliptic curve is secp256r1 (openssl prefers the name prime256v1, which keytool does not accept). The default signature algorithm is SHA256withECDSA.

Ease of implementation

Secure basic authentication is easy to implement, primarily because basic-authentication code is reused. The following classes were added to the BZDev class library to support secure basic authentication:

org.bzdev.net.PemDecoder: 227 lines of code. This is a general-purpose class for decoding PEM files. It uses a utility class (org.bzdev.net.HeaderOps) that contains 371 lines of code).
org.bzdev.net.PemEncoder: 79 lines of code. This is a general-purpose class for encoding PEM files.
org.bzdev.net.SecureBasicUtilities: 520 lines of code. This class contains the code for creating and verifying passphrases, and for some other useful operations. It contains methods used by both a client and a server and can generate key pairs. It also contains methods that allow passphrases to be represented in a series of format: strings, arrays of char, and arrays of bytes, so there is more code than would be needed by a single application.
org.bzdev.ejws.EjwsSecureBasicAuth: 483 lines of code, compared to 184 lines of code for org.bzdev.ejws.EjwsBasicAuthenticator, which provides an implementation of basic authentication. The class EjwsSecureBasicAuth contains server-specific code for the web server provided by the org.bzdev.ejws package. If a private key is GPG encrypted, this class will use GPG to decrypt the private key (the advantage is that GPG agent will then prompt for the appropriate password, etc., needed to decrypt the key).
org.bzdev.swing.AuthenticationPane: 674 lines of code. This contains the code needed to create a dialog box to get a user name and password. It works with secure basic authentication, digest authentication, and basic authentication. It will create an instance of java.net.Authenticator for use with the Java networking APIs.

The number of lines of code were estimated using a program that ignores comments and blank lines, but counts everything else including Java import statements and lines that contain as little as a single brace. As a result the number of lines of code listed for each case is an overestimate of the number of executable statements.

Implementing secure basic authentication in a browser should be roughly comparable to implementing or modifying a password manager.

Implementation limitations

The current implementation has two limitations, mostly because of the existing Java APIs:

The client will open a separate SSL connection to the server to get the certificate because the Java APIs do not provide a convenient way of getting the certificate for the connection an authenticator is using.
When a passphrase is cached an SSL connection's certificate is not checked to verify that it is the one used to generate the password. While it is a trivial change, it would require modifying classes that are part of the JRE.

Server-centric logins

The program sbl uses GPG to encrypt the private key corresponding to the public key used by a server for authentication, and that private key can be encrypted so that more than one user can decrypt it. For a small web site for which several individuals need access to a role-specific management account, one can simply provide an sbl file on that web site, and a browser can then save that file or simply run it, automatically starting sbl. This can simplify managing the web site as users don't have to set up an account or remember a website-specific password (but will need to install sbl and GPG). GPG key servers can eliminate the need for a user to explicitly provide a GPG key.

This capability may be particularly useful for small websites that support a relatively small number of users and that do not have a full-time staff to manage them. There's one security risk in placing an sbl file on a publicly accessible website: additional users can get access to an encrypted private key, but the mitigating factor is that the key is encrypted using GPG and without access to the GPG private key, breaking GPG encryption is nearly impossible: it would require a brute-force search of 2¹²⁸ keys.

As a convenience, sbl allows GPG user ID's to be listed with multiple -r options, followed by the configuration-file name. This will cause a new key pair to be generated with a new set of users being able to access the private key.

Example

Public key:


signature-algorithm: SHA256withECDSA
-----BEGIN EC PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE1IC0QbQQPpt4xWzI8IHya5HEOGZu
fzjm5LztuExU2T+tvZhXRBQRewShwwoxbPUV+NZo7YHpXXHfMciMLKpzFQ==
-----END EC PUBLIC KEY-----

A passphrase using a Google certificate, the user name "foo", the password "foo", and the private key corresponding to the public key shown above is


0JmMZEQapr8wRQIgWsnL7ZPs-zpaEIf77lISXyxvXp6AOAIL9c25BAxV85MCIQCSZ80
GzmAiGyUeRz4qTi_ZY0akLVCRc_ZCwLgheej7yQ==

Similarly, a passphrase using a Yahoo certificate, the user name "foo", the password "foo", and the private key corresponding to the public key shown above is


65mMZOzrwhUwRQIgNFXaAbvgssv68McvgXsy71pkO9_rNAxKfA1Ft5hpEN8CIQC49q9
EZkGuAZaQIpl1efRDE2vEbM8l83CtKl8-mLzWEg==

Neither passphrase includes a line break: the version above splits the passphrases into two lines for readability.

Successfully verifying these passphrases requires that that the public key can verify a signature constructed using the user's password and the server's certificate. Note that two different servers cannot use the same certificate without sharing the certificate's private key. In addition, the signature includes a timestamp, encoded in the passphrase, so that passphrases are valid for only a short time.

For reference, The Google certificate used was

and the Yahoo certificate used was

These certificates, of course, are periodically updated. Regardless, a useful exercise for a reader so inclined is to try to create new passphrases that can be verified with either certificate, given the public key and password provided above—a task that would have to break public key encryption in order to succeed.