It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
             Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
  EXPORTING
    if_algorithm = 'SHA3'
    if_key       = space
  RECEIVING
    ro_object    = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...

The code shown in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
  string hmacKey = "";
  byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
  hmac.Key = keyBytes;
  ...
}
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

Never use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

import "crypto/hmac"
...
hmac.New(md5.New, []byte(""))
...

The code in Example 1 might run successfully, but anyone who has access to it can determine that it uses an empty HMAC key. After the program ships, there is no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty HMAC key to generate the HMAC hash:

...
let hmacKey = "";
let hmac = crypto.createHmac("SHA256", hmacKey);
hmac.update(data);
...

The code in Example 1 might run successfully, but anyone with access to it might figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
CCHmac(kCCHmacAlgSHA256, "", 0, plaintext, plaintextLen, &output);
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

import hmac
...
mac = hmac.new("", plaintext).hexdigest()
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', '', data)
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.

Example 1: The following code uses an empty key to compute the HMAC:

...
CCHmac(UInt32(kCCHmacAlgSHA256), "", 0, plaintext, plaintextLen, &output)
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
DATA: lo_hmac TYPE Ref To cl_abap_hmac,
             Input_string type string.

CALL METHOD cl_abap_hmac=>get_instance
  EXPORTING
    if_algorithm = 'SHA3'
    if_key       = 'secret_key'
  RECEIVING
    ro_object    = lo_hmac.

" update HMAC with input
lo_hmac->update( if_data = input_string ).

" finalise hmac
lo_digest->final( ).

...

This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret_key" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
using (HMAC hmac = HMAC.Create("HMACSHA512"))
{
  string hmacKey = "lakdsljkalkjlksdfkl";
  byte[] keyBytes = Encoding.ASCII.GetBytes(hmacKey);
  hmac.Key = keyBytes;
  ...
}

This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "hmacKey" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

Never hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:

import "crypto/hmac"
...
hmac.New(sha256.New, []byte("secret"))
...

This code runs successfully, but anyone who has access to the source has access to the HMAC key. After the program ships, there is no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key makes it available to anyone with access to the source, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

const hmacKey = "a secret";
const hmac = createHmac('sha256', hmacKey);
hmac.update(data);
...

This code runs successfully, but anyone with access to it has access to the HMAC key. After the program ships, there is likely no way to change the hardcoded hmacKey unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:

...
CCHmac(kCCHmacAlgSHA256, "secret", 6, plaintext, plaintextLen, &output);
...

This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:

import hmac
...
mac = hmac.new("secret", plaintext).hexdigest()
...

This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.
Example 1: The following code uses a hardcoded key to compute the HMAC:

...
digest = OpenSSL::HMAC.digest('sha256', 'secret_key', data)
...

This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret_key" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

It is never a good idea to hardcode an HMAC key. The cryptographic strength of HMAC depends on the confidentiality of the secret key, which is used for the calculation and verification of the message authentication values. Hardcoding an HMAC key allows anyone with access to the source to view it, and undermines the cryptographic strength of the function.

Example 1: The following code uses a hardcoded key to compute the HMAC:

...
CCHmac(UInt32(kCCHmacAlgSHA256), "secret", 6, plaintext, plaintextLen, &output)
...

This code will run successfully, but anyone who has access to it will have access to the HMAC key. After the program ships, there is likely no way to change the hardcoded HMAC key "secret" unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

  string salt = ConfigurationManager.AppSettings["salt"];
  ...
  Rfc2898DeriveBytes rfc = new Rfc2898DeriveBytes("password", Encoding.ASCII.GetBytes(salt));
  ...
  

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the property salt. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-controlled salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

    ...
    salt = getenv("SALT");
    PKCS5_PBKDF2_HMAC(pass, sizeof(pass), salt, sizeof(salt), ITERATION, EVP_sha512(), outputBytes, digest);
    ...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the environment variable SALT. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

app.get('/pbkdf2', function(req, res) {
    ...
    let salt = req.params['salt'];
    crypto.pbkdf2(
        password,
        salt,
        iterations,
        keyLength,
        "sha256",
        function (err, derivedKey) { ... }
    );
}

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the property salt. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

...
@property (strong, nonatomic) IBOutlet UITextField *inputTextField;
...
NSString *salt = _inputTextField.text;
const char *salt_cstr = [salt cStringUsingEncoding:NSUTF8StringEncoding];
...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     salt_cstr,
                     salt.length,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the text in the UITextField inputTextField. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

function register(){
  $password = $_GET['password'];
  $username = $_GET['username'];
  $salt = getenv('SALT');

  $hash = hash_pbkdf2('sha256', $password, $salt, 100000);
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the environment variable SALT. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source.

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

import hashlib, binascii

def register(request):
  password = request.GET['password']
  username = request.GET['username']
  salt = os.environ['SALT']

  dk = hashlib.pbkdf2_hmac('sha256', password, salt, 100000)
  hash = binascii.hexlify(dk)
  store(username, hash)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the environment variable SALT. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

...
salt=io.read
key = OpenSSL::PKCS5::pbkdf2_hmac(pass, salt, iter_count, 256, 'SHA256')
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the text in salt. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Weak Cryptographic Hash: User-Controlled PBE Salt issues occur when:

1. Data enters a program through an untrusted source

2. User-controlled data is included within the salt, or used entirely as the salt within a Password-Based Key Derivation Function (PBKDF).


As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled PBE Salt is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used as all or part of the salt in a PBKDF.

The problem with having a user-defined salt is that it can enable various attacks:

1. The attacker may use this vulnerability to specify an empty salt for their own password. From this, it would be trivial to quickly derive their own password using a number of different password-based key derivation functions to leak information about the PBKDF implementation used within your application. This could make "cracking" other passwords easier by being able to limit the particular variant of hash used.
2. If the attacker is able to manipulate other users' salts, or trick other users into using an empty salt, this would enable them to compute "rainbow tables" for the application and more easily determine the derived values.

Example 1: The following code uses a user-controlled salt:

...
@IBOutlet weak var inputTextField : UITextField!
...
let salt = (inputTextField.text as NSString).dataUsingEncoding(NSUTF8StringEncoding)
let saltPointer = UnsafePointer<UInt8>(salt.bytes)
let saltLength = size_t(salt.length)
...
let algorithm : CCPBKDFAlgorithm = CCPBKDFAlgorithm(kCCPBKDF2)
let prf : CCPseudoRandomAlgorithm = CCPseudoRandomAlgorithm(kCCPRFHmacAlgSHA256)
CCKeyDerivationPBKDF(algorithm,
                     passwordPointer,
                     passwordLength,
                     saltPointer,
                     saltLength,
                     prf,
                     100000,
                     derivedKeyPointer,
                     derivedKeyLength)
...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the salt used to derive the key or password by modifying the text in the UITextField inputTextField. After the program ships, it can be nontrivial to undo an issue regarding user-controlled salts, as it is extremely difficult to know if a malicious user determined the salt of a password hash.

Touch ID based authentication can be implemented in two different flavors: using the LocalAuthentication framework or using Touch ID based access controls in the Keychain service.

Although both of them should be strong enough for most applications, the LocalAuthentication approach has some characteristics that make it less suitable for high risk apps such as banking, medical, and insurance:

- LocalAuthentication is defined outside of the device's Secure Enclave which implies that their APIs can be hooked and modified on jailbroken devices.
- LocalAuthentication authenticates the user by evaluating the context policy which may only evaluate to true or false. This boolean evaluation implies that the application will not be able to know who is really being authenticated, it just knows that fingerprint that is registered with the device was used or not. In addition, fingerprints that could be registered in the future will also successfully evaluate to true.


Example 1: The following code uses the LocalAuthentication framework to perform user authentication:

    ...
    let context:LAContext = LAContext();  
    var error:NSError?  
    let reason:String = "Please authenticate using the Touch ID sensor."
    
    if (context.canEvaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, error: &error))  {
        context.evaluatePolicy(LAPolicy.DeviceOwnerAuthenticationWithBiometrics, localizedReason: reason, reply: { (success, error) -> Void in
            if (success) {
                // Fingerprint was authenticated
            }
            else {
                // Fingerprint could not be authenticated
            }
        })
    }
    ...