Switch language: EN|RU

Tuesday, August 17, 2021

Security Testing. NIST SP 800-115 overview.

    


Hi, Dear Reader, it's been a while, I know. Will try to do my best and write more often. ;)

Introduction

Often the case (I believe every time, actually) Software developers need to test and verify a product prior to release. I'm convinced Validation team has really sophisticated checks and tools to do quality assurance stuff. However, when Security shows up it's not always obvious how to perform Security validation and what is the right place in the Validation plan for it. Today in this short write-up I'd like to remind you about quite useful guide NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, first time issued in 2008 but still could be useful. Let's highlight the most essential takeaways.

Overview

The document provides practical recommendations for designing, implementing, and maintaining technical information security test and examination processes and procedures. It is organized into 7 chapters and 7 Appendixes.





What I really like is defining benefits:
  • Provide consistency and structure to security testing, which can minimize testing risks.
  • Expedite the transition of new assessment staff.
  • Address resource constraints associated with security assessments.
This allows you to convey not only Security purposes yet to give the Product team the ability
to reuse pre-established resources such as trained staff and standardized testing platforms; decreases time required to conduct the assessment and the need to purchase testing equipment and software; and reduces overall assessment costs. The overall process includes 3 major stages (as usual).



"How-to-do" part is divided into 3 parts.


Short summary

Actually, you may not really read the whole document, because each section is ended up with the short summary. It does make sense to take a look at them and compare with your own practice. 


Moreover, the guide provides us with useful tools just embedded in specific Linux distro. Even though some of them seems outdated and weird (i.e. Application Security Testing), your Validation engineers could use this list as a starting point.

Conclusion

As a result, please do not consider this document as a guide for experienced Pentesters or Read team. It is designed to help your product team figure out what is Security validation process, why it is beneficial and necessary. The most important takeaway is a structured process and practical examples, describing how you can adopt Security validation keeping in mind already established development pipeline.

Stay on the light side. R.Z.
Posted by at No comments:

Tuesday, February 9, 2021

Guidelines for services: using convenient multi-factor authentication. Part 2 || Рекомендации сервисам по использованию удобной мультифакторной аутентификации. Часть 2

   





Finally, I bring to your attention the latest article with a brief review of the best practices of secure and convenient authentication in services according to NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. Today I'm going to talk about Multi-factoк authentication (MFA). Part 2. At the very beginnig of this series of articles I told you about How services can make using passwords convenient. In the MFA. Part 1 we discussed the recommendations related to three (out of 7) types of secure and convenient MFAs: Out-of-Band Devices, Single-Factor OTP Device and Multi-Factor OTP Device. Now let's move on to the remaining ones: Single-Factor Cryptographic Software, Single-Factor Cryptographic Devices, Multi-Factor Cryptographic Software and Multi-Factor Cryptographic Device.

Single-Factor Cryptographic Software
Means using a cryptographic key stored on a disk (e.g. file) or some other special "soft" media (the essence is the same). Single-factor software cryptographic authenticators encapsulate one or more secret keys unique to the service. Implements the concept "something you have". It is like a digital signature. In fact anyone who has direct access to the user's device can use it to confirm authentication. Obviously, the key stored on disk as a simple file is not the best solution. However, if this works for you, please follow these guidelines:
  1. The key shall be stored in suitably secure storage available to the user's application (e.g., keychain storage, TPM, or TEE if available)
  2. The key shall be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access
  3. Single-factor cryptographic software authenticators should discourage and shall not facilitate the cloning of the secret key onto multiple devices
  4. The service has either symmetric or asymmetric cryptographic keys corresponding to each users. While both types of keys shall be protected against modification, symmetric keys shall additionally be protected against unauthorized disclosure
  5. The challenge nonce shall be at least 64 bits in length, and shall either be unique over the authenticator’s lifetime or statistically unique
Single-Factor Cryptographic Devices
Unlike the previous method, this one means using a hardware device that performs cryptographic operations using protected cryptographic key(s) and provides the user output via direct connection to the user endpoint. The device uses embedded symmetric or asymmetric cryptographic keys, and does not require activation through a second factor of authentication. The authenticator output is provided by direct connection to the user endpoint and operates by signing a challenge nonce presented through a direct computer interface (USB port or something modern like bluetooth). Implements the concept "something you have". The main difference is that the keys are accessed directly on that device. Follow these guidelines:
  1. Single-factor cryptographic device authenticators encapsulate one or more secret keys unique to the device that shall not be exportable (i.e., cannot be removed from the device)
  2. Alternatively, the authenticator could be a suitably secure processor integrated with the user endpoint itself (e.g., a hardware TPM)
  3. The secret key and its algorithm shall provide at least the minimum security length 112 bits
  4. The challenge nonce shall be at least 64 bits in length
  5. It's a good practice to use a physical input (e.g., the pressing of a button) in order to operate. This provides defense against unintended operation of the device, which might occur if the endpoint to which it is connected is compromised
  6. The service has either symmetric or asymmetric cryptographic keys corresponding to each user. While both types of keys shall be protected against modification, symmetric keys shall additionally be protected against unauthorized disclosure
  7. The challenge nonce shall be at least 64 bits in length, and shall either be unique over the authenticator’s lifetime or statistically unique
Multi-Factor Cryptographic Software
The key difference from simple single-factor cryptographic software is a cryptographic key stored on disk or some other "soft" mediathat requires activation through a second factor of authentication. It can be a PIN, password or biometric data. Authentication is accomplished by proving possession and control of the key. Implements two concepts at once: "something you have" with "something you know or something you are". For the service, there is no difference from simple single-factor cryptographic software, hardening is performed on the user's side. In this case, all the previous recommendations are works, however, here are a few more noteworthy ones:
  1. The key should be stored in suitably secure storage available to the user's application (e.g., keychain storage, TPM, TEE)
  2. The key shall be strongly protected against unauthorized disclosure by the use of access controls that limit access to the key to only those software components on the device requiring access
  3. Multi-factor cryptographic software authenticators should discourage and shall not facilitate the cloning of the secret key onto multiple devices
  4. Ключ должен содержаться в безопасном хранилище (Keychain, TPM, TEE и т.п.)
  5. Each authentication operation using the authenticator shall require the input of both factor, whitout exceptions
  6. Any memorized secret used by the user for activation shall be a randomly-chosen numeric value at least 6 decimal digits in length and the number of attempts shall be rate limited
  7. A biometric activation factor (in case of its use) shall includes limits on the number of consecutive authentication failures. For more information about biometric guildelines, see Appendix B. 
  8. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — shall be zeroized immediately after an authentication transaction has taken place
Multi-Factor Cryptographic Device
In this case, both key storage and cryptographic operations are performed directly inside the device. These operations use one or more protected cryptographic keys and requires activation through a second authentication factor (e.g. PIN, password, biometrics). Authentication is accomplished by proving possession of the device and control of the key, the authenticator output is provided by direct connection to the user endpoint (laptop, phone, PC). Implements two concepts at once: "something you have" with "something you know or something you are". The basic principles and guidelines are the same as for single-factor cryptographic devices. In fact, the only difference is the need to present something else. Below you'll find additional recommendations:
  1. Each authentication operation using the authenticator should require the input of the additional factor. Input of the additional factor may be accomplished via either direct input on the device or via a hardware connection (e.g., USB, smartcard) 
  2. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — shall be zeroized immediately after an authentication transaction has taken place
Appendix A. Guidelines for Rate Limiting (Throttling)
It is a good practice for services to implement mechanisms to limit the unseccessful MFA attempts (against guessing attacks and brute force) by default. The main recommendations are to set limit consecutive failed authentication attempts on a single account to no more than 100. Not everything is as simple as it seems. On the other hand, services should reduce the likelihood that an attacker will lock the legitimate claimant out as a result of rate limiting. Such measures may include:
  1. Requiring the claimant (user) to complete a CAPTCHA before attempting authentication
  2. Requiring the claimant (user) to wait following a failed attempt for a period of time that increases as the account approaches its maximum allowance for consecutive failed attempts (e.g., 30 seconds up to an hour)
  3. Accepting only authentication requests that come from a white list of IP addresses from which the subscriber has been successfully authenticated before
  4. Leveraging other risk-based or adaptive authentication techniques to identify user behavior that falls within, or out of, typical norms. These might, for example, include use of IP address, geolocation, timing of request patterns, or browser metadata
  5. When the subscriber (user) successfully authenticates, the service should disregard any previous failed attempts for that user from the same IP address
Appendex B. Guidelines for Use of Biometrics
Using biometrics as a second factor (concept "something you are") in authentication includes both measurement of physical characteristics (e.g., fingerprint, iris, facial characteristics) and behavioral characteristics (e.g., typing cadence). The NIST's document provides some concern on the use of biometrics:
  1. The biometric False Match Rate (FMR) does not provide confidence in the authentication of the subscriber by itself. Biometric comparison is probabilistic, whereas the other authentication factors are deterministic. In addition, FMR does not account for spoofing attacks
  2. Biometric template protection schemes provide a method for revoking biometric credentials that is comparable to other authentication factors (e.g., PKI certificates and passwords). However, the availability of such solutions is limited, and standards for testing these methods are under development
  3. Biometric characteristics do not constitute secrets. They can be obtained online or by taking a picture of someone with a camera phone (e.g., facial images) with or without their knowledge, lifted from objects someone touches (e.g., latent fingerprints), or captured with high resolution images (e.g., iris patterns). While presentation attack detection (PAD) technologies (e.g., liveness detection) can mitigate the risk of these types of attacks
If you still decide to use biometrics, then follow these recommendations:
  1. Biometrics shall be used only as part of multi-factor authentication with a physical authenticator (something you have)
  2. An authenticated protected channel between sensor (or an endpoint containing a sensor that resists sensor replacement) and verifier shall be established and the sensor or endpoint shall be authenticated prior to capturing the biometric sample from the claimant (user)
  3. The biometric system shall operate with an FMR (ISO/IEC 2382-37) of 1 in 1000 or better
  4. The biometric system should implement presentation attack detection (PAD). Testing of the biometric system to be deployed should demonstrate at least 90% resistance to presentation attacks for each relevant attack type (i.e., species)
  5. The biometric system shall allow no more than 5 consecutive failed authentication attempts or 10 consecutive failed attempts if PAD meeting the above requirements is implemented. Once that limit has been reached, the biometric authenticator shall either (the choice is left to the service):
    1. impose a delay of at least 30 seconds before the next attempt, increasing exponentially with each successive attempt (e.g., 1 minute before the following failed attempt, 2 minutes before the second following attempt) or
    2. disable the biometric user authentication and offer another factor (e.g., a different biometric modality or a PIN/Passcode if it is not already a required factor) if such an alternative method is already available
  6. The service shall make a determination of sensor and endpoint performance, integrity, and authenticity. Acceptable methods for making this determination include, but are not limited to: Authentication of the sensor or endpoin, Certification by an approved accreditation authority and Runtime interrogation of signed metadata
  7. Biometric comparison can be performed locally on claimant’s device or at a central verifier. Since the potential for attacks on a larger scale is greater at central verifiers, local comparison is preferred. Yet if the comparison performs centrally:
    1. use of the biometric as an authentication factor shall be limited to one or more specific devices that are identified using approved cryptography. Since the biometric has not yet unlocked the main authentication key, a separate key shall be used for identifying the device
    2. biometric revocation, referred to as biometric template protection in ISO/IEC 24745, shall be implemented
    3. all transmission of biometrics shall be over the authenticated protected channel
  8. Канал от датчика клиента до сервиса должен быть защищен, а доступ к ключу в самом втором факторе (его активация с помощью биометрии) должен быть открыт только после успешной биометрической аутентификации на нем 
  9. False Match Rate (FMR) должен удовлетворять требованиям "1 из 1000" стандарта ISO/IEC 2382-37
  10. Biometric samples collected in the authentication process may be used to train comparison algorithms or — with user consent — for other research purposes. Biometric samples and any biometric data derived from the biometric sample such as a probe produced through signal processing shall be zeroized immediately after any training or research data has been derived
  11. Biometrics are also used in some cases to prevent repudiation of enrollment and to verify that the same individual participates in all phases of the enrollment process as described in SP 800-63 
To sum up, we can say that the implementation of even modern methods of Multi-Factor authentication has a "right to live" and can be used in the wild to meet the need of both services and users. Following of already issued best practices (thanks to colleagues from NIST), they help to ensure that the basic security controls step-by-step and not to forget essencial features.  It's very useful to have that cheat sheet.

The main purpose of this series of posts was to highlight that there are not only strict regulatory security requirements, but also guidelines and best practices for addressing convenience issues. This is important because, as we know, users are the most valuable fort in the struggle against attackers. Convenient security will always be the most effective.


Stay on the light side. R.Z.
Posted by at No comments:

Thursday, January 28, 2021

Guidelines for services: using convenient multi-factor authentication. Part 1 || Рекомендации сервисам по использованию удобной мультифакторной аутентификации. Часть 1

  





Due to requests of my readers, I'm about to continue the notes with a brief overview of the best practices for convenient authentication in services, set out in a NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management. The previous part was about passwords. Today I'd like to discuss multi-factor authentication (MFA). Part 1. As my colleagues mentioned in the comments, the best practice for password security is... don't use them at all =) (better not just them). More precisely, add a second or third factor that the user will be also associated with, except for the single password. In the MFA paradigm stronger authentication is achieved through a mix of three so-called possession-based concepts:
  1. Something you know
  2. Something you have
  3. Something you are
In the observed document NIST serves recommendations for 7 the most popular types of MFA:
  1. Out-of-Band Devices
  2. Single-Factor OTP Device
  3. Multi-Factor OTP Device
  4. Single-Factor Cryptographic Software
  5. Single-Factor Cryptographic Devices
  6. Multi-Factor Cryptographic Software
  7. Multi-Factor Cryptographic Device
Obviously, it's much more expensive to offer MFA technologies for services (even in the simple case - SMS or mobile app). However, this is much more secure than using a single password and provides additional protection for both the client and the service itself. Let's drill into all of these types and highlight the most valuable points that will help services make security reliable and convenient for users. In this post we'll take a look at types from 1 to 3, and leave the rest (from 4 to 7) for Part 2.

Out-of-Band Devices
Assumes the use of a physical device (the simplest - mobile phone) that is uniquely addressable and can communicate securely with the verifier over a distinct communications channel, referred to as the secondary channel. Implements the concept "something you have". This method can be carried out through the special mobile app (press "confirm", scan QR code, etc.) or just by SMS. The out-of-band authenticator can operate in one of the following ways: the claimant transfers a secret received by the out-of-band device via the secondary channel to the verifier using the primary channel (typically a digit code), the claimant transfers a secret received via the primary channel to the out-of-band device for transmission to the verifier via the secondary channel (e.g., QR code), the claimant compares secrets received from the primary channel and the secondary channel and confirms the authentication via the secondary channel (e.g., confirm/decline). Regardless of them, the following recommendations should be followed:
  1. The out-of-band authenticator shall establish a separate channel with the verifier in order to retrieve the out-of-band secret or authentication request (however, it's allowed to perform it on a single device) 
  2. The out-of-band device should be uniquely addressable and communication over the secondary channel shall be encrypted unless sent via the public switched telephone network (PSTN)
  3. The out-of-band authenticator shall uniquely authenticate itself in one of the following ways when communicating with the verifier: Establish an authenticated protected channel to the verifier using approved cryptography using the key, stored in suitably secure storage (e.g., keychain storage, TPM, TEE, secure element) or Authenticate to a public mobile telephone network using a SIM card or equivalent that uniquely identifies the device
  4. The device should not display the authentication secret while it is locked by the owner 
  5. The authenticator shall present a secret received via the secondary channel from the verifier and prompt the claimant to verify the consistency of that secret with the primary channel, prior to accepting a yes/no response 
  6. The verifier shall not store the identifying key itself, but shall use a verification method (e.g., an approved hash function)
  7. In all cases, the authentication shall be considered invalid if not completed within 10 minutes, then it's allowed to try again
  8. The verifier shall generate random authentication secrets with at least 20 bits of entropy and if the authentication secret has less than 64 bits of entropy, the verifier shall implement a rate-limiting mechanism (nevertheless, it's never superfluous =) )
  9. Use of the PSTN for out-of-band verification is undesirably, but if verifiers use it, it should consider risk indicators such as device swap, SIM change, number porting, or other abnormal behavior before using the PSTN to deliver an out-of-band authentication secret
Single-Factor OTP Device
This category includes hardware devices and software-based OTP generators installed on devices such as mobile phones. OTP implements the concept "something you have". Single-factor OTP devices are similar to look-up secret authenticators with the exception that the secrets are cryptographically and independently generated by the authenticator and verifier and compared by the verifier. The secret is computed based on a nonce that may be time-based or from a counter on the authenticator and verifier. Single-factor OTP authenticators contain two persistent values. The first is a symmetric key that persists for the device’s lifetime. The second is a nonce that is either changed each time the authenticator is used or is based on a real-time clock. When using this type of authentication, the following recommendations should be followed:
  1. The secret key and its algorithm shall provide at least the minimum security strength (112 bits)
  2. The nonce shall be of sufficient length to ensure that it is unique for each operation of the device over its lifetime
  3. OTP authenticators — particularly software-based OTP generators — should discourage and shall not facilitate the cloning of the secret key onto multiple devices
  4. The authenticator output may be truncated to as few as 6 decimal digits (approximately 20 bits of entropy)
  5. Passwords should obviously not be repeated
  6. If the nonce used to generate the authenticator output is based on a real-time clock, the nonce shall be changed at least once every 2 minutes
  7. The symmetric keys used by authenticators are also present in the verifier, and shall be strongly protected against compromise (on both sides - device and verifier) 
  8. The verifier shall use approved encryption and an authenticated protected channel when collecting the OTP in order to provide resistance to eavesdropping and MitM attacks
  9. In order to provide replay resistance, verifiers shall accept a given time-based OTP only once during the validity period
  10. If the authenticator output has less than 64 bits of entropy, the verifier shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account
Multi-Factor OTP Device
The main difference from the simple OTP - additional factor, which augments the one-time password generation. The second factor of authentication may be achieved through some kind of integral entry pad, an integral biometric (e.g., fingerprint) reader, or a direct computer interface (e.g., USB port). Implements two concepts at once: "something you have" with "something you know or something you are". The OTP is displayed on the device and manually input for transmission to the verifier. Multi-factor OTP authenticators operate in a similar manner to single-factor OTP authenticators, except that they require the entry of either a memorized secret or the use of a biometric to obtain the OTP from the authenticator. Each use of the authenticator require the input of the additional factor. Certainly for the service this type of MFA looks like an single-factor OTP. All the previous recommendation (Memorized passwords пароли, single-factor OTP) works for multi-factor OTPs. Yet there is a few more pieces of advice:
  1. Any memorized secret used by the authenticator for activation shall be a randomly-chosen numeric secret at least 6 decimal digits in length
  2. A biometric activation factor shall meet the requirements of limits on the number of consecutive authentication failures and other tips (more detailed - in the Part 2)
  3. The unencrypted key and activation secret or biometric sample — and any biometric data derived from the biometric sample such as a probe produced through signal processing — shall be zeroized immediately after an OTP has been generated
  4. In the event a claimant’s authentication is denied due to duplicate use of an OTP, verifiers may warn the claimant in case an attacker has been able to authenticate in advance
Generally, the analyzed today's recommendations are primarily concerned with security, not really the convenience of the user (as you could see in my post about passwords). Nevertheless, the modern MFA use cases provided by services offer comfort by default. This  essentially reduces several requirements (and thus the risks) of using the strongest, but unmemorable passwords.  

In the MFA. Part 2 I'm going to talk about using secret keys as a MFA in various forms.


Stay on the light side. R.Z.
Posted by at No comments:

Monday, December 21, 2020

How services can make using passwords convenient || Как сервисам сделать использование паролей удобным

 


 

"How to set a strong, unique and memoriaable user password" - this topic has been winning today the first lines in articles about cybersecurity. It often happens that I still see stickers on monitors, notes written on a piece of paper and.... for sure, passwords and PINs written by plain text in the address book, notes app or even home screen widget. However, what if you think a little about the users and don't just give them all the full responsibility? Issued by NIST Special Publication 800-63B. Digital Identity Guidelines. Authentication and Lifecycle Management offers recommendations for service providers, portals and others whether they are cloud based or on-premises. This is not a new document, but it is periodically updated (the latest version is dated 2020) and is still relevant.

Security should be comfortable, I keep saying that. It is gratifying that the guys from NIST worrying about users created best practices for services. Following them, it will be more profitable and easier for users to use well-made passwords, while you do not need to require them to constantly complicate, unnecessary actions and lengthy instructions. For some provisions, I really want to shake hand, because they do debunk a lot of myths.

Actually NIST SP 800-63B contains many aspects of the password management lifecycle and 9 types of authentication. Let me talk today about the only one of them 
(Memorized Secret Authenticators).

  1. Passwords must be at least 8 characters long if they are created by the user, and at least 6 characters long if they are generated automatically. Important: Passwords may be entirely numeric
  2. The service is recommended to check passwords based on their appearance in the black list of compromised values 
  3. The service should not allow the use of "dictionary" or simple passwords (111, aaaa, qwerty, etc.). Fortunately, there are many such lists on the Internet to check.
  4. The service sholud prohibit passwords that contain the username or part of it
  5. Very important (and sometimes a popular myth): No other complexity requirements for memorized secrets should be imposed (like variety of chars, case, digits). 
  6. The service shuold technically support the use of passwords of at least 64 characters in length
  7. All printing ASCII [RFC 20] characters should be acceptable, including spaces
  8. Unicode [ISO/ISC 10646] characters (including emojis!) should be acceptable, including normalization and equal number of symbols (1 UNICODE = 1 ASCII)
  9. The service shall not permit the user to store a “hint” that is accessible to an unauthenticated claimant (Do you remember hints in earlier Windows versions on the login page?)
  10. Conversely, the service shall not prompt subscribers to use specific types of information and help them not to use typical phrases (e.g., “What was the name of your first pet?”)
  11. The service should show examples and explain to users why his or her password is not secure and refuse to use it if it matches a blacklist or dictionary
  12. The service shall implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account (in fact, the number given is quite high - 100, however, it's good practice to use additional mechanisms such as captcha, time limit between attempts, etc.)
  13. Ones more myths breaking: the service should not require passwords to be changed arbitrarily (e.g., periodically). Instead the service shall force a change if there is evidence of compromise of the authenticator.
  14. The service should permit claimants to use “paste” functionality when entering a memorized secret. This facilitates the use of password managers, which are widely used and in many cases increase the likelihood that users will choose stronger memorized secrets.
  15. The service should offer an option to display the secret — rather than a series of dots or asterisks ("*"). It's also useful to permit the user’s device to display individual entered characters for a short time after each character is typed to verify correct entry (particularly applicable on mobile devices).
  16. The service also has requirements for reliable password storage and protection when it is requested (transmitted), such as a hash with a "salt", communication encryption, etc.
These recommendations are based on practical experience and many (especially large services) have already implemented them. However, if you are designing your own service or application, it is useful to familiarize yourself with it.


Stay on the light side. R.Z.
Posted by at No comments:
Subscribe to: Posts (Atom)