.travis.yml

@@ -1,5 +1,3 @@
-sudo: false
-
 language: php
 
 cache:
@@ -54,6 +52,15 @@ matrix:
     - php: 7.2
       env:
         - DEPS=latest
+    - php: 7.3
+      env:
+        - DEPS=lowest
+    - php: 7.3
+      env:
+        - DEPS=locked
+    - php: 7.3
+      env:
+        - DEPS=latest
 
 before_install:
   - if [[ $TEST_COVERAGE != 'true' ]]; then phpenv config-rm xdebug.ini || return 0 ; fi

CHANGELOG.md

@@ -2,6 +2,33 @@
 
 All notable changes to this project will be documented in this file, in reverse chronological order by release.
 
+## 2.7.0 - 2019-05-14
+
+### Added
+
+- [#44](https://github.com/zendframework/zend-authentication/pull/44) adds support for PHP 7.3.
+- [#47](https://github.com/zendframework/zend-authentication/pull/47) adds
+  configuration option to `Zend\Authentication\Validator\Authentication` for
+  mapping custom authentication result codes to existing and new validation
+  message types.
+
+### Changed
+
+- [#42](https://github.com/zendframework/zend-authentication/pull/42) Changes authentication using Basic scheme
+  to re-challenge the client when credentials in Authorization header can not be base64 decoded.
+
+### Deprecated
+
+- Nothing.
+
+### Removed
+
+- [#44](https://github.com/zendframework/zend-authentication/pull/44) removes support for zend-stdlib v2 releases.
+
+### Fixed
+
+- Nothing.
+
 ## 2.6.0 - 2018-04-12
 
 ### Added

composer.json

@@ -17,7 +17,7 @@
     },
     "require": {
         "php": "^5.6 || ^7.0",
-        "zendframework/zend-stdlib": "^2.7.7 || ^3.1"
+        "zendframework/zend-stdlib": "^3.2.1"
     },
     "require-dev": {
         "phpunit/phpunit": "^5.7.27 || ^6.5.8 || ^7.1.2",
@@ -57,8 +57,8 @@
     },
     "extra": {
         "branch-alias": {
-            "dev-master": "2.6.x-dev",
-            "dev-develop": "2.7.x-dev"
+            "dev-master": "2.7.x-dev",
+            "dev-develop": "2.8.x-dev"
         }
     },
     "scripts": {

docs/book/adapter/dbtable/callback-check.md

@@ -114,7 +114,7 @@ $authAdapter
     ->setTableName('users')
     ->setIdentityColumn('username')
     ->setCredentialColumn('password')
-    ->setCredentialValidatinCallback($passwordValidation);
+    ->setCredentialValidationCallback($passwordValidation);
 ```
 
 At this point, the authentication adapter instance is ready to accept
@@ -214,7 +214,7 @@ As an example, many websites require a user to activate their account before
 allowing them to login for the first time. We can add that criteria as follows:
 
 ```php
-// Create a basic adapter, with only an MD5() credential treatment:
+// Create a basic adapter
 $adapter = new AuthAdapter(
     $db,
     'users',

docs/book/adapter/dbtable/credential-treatment.md

@@ -3,8 +3,30 @@
 `Zend\Authentication\Adapter\DbTable\CredentialTreatmentAdapter` will execute a
 SQL query containing the provided identity and credentials, passing the
 credentials to a *credential treatment* function defined on the RDBMS server;
-if an identity is returned, authentication succeeds. Common credential
-treatments include `MD5()` and `PASSWORD()`.
+if an identity is returned, authentication succeeds. Credential
+treatments depends on your RDBMS, and while simple hashing function such as
+`md5` and `sha1` are generally available, it is recommended not to use them and
+rather use the RDBMS specific function such as
+[`PASSWORD(?)` for MySQL](http://dev.mysql.com/doc/refman/5.7/en/password-hashing.html) or
+[`crypt()` for PostgreSQL](https://www.postgresql.org/docs/11/pgcrypto.html#id-1.11.7.34.6).
+More details are available in the next section.
+
+## Security considerations
+
+Passing passwords to database in plaintext for insert or verification is
+generally not recommended.  
+Sql statements can and usually are logged by the database, and passwords in them
+become visible to anyone with access to the logs or monitoring tools that
+consume those logs.
+
+The safer approach is to hash passwords, and to verify them against a stored
+hash in your application code. This way the password never leaves the
+application, and only the hashed value is exchanged with the database.
+
+As such, this adapter is not recommended for new applications, and existing
+applications should consider migrating to using PHP-provided password handling
+functions such as `password_hash()` and `password_verify()`. See
+[CallbackCheckAdapter](callback-check.md) for more info.
 
 ## Configuration Options
 
@@ -23,7 +45,7 @@ The available configuration options include:
 - `credentialTreatment`: In many cases, passwords and other sensitive data
   are encrypted, hashed, encoded, obscured, salted or otherwise treated through
   some function or algorithm. By specifying a parameterized treatment string
-  with this method, such as '`MD5(?)`' or '`PASSWORD(?)`', a developer may
+  with this method, such as '`PASSWORD(?)`', a developer may
   apply such arbitrary SQL upon input credential data. Since these functions
   are specific to the underlying RDBMS, check the database manual for the
   availability of such functions for your database system.
@@ -186,7 +208,7 @@ credential treatment to solve more complex problems.
 
 ### Check for compromised user
 
-In this scenario, we use the credential treatment `MD5()`, but also check to see
+In this scenario, we use the credential treatment `PASSWORD()`, but also check to see
 that the user has not been flagged as "compromised", which is a potential value
 of the `status` field for the user record.
 
@@ -199,7 +221,7 @@ $adapter = new AuthAdapter(
     'users',
     'username',
     'password',
-    'MD5(?) AND status != "compromised"'
+    'PASSWORD(?) AND status != "compromised"'
 );
 ```
 
@@ -218,7 +240,7 @@ $adapter = new AuthAdapter(
     'users',
     'username',
     'password',
-    'MD5(?) AND active = "TRUE"'
+    'PASSWORD(?) AND active = "TRUE"'
 );
 ```
 
@@ -238,7 +260,9 @@ $sqlAlter = "ALTER TABLE [users] "
     . "AFTER [password]";
 ```
 
-Salts should be created *for each user* using a cryptographically sound pseudo-random number generator (CSPRNG). PHP 7 provides an implementation via `random_bytes`:
+Salts should be created *for each user* using a cryptographically sound pseudo-random number generator (CSPRNG).
+PHP 7 provides an implementation via `random_bytes()` (and
+the [random_compat package provides them for older, supported versions of PHP](https://github.com/paragonie/random_compat)):
 
 ```php
 $salt = random_bytes(32);
@@ -267,7 +291,7 @@ $db,
     'users',
     'username',
     'password',
-    "MD5(CONCAT('staticSalt', ?, password_salt))"
+    "PASSWORD(CONCAT('staticSalt', ?, password_salt))"
 );
 ```
 
@@ -304,13 +328,13 @@ The following uses the second example in this section, adding another `WHERE`
 clause to determine if the user is active in the system.
 
 ```php
-// Create a basic adapter, with only an MD5() credential treatment:
+// Create a basic adapter, with only an PASSWORD() credential treatment:
 $adapter = new AuthAdapter(
     $db,
     'users',
     'username',
     'password',
-    'MD5(?)'
+    'PASSWORD(?)'
 );
 
 // Now retrieve the Select instance and modify it:

docs/book/adapter/ldap.md

@@ -172,7 +172,7 @@ Name                     | Description
 `password`               | The password of the account used to perform account DN lookups. If this option is not supplied, the LDAP client will attempt an “anonymous bind” when performing account DN lookups.
 `bindRequiresDn`         | Some LDAP servers require that the username used to bind be in DN form like `CN=Alice Baker,OU=Sales,DC=foo,DC=net` (basically all servers except Active Directory). If this option is `TRUE`, this instructs `Zend\Ldap\Ldap` to automatically retrieve the DN corresponding to the username being authenticated, if it is not already in DN form, and then re-bind with the proper DN. The default value is `FALSE`. Currently only Microsoft Active Directory Server (ADS) is known not to require usernames to be in DN form when binding, and therefore this option may be `FALSE` with AD (and it should be, as retrieving the DN requires an extra round trip to the server). Otherwise, this option must be set to `TRUE` (e.g. for OpenLDAP). This option also controls the default `accountFilterFormat` used when searching for accounts. See the `accountFilterFormat` option.
 `baseDn`                 | The DN under which all accounts being authenticated are located. This option is required. if you are uncertain about the correct baseDn value, it should be sufficient to derive it from the user’s DNS domain using `DC=` components. For example, if the user’s principal name is `alice@foo.net`, a `baseDn` of `DC=foo,DC=net` should work. A more precise location (e.g., `OU=Sales,DC=foo,DC=net`) will be more efficient, however.
-`accountCanonicalForm`   | A value of 2, 3, or 4 indicating the form to which account names should be canonicalized after successful authentication. Values are as follows: 2 for traditional username style names (e.g., `alice`), 3 for backslash-style names (e.g., `FOO\alice`) or 4 for principal style usernames (e.g., `alice@foo.net`). The default value is 4 (e.g., `alice@foo.net`). For example, with a value of 3, the identity returned by `Zend\Authentication\Result::getIdentity()` (and `Zend\Authentication\AuthenticationService::getIdentity()`, if `Zend\Authentication\AuthenticationService` was used) will always be `FOO\alice`, regardless of what form Alice supplied, whether it be `alice`, `alice@foo.net`, `FOO\alice`, `FoO\aLicE`, `foo.net\alice`, etc. See the []Account Name Canonicalization](http://framework.zend.com/manual/current/en/modules/zend.ldap.introduction.html#account-name-canonicalization) section in the zend-ldap documentation for details. Note that when using multiple sets of server options it is recommended, but not required, that the same `accountCanonicalForm` be used with all server options so that the resulting usernames are always canonicalized to the same form (e.g., if you canonicalize to `EXAMPLE\username` with an AD server but to `username@example.com` with an OpenLDAP server, that may be awkward for the application’s high-level logic).
+`accountCanonicalForm`   | A value of 2, 3, or 4 indicating the form to which account names should be canonicalized after successful authentication. Values are as follows: 2 for traditional username style names (e.g., `alice`), 3 for backslash-style names (e.g., `FOO\alice`) or 4 for principal style usernames (e.g., `alice@foo.net`). The default value is 4 (e.g., `alice@foo.net`). For example, with a value of 3, the identity returned by `Zend\Authentication\Result::getIdentity()` (and `Zend\Authentication\AuthenticationService::getIdentity()`, if `Zend\Authentication\AuthenticationService` was used) will always be `FOO\alice`, regardless of what form Alice supplied, whether it be `alice`, `alice@foo.net`, `FOO\alice`, `FoO\aLicE`, `foo.net\alice`, etc. See the [Account Name Canonicalization](http://framework.zend.com/manual/current/en/modules/zend.ldap.introduction.html#account-name-canonicalization) section in the zend-ldap documentation for details. Note that when using multiple sets of server options it is recommended, but not required, that the same `accountCanonicalForm` be used with all server options so that the resulting usernames are always canonicalized to the same form (e.g., if you canonicalize to `EXAMPLE\username` with an AD server but to `username@example.com` with an OpenLDAP server, that may be awkward for the application’s high-level logic).
 `accountDomainName`      | The FQDN domain name for which the target LDAP server is an authority (e.g., `example.com`). This option is used to canonicalize names so that the username supplied by the user can be converted as necessary for binding. It is also used to determine if the server is an authority for the supplied username (e.g., if `accountDomainName` is `foo.net` and the user supplies `bob@bar.net`, the server will not be queried, and a failure will result). This option is not required, but if it is not supplied, usernames in principal name form (e.g., `alice@foo.net`) are not supported. It is strongly recommended that you supply this option, as there are many use-cases that require generating the principal name form.
 `accountDomainNameShort` | The ‘short’ domain for which the target LDAP server is an authority (e.g., `FOO`). Note that there is a 1:1 mapping between the `accountDomainName` and `accountDomainNameShort`. This option should be used to specify the NetBIOS domain name for Windows networks, but may also be used by non-AD servers (e.g., for consistency when multiple sets of server options with the backslash style `accountCanonicalForm`). This option is not required but if it is not supplied, usernames in backslash form (e.g., `FOO\alice`) are not supported.
 `accountFilterFormat`    | The LDAP search filter used to search for accounts. This string is a `printf()`-style expression that must contain one `%s` to accommodate the username. The default value is `(&(objectClass=user)(sAMAccountName=%s))`, unless `bindRequiresDn` is set to `TRUE`, in which case the default is `(&(objectClass=posixAccount)(uid=%s))`. For example, if for some reason you wanted to use `bindRequiresDn = true` with AD you would need to set `accountFilterFormat = '(&(objectClass=user)(sAMAccountName=%s))'`.

docs/book/validator.md

@@ -13,6 +13,7 @@ The available configuration options include:
 - `identity`: the identity or name of the identity field in the provided context.
 - `credential`: credential or the name of the credential field in the provided context.
 - `service`: an instance of `Zend\Authentication\AuthenticationService`.
+- `code_map`: map of `Zend\Authentication\Result` codes to validator message identifiers.
 
 ## Usage
 
@@ -33,3 +34,65 @@ $validator->isValid('myIdentity', [
      'myCredentialContext' => 'myCredential',
 ]);
 ```
+
+## Validation messages
+
+The authentication validator defines five failure message types; identifiers
+for them are available as constants for convenience.
+Common authentication failure codes, defined as constants in
+`Zend\Authentication\Result`, are mapped to validation messages
+using a map in `CODE_MAP` constant. Other authentication codes default to the
+`general` message type.
+
+```php
+namespace Zend\Authentication\Validator;
+
+use Zend\Authentication\Result;
+
+class Authentication
+{
+    const IDENTITY_NOT_FOUND = 'identityNotFound';
+    const IDENTITY_AMBIGUOUS = 'identityAmbiguous';
+    const CREDENTIAL_INVALID = 'credentialInvalid';
+    const UNCATEGORIZED      = 'uncategorized';
+    const GENERAL            = 'general';
+
+    const CODE_MAP = [
+        Result::FAILURE_IDENTITY_NOT_FOUND => self::IDENTITY_NOT_FOUND,
+        Result::FAILURE_CREDENTIAL_INVALID => self::CREDENTIAL_INVALID,
+        Result::FAILURE_IDENTITY_AMBIGUOUS => self::IDENTITY_AMBIGUOUS,
+        Result::FAILURE_UNCATEGORIZED      => self::UNCATEGORIZED,
+    ];
+}
+```
+
+The authentication validator extends `Zend\Validator\AbstractValidator`, providing
+a way common for all framework validators to access, change or translate message templates.  
+More information is available in the
+[zend-validator documentation](https://docs.zendframework.com/zend-validator/messages/)
+
+## Configure validation messages for custom authentication result codes
+
+The constructor configuration option `code_map` allows mapping custom codes
+from `Zend\Authentication\Result` to validation message identifiers.  
+`code_map` is an array of integer code => string message identifier pairs
+
+A new custom message identifier can be specified in `code_map` which will then
+be registered as a new message type with the template value set to the `general` message.
+Once registered, the message template for the new identifier can be changed
+as described in the [zend-validator documentation](https://docs.zendframework.com/zend-validator/messages/).
+
+```php
+use Zend\Authentication\Validator\Authentication as AuthenticationValidator;
+
+$validator = new AuthenticationValidator([
+    'code_map' => [
+        // map custom result code to existing message
+        -990 => AuthenticationValidator::IDENTITY_NOT_FOUND,
+        // map custom result code to a new message type
+        -991 => 'custom_failure_identifier',
+    ],
+]);
+
+$validator->setMessage('Custom Error Happened', 'custom_failure_identifier');
+```

src/Adapter/DbTable/AbstractAdapter.php

@@ -348,7 +348,7 @@ protected function authenticateQuerySelect(Sql\Select $dbSelect)
      */
     protected function authenticateValidateResultSet(array $resultIdentities)
     {
-        if (count($resultIdentities) < 1) {
+        if (! $resultIdentities) {
             $this->authenticateResultInfo['code']       = AuthenticationResult::FAILURE_IDENTITY_NOT_FOUND;
             $this->authenticateResultInfo['messages'][] = 'A record with the supplied identity could not be found.';
             return $this->authenticateCreateAuthResult();

src/Adapter/Digest.php

@@ -162,7 +162,6 @@ public function authenticate()
         }
 
         $id       = "$this->identity:$this->realm";
-        $idLength = strlen($id);
 
         $result = [
             'code'  => AuthenticationResult::FAILURE,
@@ -178,7 +177,7 @@ public function authenticate()
             if (empty($line)) {
                 break;
             }
-            if (substr($line, 0, $idLength) === $id) {
+            if (0 === strpos($line, $id)) {
                 if (CryptUtils::compareStrings(
                     substr($line, -32),
                     md5("$this->identity:$this->realm:$this->credential")