Post on 24-Jan-2021
Aadhaar Authentication Application Security
Standard (for Web, Mobile and Thick Client Applications)
2 | P a g e
Document Control
S. No. Type of Information Document Data
1. Document Title UIDAI - Aadhaar Authentication Application Security Standard
2. Document Code UIDAI – AAASS
3. Date of Release 13-Nov-2020
4. Document Superseded First Version (2020)
5. Document Revision No V1.0
6. Document Owner UIDAI
7. Document Author(s) Deepali Sharma (ADG -Auth), Rajinder Singh (Consultant)
Document Approvers
S.No. Approver Approved Through/ Nominee Comments
1. Shri. Pronab Mohanty (DDG –
Auth)
2. Shri. Pankaj Kumar (CEO)
Document Change Approvals
Version No. Revision Date Nature of Change Date Approved
Version 1.0 NA First version (2020) 12-Nov-2020
3 | P a g e
Purpose of this Document
Aadhaar Authentication Application Security Standard includes technical and operational
requirements set by the Unique Identification Authority of India (UIDAI) to protect Aadhaar
number holder data. The standard applies to all entities that perform Aadhaar authentication
and store, process or transmit Aadhaar number holder data. The standard is applicable to web-
based applications, mobile applications and thick client applications leveraging Aadhaar
authentication.
The standard first defines the platform agnostic security requirements across each of the three
platforms and thereafter, the additional security requirements applicable to the individual
platforms. The standard is structured as follows:
Section 1 Introduction to the Aadhaar Authentication Application Security Standard: This
section lists down the domains (goals) defined in the standard.
Section 2 Aadhaar Authentication Application Security Standard – Common Requirements: This
section defines the common minimum-security requirements applicable to the web, mobile and
thick-client applications used for Aadhaar authentication purposes. This section also includes the
minimum-security requirements that are specifically applicable to each of the applications - web,
mobile and thick-client, in addition to the common requirements. The following sub-sections are
defined across each domain(goal):
• Common Requirements – Minimum-security requirements applicable to web, mobile and thick-client applications used for Aadhaar authentication purposes
• Additional Requirements for Web Applications - Minimum-security requirements applicable only to web applications used for Aadhaar authentication purposes
• Additional Requirements for Mobile Applications - Minimum-security requirements applicable only to mobile applications used for Aadhaar authentication purposes
• Additional Requirements for Thick-client Applications - Minimum-security requirements applicable only to thick-client applications used for Aadhaar authentication purposes
Section 3 and subsequent sub-sections expand on the requirements defined in section 2.
Audience for this document
Architects: This document shall be used by application architects to design the authentication
mobile applications.
Developers: This document shall be used by the developers who are involved in developing the
authentication applications.
4 | P a g e
Feedback and Suggestions on the standard
Feedback and Suggestions on the standard is solicited / invited / appreciated. We will try to
address as many relevant feedback / suggestions as possible in the future versions of this
document. It will help in enhancing / refining the standard further and making it more
comprehensive and up to date with recent advancements in the field of information security
and threat landscape.
Any such query / feedback / suggestion, related to content of this standard, may kindly be sent
to us through email to auth.excellence@uidai.net.in.
5 | P a g e
Table of Contents
1. Introduction to the Aadhaar Authentication Application Security Standard (AAASS) ...................... 6
2. Aadhaar Authentication Application Security Standard - Requirements ....................................... 8
3. Aadhaar Authentication Application Security Standard – Detailed Requirements .........................18
Goal 1: Protect Aadhaar Holder Data ..........................................................................................18
Goal 2: Architecture, Design and Threat Modelling ......................................................................22
Goal 3: Authentication API compliance and Encryption ................................................................24
Goal 4: Delivery of consent message for Aadhaar authentication within application ........................25
Goal 5: Operator Authentication and Session Management ..........................................................28
Goal 6: Secure Network Communication.....................................................................................29
Goal 7: Aadhaar Authentication Logs ..........................................................................................30
Goal 8: Application Logs ............................................................................................................32
Goal 9: Application Version Control ............................................................................................33
Goal 10: Information Storage and Privacy ...................................................................................34
Goal 11: Application Configuration Management ........................................................................36
Goal 12: Secure Application Development and Management ........................................................38
Goal 13: Cryptography, Key Management and HSM .....................................................................41
Goal 14: Resiliency against Reverse Engineering ..........................................................................42
4. ANNEXURE: Checklist ............................................................................................................44
4.1 Aadhaar Authentication Application Security Standards – Checklist for Web Applications ...........44
4.2 Aadhaar Authentication Application Security Standards – Checklist for Mobile Applications .......48
4.3 Aadhaar Authentication Application Security Standards – Checklist for Thick Client Applications .53
6 | P a g e
1. Introduction to the Aadhaar Authentication Application
Security Standard (AAASS)
Aadhaar Authentication Application Security Standard has been developed by UIDAI to assist developers and
various system integrators and other TSPs (Technical Service Provider) engaged by requesting entities in
developing authentication applications. The standard also provides developers with standard best practices and
testing requirements to build a secure application by leveraging other standards and best practices such as PA-
DSS, OWASP Top 10, OWASP MASC, SANS 25 etc.
At a high level, the standard details out requirements for the following domains:
S. No.
Domain (Goal) Applicability
Goal 1
Protect Aadhaar holder data
Applicable to web, mobile and thick-client applications
Goal 2
Architecture, Design and Threat Modelling
Goal 3
Authentication API compliance and Encryption
Goal 4
Delivery of consent message for Aadhaar authentication within application
Goal 5
Operator Authentication and Session Management
Goal 6
Secure Network Communication
Goal 7
Aadhaar Authentication Logs
Goal 8
Application Logs
Goal 9
Application Version Control
Goal 10
Information Storage and Privacy
Goal 11
Application Configuration Management
Goal 12
Secure Application Development and Management
Goal 13
Cryptography, Key Management and HSM
Goal 14
Resiliency against Reverse Engineering Applicable to only mobile and
thick-client applications
7 | P a g e
Prior to deployment of the application in the production environment, a requesting entity shall ensure
that the application meets all the requirements of the AAASS satisfactorily.
8 | P a g e
2. Aadhaar Authentication Application Security Standard -
Requirements
Minimum-security requirements for web, mobile and thick-client applications used for Aadhaar
authentication purposes across each of the goals defined in section 1 are listed below.
Follow the given hyperlinks in the table to view the requirements in detail.
S. No.
Applicability Requirements Referenced from the Aadhaar Act/
Regulations/ other standard / guideline / best practice
GOAL 1: Protect Aadhaar holder data
G1 Common Requirements
1. Mask Aadhaar number on input
2. Mask Aadhaar number on display
3. Do not send Aadhaar number in the URL in cleartext
4. Ensure Aadhaar number is not auto populated
5. Encrypt transmission of Aadhaar number across open, public networks
6. Perform Aadhaar number validation checks
7. Provide Virtual ID as an alternative input option
8. Wherever possible capture domain specific identifier or ANCS token or Virtual ID at the front-end
1. Industry best practices (banking)
2. PA-DSS1 (Requirement 2 – 2.1) 3. PA-DSS (Requirement 5 -5.2.10),
OWASP ASVS 4.02 (Control 3), Aadhaar (Sharing of information) Regulations 2016, Clause (6) (Point 4)
4. PA-DSS ((Requirement 11 - 11.2), Industry best practices
5. Aadhaar (Sharing of information) Regulations 2016, Clause (6) (Point 4), PA-DSS (Requirement 1)
6. Aadhaar API specifications (version 2.5), Aadhaar Auth regulations Clause (19) b
7. UIDAI circular dated 10 January 2018 – Implementation of Virtual ID, UID token and Limited KYC – Point number 3(1)
8. Requesting Entity Checklist v2.0
Additional Requirements for Web Applications
9. Ensure there is no local storage of Aadhaar Number / PID block
9. Auth Regulations Chapter III Clause 17. (1) (a), (b) and (c)
Additional Requirements for Mobile Applications
10. Ensure there is no local storage of Aadhaar Number / PID block in Shared preference folder
10. Auth Regulations Chapter III Clause 17. (1) (a), (b) and (c)
1 Payment Card Industry (PCI) Payment Application Data Security Standard (PA DSS) version 3.2 2 Open Web Application Security Project (OWASP) Application Security Verification Standard (ASVS) 4.0
9 | P a g e
Additional Requirements for Thick-client Applications
11. Ensure there is no local storage of Aadhaar Number / PID block in system volatile memory
11. Auth Regulations Chapter III Clause 17. (1) (a), (b) and (c)
GOAL 2: Architecture, Design and Threat Modelling
G2 Common Requirements
1. Ensure all third-party components used by the application are verified
2. Ensure that security controls are enforced on both the client side and server side
3. Ensure that the high-level architecture is verified
4. Ensure that the security testing is performed as part of the development lifecycle
1. OWASP MASC 0.9.3 2. OWASP MASC 0.9.3 3. OWASP MASC 0.9.3 4. OWASP MASC 0.9.3
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
5. Ensure that connecting clients use the current version of the mobile application
6. Ensure that the remote endpoints are verified
5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
7. Ensure that connecting clients use the current version of the thick client application
8. Ensure thick client application architecture is secure
7. OWASP MASC 0.9.3
GOAL 3: Authentication API compliance and Encryption
G3 Common Requirements
1. Refer the latest UIDAI API specifications for implementing API available on UIDAI website
2. Ensure application authentication API is protected using appropriate access control
3. Ensure PID block is encrypted on capture
1. Aadhaar API specifications (Version 2.5)
2. OWASP ASVS 4.0 (Control 13), SANS Top 25
3. Auth Regulations, Chapter II, Clause 7 (2) and (3), Clause 9 (1) and (5)
4. UIDAI circular on use of registered devices.
5. Auth Regulations Chapter II Clause 8 (2)
10 | P a g e
4. Ensure use of Registered Devices for capturing biometrics
5. Ensure latest API specifications is in use
6. Implement OTP verification controls in front-end application
6. PA DSS (Requirement 1 – 1.1.2), Industry best practices (banking)
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
No additional requirements
Additional Requirements for Thick-client Applications
No additional requirements
GOAL 4: Delivery of disclosure of information / consent message for Aadhaar authentication within the application
G4 Common Requirements
1. Ensure disclosure of information / consent is provided prior to Aadhaar authentication
2. Implement the functionality to change the text of disclosure of information/consent to local language
3. Ensure disclosure of information/consent checkbox is not ticked by default
4. Ensure provision for sharing disclosure of information/ consent message with differently abled persons is in place
5. Ensure disclosure of information/consent is provided separately each time before carrying out authentication
6. Ensure appropriate consent implementation in case Aadhaar authentication is mandatory by law
Note: Compliance to the disclosure of information / consent requirement also depends on the implementation and not just including the text and controls in the application.
1. Authentication Regulations Chapter II, Clause 6. (1)(2), Aadhaar act section 8
2. Authentication Regulations Chapter II, Clause 6. (1)(2), Aadhaar act section 8
3. Authentication Regulations Chapter II, Clause 6. (1)(2), Aadhaar act section 8
4. Requesting Entity Compliance Checklist V2.0. dated 30.01.2019 - Point number 1(j)
5. Aadhaar act section 8, Authentication Regulations Chapter II, Clause 6. (1)(2)
6. Sharing of Information Regulation, Chapter II, Clause 5. (1b)
11 | P a g e
7. Ensure appropriate consent implementation in case Aadhaar authentication is voluntary by law
7. Sharing of Information Regulation, Chapter II, Clause 5. (1b)
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
No additional requirements
Additional Requirements for Thick-client Applications
No additional requirements
GOAL 5: Operator Authentication and Session Management
G5 Common Requirements
1. Ensure operator authentication is performed for accessing the application
2. Implement two factor authentication for the operator login
3. Implement Password hygiene controls
4. Ensure ‘Remember Me’ option is disabled, and login credentials are not stored anywhere
1. UIDAI Information Security Policy - External Ecosystem AUA-KUA version 3.5- Section 2.11 (2)
2. OWASP ASVS 4.0 (Control 2) 3. UIDAI IS Policy version 3.5
section 7, PA DSS (Requirement 3 – 3.1.2), OWASP Secure coding, OWASP ASVS 4.0 (Control 2), SANS Top 25
4. OWASP MASC 0.9.3
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
5. Ensure authentication is performed at the remote endpoint
6. Ensure that the remote endpoint uses randomly generated access tokens to authenticate
7. Ensure that the remote endpoint terminates the existing session when the user logs out
8. Ensure that the remote endpoint implements an exponential back-off
5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3 7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3 9. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
12 | P a g e
9. Ensure that biometric authentication, if any, is not event-bound
GOAL 6: Secure Network Communication
G6 Common Requirements
1. Ensure that data is encrypted on the network using TLS
2. Ensure that the TLS settings are in line with current best practices
3. Ensure that the app verifies the X.509 certificate of the remote endpoint
4. Ensure that application doesn’t rely only on insecure communication channels (email or SMS) for critical operations
1. OWASP MASC 0.9.3 2. OWASP MASC 0.9.3 3. OWASP MASC 0.9.3 4. OWASP MASC 0.9.3
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
5. Ensure that the app either uses its own certificate store, or pins the endpoint certificate
5. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
GOAL 7: Aadhaar Authentication Logs
G7 Common Requirements
1. Ensure for each Aadhaar authentication request (auth, e-KYC etc.) audit log is generated with all the mandatory fields
2. Ensure logs are stored online for 2 years and archived for 5 years (even if the application has been decommissioned, requirement for log maintenance prevails)
1. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 18. (1) and Notice for AUA/KUA [F. No.-11020/205/2017-UIDAI (Auth-I)] dated 25/July/2017
2. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 18. (1)
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
No additional requirements
13 | P a g e
Additional Requirements for Thick-client Applications
No additional requirements
GOAL 8: Application Logs
G8 Common Requirements
1. Ensure Aadhaar Application logs are maintained
2. Ensure Application facilitates centralized logging
1. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 18. (1)
2. PA DSS (Requirement 4 – 4.1 - 4.5), OWASP ASVS 4.0 (Control 2)
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
No additional requirements
Additional Requirements for Thick-client Applications
No additional requirements
GOAL 9: Application Version Control
G9 Common Requirements
1. Ensure a unique application version number is maintained using a version control system
2. Ensure different nomenclature is used for pre-production and production application version
3. Ensure a Change Management Form is maintained for each application level change
1. PA DSS (Requirement 5 -5.3), OWASP ASVS 4.0 (Appendix C)
2. PA DSS (Requirement 5 – 5.3) 3. UIDAI Information Security
Policy - External Ecosystem AUA-KUA version 3.5-, Section 2.14, PA DSS (Requirement 5 – 5.3), OWASP best practices
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
No additional requirements
Additional Requirements for Thick-client Applications
No additional requirements
GOAL 10: Information Storage and Privacy
14 | P a g e
G10 Common Requirements
1. Ensure core biometric information is not stored anywhere in the application/system
2. Ensure that e-KYC data is stored in an encrypted manner within the database tables
3. Ensure resident Data (e-KYC and Aadhaar) is not stored on a server connected to the internet
4. Ensure that no sensitive data is written to application logs
5. Ensure that no sensitive data is shared with third parties
6. Ensure that the application does not store any sensitive data in temporary memory
1. Aadhaar (Authentication) Regulations 2016 Chapter III Regulation number 17. (1) (a), (b) and (c)
2. Authentication) Regulations 2016 Chapter III Regulation number 16. (3), PA DSS (Requirement 2 – 2.3)
3. PA DSS (Requirement 9) 4. OWASP MASC 0.9.3 5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
7. Ensure that system credential storage facilities are used appropriately
8. Ensure that the keyboard cache is disabled on text inputs
9. Ensure that the clipboard is deactivated on text fields
10. Ensure that no sensitive data is included in backups.
11. Ensure that the app removes sensitive data from views while running in background
12. Ensure that the app does not hold sensitive data in memory longer than necessary
13. Ensure that the app enforces a minimum device-access-security policy
7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3 9. OWASP MASC 0.9.3 10. OWASP MASC 0.9.3 11. OWASP MASC 0.9.3 12. OWASP MASC 0.9.3 13. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
14. Ensure that system credential storage facilities are used appropriately
14. OWASP MASC 0.9.3 15. OWASP MASC 0.9.3 16. OWASP MASC 0.9.3
15 | P a g e
15. Ensure that no sensitive data is included in files, registry or computer memory
16. Ensure that the app does not hold sensitive data in memory longer than necessary
GOAL 11: Application Configuration Management
G11 Common Requirements
1. Ensure the configuration parameters are not hardcoded in the application code
2. Ensure environment variables or DB calls are used to invoke application parameters
3. Ensure license keys are stored in config or properties file
4. Ensure proper mapping between sub-AUAs and their respective sub-AUA code is maintained (if applicable)
1. OWASP ASVS 4.0 (Control 14) 2. OWASP ASVS 4.0 (Control 14),
PA DSS (Requirement 5 – 5.1) 3. OWASP ASVS 4.0 (Control
3,5,9,13,14) 4. Aadhaar Authentication User
Agency Agreement version 4.0 Clause 3.1
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
5. Ensure that the app is signed and provisioned with valid certificate.
6. Ensure that the app has been built in release mode
7. Ensure that debugging code has been removed
8. Ensure that the error handling logic is verified
5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3 7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
9. Ensure that the app is signed and provisioned with valid certificate.
10. Ensure that the error handling logic is verified
9. OWASP MASC 0.9.3 10. OWASP MASC 0.9.3
GOAL 12: Secure Application Development and Management
G12 Common Requirements
1. Ensure that the application is tested for at the minimum OWASP Top 10, SANS Top 25 controls before go-live testing. Result of testing should be documented
1. Authentication) Regulations 2016 Chapter III, Regulation number 14. (1) (h) ,19, OWASP Top 10, SANS Top25, PA DSS (Requirement 7 – 7.1-7.3)
2. OWASP Secure coding guidelines
16 | P a g e
2. Ensure OWASP secure coding guidelines are referred to, for code best practices
3. Ensure periodic source code reviews and VAPT assessments are conducted for the application
4. Ensure measures are deployed to prevent tampering of deployed code
5. Ensure applications are developed in a way to prevent common coding vulnerabilities in software development processes
6. Ensure secure development trainings are provided to the developers
7. Ensure an updated application documentation is maintained
3. Authentication) Regulations 2016 Chapter III, Regulation number 14. (1) (h), PA DSS (Requirement 7 – 7.1-7.3)
4. OWASP ASVS 4.0 (Control 1, 10), PA DSS (Requirement 5 -5.1.5)
5. PA DSS (Requirement 5 -5.1.7) 6. PA DSS (Requirement 14 –14.1-
14.3) 7. PA DSS ((Requirement 5 -5.1.5)
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
8. Ensure that all inputs from external sources are validated
9. Ensure that the app does not export sensitive functionality via custom URL
10. Ensure that JavaScript is disabled in WebViews unless explicitly required
11. Ensure that the object serialization in API is verified
8. OWASP MASC 0.9.3 9. OWASP MASC 0.9.3 10. OWASP MASC 0.9.3 11. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
12. Ensure a registration process is built into the application to ensure only authorized personnel can install and use the application
GOAL 13: Cryptography, Key Management and HSM
G13 Common Requirements
1. Ensure HSM is provisioned for Key Management
1. Notice for AUA/KUA [F. No.-11020/204/2017-UIDAI (Auth-I)] dated 22/June/2017 Point 4, OWASP ASVS 4.0 (Clause 2)
Additional Requirements for Web Applications
No additional requirements
17 | P a g e
Additional Requirements for Mobile Applications
2. Ensure that the app does not rely on symmetric cryptography with hardcoded keys
3. Ensure that the app doesn't re-use the same cryptographic key for multiple purposes
4. Ensure that the app does not use deprecated cryptographic protocols
2. OWASP MASC 0.9.3 3. OWASP MASC 0.9.3 4. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
GOAL 14: Resiliency against Reverse Engineering
G14 Common Requirements
No common requirements
Additional Requirements for Web Applications
No additional requirements
Additional Requirements for Mobile Applications
1. Ensure that the app implements two or more functionally independent methods of root detection
2. Ensure tamper detection is implemented
3. Ensure SSL pinning is implemented
4. Ensure detection of widely used reverse engineering tools
5. Ensure detection of emulator 6. Ensure detection of
modification of process memory
7. Ensure all executable files and libraries belonging to the app are verified
8. Ensure code obfuscation is implemented
1. OWASP MASC 0.9.3 2. OWASP MASC 0.9.3 3. OWASP MASC 0.9.3 4. OWASP MASC 0.9.3 5. OWASP MASC 0.9.3 6. OWASP MASC 0.9.3 7. OWASP MASC 0.9.3 8. OWASP MASC 0.9.3
Additional Requirements for Thick-client Applications
9. Ensure tamper detection is implemented
10. Ensure all executable files and libraries belonging to the app are verified
11. Ensure code obfuscation is implemented
9. OWASP MASC 0.9.3 10. OWASP MASC 0.9.3 11. OWASP MASC 0.9.3
Press ALT + Left Arrow Key to go back
18 | P a g e
3. Aadhaar Authentication Application Security Standard –
Detailed Requirements
Goal 1: Protect Aadhaar Holder Data
Requirement Description
Common Requirements Requirement 1: Mask Aadhaar
number on input
• Application should mask the Aadhaar number/ VID while entering in the input field. Aadhaar number/ VID input field should be treated as a password field with Aadhaar number/ VID getting masked while being inputted.
• If any physical copy/form is collected which has Aadhaar number mentioned
on it, then before storing the hard copies, Aadhaar number should be
redacted. This is in case the law does not permit full storage of Aadhaar
number.
Note: In order to reduce the instances of
incorrect data entry by the operator /
resident, which may be the case due to
masked data display, application can implement functionality to allow users to
see Aadhaar number entered by placing Show/Hide icon within the Aadhaar
number input field.
Requirement 2: Mask Aadhaar
number on display
• Aadhaar number displayed anywhere on the application screen should be
masked by default. The application should not display full Aadhaar number
for any of the user roles.
• In internal systems as well, Aadhaar number shall be displayed only if there
is a legitimate business reason, otherwise the same shall remain masked
completely or only the last 4 digits shall be displayed for legitimate business
reason.
Press ALT + Left Arrow Key to go back
19 | P a g e
• Aadhaar number shall not be printed on any receipt/slip given by the
agency. If there is any business requirement to display/print Aadhaar
number, only the last 4 digits shall be displayed.
What is Masking of Aadhaar Number?
• Masking is done to ensure that the Aadhaar number is redacted / removed
in such a manner that there are no means available to retrieve the complete
12-digit Aadhaar number.
• Mask Aadhaar number when displayed; the first eight digits should be
redacted / removed and last four digits are the maximum number of digits
that you may display.
Masking Convention
Correct Incorrect XXXX-XXXX-1234 1234-XXXX-1234 1234-XX34-XXXX
Requirement 3: Do not send
Aadhaar number in the URL in
cleartext
• While sending out Aadhaar number/ VID from one page to another, ensure that it is transmitted securely and in an encrypted manner. Aadhaar number should never be sent out as a part of URL in get requests.
Get and Post Requests
Requirement 4: Ensure Aadhaar number is not
auto populated
• Aadhaar number/ VID should not be auto populated by the application.
• Aadhaar number/ VID should not be stored in volatile memory or cache.
Incorrect
Correct
GET requests https://www.test.com/test/demo_form.php?aadhaarNo=123412341234
Post requests url = ' https://www.test.com/test/python/demopage.php'
myobj = {'aadhaarNo': '{Encrypted Aadhaar Number}'}
Press ALT + Left Arrow Key to go back
20 | P a g e
Aadhaar Number should not be auto populated
Requirement 5: Encrypt
transmission of Aadhaar number
across open, public networks
• Aadhaar number/ VID when transmitted across open, public networks (internet) should be encrypted using strong cipher suites.
• Use strong cryptography and security protocols such as SSL/TLS, SSH or IPSec to safeguard sensitive Aadhaar holder data during transmission over open, public networks (e.g. Internet, wireless technologies etc.).
• Acceptable: o Encryption algorithms and key lengths as recommended by NIST. o The current recommendations by NIST and standards used by UIDAI
are as follows: ▪ RSA 2048 for asymmetric encryption ▪ AES 256 for symmetric encryption ▪ SHA-256 for hashing
• Not Acceptable / Should not be used (Due to several known vulnerabilities in them):
o Ciphers less than 128 for symmetric and less than 2048 for asymmetric encryption
o Null cipher suites (no encryption) o No anonymous Diffie-Hellman (no authentication) o Weak protocols, e.g. SSLv2 o Weak Hash algorithms - MD5 Hash, SHA-1
• Hash Algorithm: o MD5 - Should not be used. It is weak and there are practical known
attacks for it. o SHA: - SHA-1 disallowed after 2013 for digital signature. SHA-256+
are acceptable.
Requirement 6: Perform Aadhaar
number validation checks
• Application should perform input validation checks at the time of capturing Aadhaar number/ VID to avoid sending junk data to UIDAI.
• Aadhaar number length check o Ensure length of Aadhaar number length is 12 and in case of VID the
length should be 16. o Ensure Aadhaar number/ VID entered is numeric and no alphabets or
special characters are entered. o Ensure Aadhaar number/ VID entered is a valid verhoeff number.
Press ALT + Left Arrow Key to go back
21 | P a g e
Aadhaar number validation checks to identify junk / incorrect data
Requirement 7: Provide Virtual ID as an alternative
input option
• Ensure that there is a provision to input Virtual ID in lieu of Aadhaar number.
• Application screen should have an option to provide Virtual ID in addition to Aadhaar number as input. Similar changes in the backend should be made to handle Virtual ID as input.
Application should provide option to enter Virtual ID
Requirement 8: Wherever
possible capture domain specific
identifier or ANCS token or Virtual ID at the front-
end
• Wherever possible, only the domain specific identifier should be captured at the device end and not the Aadhaar number. For e.g. ― Wherever possible, AUAs should only capture their domain specific identifier (bank a/c no, ration card no, along with family member id, LPG customer account no, etc.)
• On the AUA server, when forming the authentication input XML, retrieve the Aadhaar number from AUA database using domain specific identifier.
• In place of using Aadhaar number to ensure secrecy of the number, it is recommended to use temporary tokens mapped to the Aadhaar number – such as Virtual ID or ANCS token.
Note: Aadhaar Number Capture Service Token or ANCS Token” means an encrypted Aadhaar number generated for an Aadhaar number by the Authority for completion of an authentication transaction. ANCS Token shall be valid for a short period of time as prescribed by the Authority from time to time.
Note: ANCS token and Virtual ID cannot be retained by the entities in their permanent storage systems.
Additional Requirements for Web Applications Requirement 9:
Ensure there is no local / temporary
storage of Aadhaar number
/PID block
• Ensure that Aadhaar number/Virtual ID inputted by the user is not stored in any form in permanent or temporary storage. For OTP based authentication, the same may be stored until the OTP transaction is successful or OTP has expired.
• Ensure that PID block is not stored anywhere within the system.
Additional Requirements for Mobile Applications Requirement 10:
Ensure there is no local / temporary
• Ensure that Aadhaar number/Virtual ID inputted by the user is not stored in any form in permanent or temporary storage. For OTP based authentication,
Press ALT + Left Arrow Key to go back
22 | P a g e
storage of Aadhaar number
/PID block in Shared
preference folder
the same may be stored until the OTP transaction is successful or OTP has expired.
• Ensure that PID block is not stored anywhere within the system.
Additional Requirements for Thick-client Applications Requirement 11:
Ensure there is no local / temporary
storage of Aadhaar number
/PID block in system volatile
memory
• Ensure that Aadhaar number/Virtual ID inputted by the user is not stored in any form in permanent or temporary storage. For OTP based authentication, the same may be stored until the OTP transaction is successful or OTP has expired.
• Ensure that PID block is not stored anywhere within the system.
Goal 2: Architecture, Design and Threat Modelling
Requirement Description
Common Requirements Requirement 1: Ensure all third-
party components used by the application
are verified
• Ensure all third-party components used by the application, such as libraries
and frameworks, are identified, and checked for known vulnerabilities.
• Ensure all third-party components have been assessed (associated risks)
before being used or implemented. Additionally, verify that a process is in
place to ensure that each time a security update for a third-party component
is published, the change is inspected, and the risk is evaluated.
Requirement 2: Ensure that
security controls are enforced on both the client side and server
side
• Ensure security controls such as input validation, authentication, authorization etc. should not only be enforced at client side. These controls should also be checked at the remote endpoint.
Requirement 3: Ensure that the
high-level architecture is
verified
• Verify that a high-level architecture for the application and all connected
remote services has been defined and security has been addressed in the
architecture.
• Verify that data considered sensitive in the context of the application is
clearly identified.
• Verify all app components are defined in terms of the business functions
and/or security functions they provide.
•
Press ALT + Left Arrow Key to go back
23 | P a g e
Requirement 4: Ensure that the
security testing is performed as part
of the development
lifecycle
• Ensure that security testing is performed as part of the software
development lifecycle and not only after completion of development of the
application.
Additional Requirements for Mobile Applications Requirement 5:
Ensure that connecting clients
use the current version of the
mobile application
• Verify the version of the application which is connecting to the server.
• Only allow the latest version of the application to communicate with the
AUA/KUA server.
Requirement 6: Ensure that the
remote endpoints are verified
• Ensure that the application verifies the remote endpoint (server) before
establishing a connection with it.
Additional Requirements for Thick-client Applications Requirement 7:
Ensure that connecting clients
use the current version of the
thick client application
• Verify the version of the application which is connecting to the server.
• Only allow the latest version of the application to communicate with the
AUA/KUA server.
Requirement 8: Ensure thick
client application architecture is
secure
• Thick client application follows client-server architecture. They may have two-tier or three-tier architecture.
• In two-tier architecture, the application interacts directly with the database. This is usually seen in legacy applications and is considered insecure. An example of a thick client application can be a JAVA or VB.NET, Visual Basic application that communicates with a database.
• In three-tier architecture, the application interacts with the webserver which in turn interacts with the database.
• Below is the list of vulnerabilities that should be mitigated on thick clients on top of the business logic checks.
Vulnerabilities Thick Client based vulnerabilities
Improper error handling Applicable
SQL Injection Applicable
Cross Site Scripting Not applicable – browser-based vulnerability
Clickjacking attacks Not applicable – browser-based vulnerability
Press ALT + Left Arrow Key to go back
24 | P a g e
Parameter Tampering Applicable
Insecure Storage Applicable
Denial of Service Applicable
Reverse engineering Applicable
Broken access control Applicable
Session management Applicable
Goal 3: Authentication API compliance and Encryption
Requirement Description
Common Requirements Requirement 1: Refer the latest
UIDAI API specifications for implementing API
available on UIDAI website
The current API specifications in use are:
• Authentication API Specification - https://uidai.gov.in/images/resource/aadhaar_authentication_api_2_5.pdf
• e-KYC API Specification - https://uidai.gov.in/images/resource/aadhaar_ekyc_api_2_5.pdf
• OTP API Specification - https://uidai.gov.in/images/resource/aadhaar_otp_request_api_2_5.pdf
Requirement 2: Ensure
application authentication
API is protected using appropriate
access control
• To ensure critical API endpoints can only be accessed by authorized
personnel, and applications, access control mechanism must be in place to
access the authentication APIs.
• Implement authentication check at the API gateway to ensure only
authorized user can access the application.
• Implement captcha before each API call.
• Validate Referrer header at the server side.
Requirement 3: Ensure PID block is encrypted on
capture
• PID block data should be encrypted as per the API specifications. In the
current implementation encryption is done with a dynamic session key using
AES-256 symmetric algorithm (AES/GCM/NoPadding). Session key, in turn, is
encrypted with 2048-bit UIDAI public key using asymmetric algorithm
(RSA/ECB/PKCS1Padding).
• For OTP based transaction, PID block encryption should be as per the API
specifications.
• OTP should not travel from client side to server side in plain text.
Press ALT + Left Arrow Key to go back
25 | P a g e
Requirement 4: Ensure use of
Registered Devices for capturing
biometrics
• Application should capture the biometric information of the Aadhaar
number holder using certified and registered biometric devices.
• Application should not allow usage of non-registered devices for capturing
biometrics by implementing a technical control to detect if the biometric
device being used is registered on not.
Requirement 5: Ensure latest API
specifications is in use
• The application should use the latest Authentication API, e-KYC API, OTP API,
Tokenization API.
Requirement 6: Implement OTP
verification controls in front-end application
• Restrict OTP resend to a maximum of 3 tires.
• Disable the option to resend OTP for 90 seconds or more.
• In case there is incorrect OTP submission and authentication failure for two
or more times, application should redirect to the first page after showing
appropriate message. Aadhaar number input and consent should be taken
again for the new transaction.
• OTP should be masked while entering.
Goal 4: Delivery of consent message for Aadhaar authentication within
application
Note: Compliance to the disclosure of information / consent requirement also depends on the
implementation and not just including the text and controls in the application.
Requirement Description
Common Requirements Requirement 1:
Ensure disclosure of information /
consent is provided prior to
Aadhaar authentication
• Application should ensure that the disclosure of information/consent
message is provided before Aadhaar authentication.
• Disclosure of information/consent message should be given prior to
submission of Aadhaar number in the application.
Requirement 2: Implement the functionality to
change the text of disclosure of
information/cons
• Ensure that the text of disclosure of information/consent is provided to the
user in their local language of choice.
Press ALT + Left Arrow Key to go back
26 | P a g e
ent to local language
Requirement 3: Ensure disclosure
of information/cons
ent checkbox is not ticked by
default
• While implementing the electronic consent, it should be ensured that the consent checkbox is not ticked by default on the application.
Consent checkbox should not be pre-ticked
Requirement 4: Ensure provision
for sharing disclosure of information/
consent message with differently abled persons is
in place
• Ensure appropriate provisions for sharing disclosure of information/consent message with differently abled divyangjans are there in place.
• For example, in case of visually challenged persons, one such provision can be to have an option within the application to speak out consent message displayed on the application screen.
Not Allowed <input type="checkbox" name="Aadhaar Consent" value="Consent" checked> Allowed <input type="checkbox" name="Aadhaar Consent" value="Consent" >
Press ALT + Left Arrow Key to go back
27 | P a g e
Requirement 5: Ensure disclosure
of information/cons
ent is provided separately each
time before carrying out
authentication
• It is mandatory to provide disclosure of information/consent each time
before carrying out authentication. Ensure that the application is taking
consent each time.
Requirement 6: Ensure
appropriate consent
implementation in case Aadhaar authentication is
mandatory by law
• In cases where Aadhaar number is required mandatorily for availing
services/benefits, the same should be mentioned in the disclosure of
information/consent message along with the law/regulation mandating it.
Requirement 7: Ensure
appropriate consent
implementation in case Aadhaar authentication is voluntary by law
• In cases where there are alternatives to submission of Aadhaar number, the same should be displayed on the application screens prominently. Also, the alternatives should be mentioned in the disclosure of information/consent message.
• Consent must be taken from the Aadhaar number holder to demonstrate that the user voluntarily chose Aadhaar authentication over other available alternatives.
Alternatives to Aadhaar displayed in the application
Press ALT + Left Arrow Key to go back
28 | P a g e
Goal 5: Operator Authentication and Session Management
Requirement Description
Common Requirements Requirement 1: Ensure operator authentication is
performed for accessing the application
• Application should implement operator authentication using a unique
username and password for each operator.
• Ensure that one concurrent session per user is allowed at a time i.e. parallel
login sessions are not allowed for the operator.
Note: Optionally MAC binding / device binding functionality to restrict one
operator from logging in through multiple devices can also be implemented for
operator assisted applications.
Requirement 2: Implement two
factor authentication for the operator login
• Ensure two factor authentication (2FA) is implemented for operator login. AUA/KUA is advised to use strong second factor like OTP / TOTP etc. for operator login. The OTP / TOTP here is non-Aadhaar based unless mandated by law to leverage Aadhaar based OTP / TOTP authentication for operator login.
• Ensure that second factor of authentication exists at the remote endpoint (server) and the 2FA requirement is consistently enforced.
Two Factor Login
Requirement 3: Implement
Password hygiene controls
• New credentials should be created for each operator.
• Default passwords should be changed on first login.
• Password complexity, session timeout period, account lockout threshold etc.
should be set as per the UIDAI IS policy for AUA/KUAs.
• Passwords should not be hard coded in the source code of the application.
• Automated logon processes should be disabled.
• Access to admin/root password should be with authorized users only.
Requirement 4: Ensure
‘Remember Me’ option is
disabled, and login credentials
are not stored anywhere.
• Ensure that the application does not store user credentials and use the same for future logins.
• Ensure that the application does not allow browsers / mobile device / desktop utilities to store user credentials for future use.
Press ALT + Left Arrow Key to go back
29 | P a g e
Additional Requirements for Mobile Applications and Thick-client Applications Requirement 5:
Ensure authentication is performed at the remote endpoint
• Ensure that all authentication related activities are performed at the remote endpoint (server side).
Requirement 6: Ensure that the
remote endpoint uses randomly
generated access tokens to
authenticate
• Ensure remote endpoint uses randomly generated access tokens to authenticate client requests without sending the user's credentials.
Requirement 7: Ensure that the
remote endpoint terminates the existing session when the user
logs out
• Ensure that user session is terminated at server side after a user logs out or closes the application.
Requirement 8: Ensure that the
remote endpoint implements an
exponential back-off
• Ensure that the remote endpoint implements an exponential back-off, or temporarily locks the user account, when incorrect authentication credentials are submitted excessive number of times.
Requirement 9: Ensure that biometric
authentication, if any, is not event-
bound
• Ensure that biometric authentication, if any, is not event-bound (i.e. using an API that simply returns “true” or “false”). Instead, it is based on unlocking the keychain / keystore.
Goal 6: Secure Network Communication
Requirement Description
Common Requirements Requirement 1: Ensure that data is encrypted on
the network using TLS
• Ensure that data is encrypted on the network using TLS. A secure channel should be used consistently throughout the app.
• Application should use TLS/SSL protocols when accessed via public networks
Press ALT + Left Arrow Key to go back
30 | P a g e
o If the application transmits, or facilitates transmission of Aadhaar data over public networks, the authentication application must support use of strong cryptography and security protocols (for example, SSL/TLSIPSEC, SSH, etc.) to safeguard Aadhaar data during transmission over open, public networks.
o Only trusted keys and certificates should be accepted. o The protocol in use should only support secure versions or
configurations. o The encryption strength should be appropriate for the encryption
methodology in use.
Requirement 2: Ensure that the
TLS settings are in line with current
best practices
• Ensure that TLS settings are in line with current best practices, as long as they are supported by the mobile operating system.
Requirement 3: Ensure that the app verifies the X.509 certificate
of the remote endpoint
• Ensure that the app verifies X.509 certificate of the remote endpoint when the secure channel is established. Only certificates signed by a valid CA should be accepted.
Requirement 4: Ensure that application
doesn’t rely only on insecure
communication channels (email
or SMS) for critical operations
• The application shall not rely on a single insecure communication channel (email or SMS) for critical operations, such as registration and account recovery. Additional channels which can be explored includes:
o Token o Push Notification o QR Code
Additional Requirements for Mobile Applications and Thick-client Applications Requirement 5: Ensure that the
app either uses its own certificate
store, or pins the endpoint certificate
• Ensure that the app either uses its own certificate store, or pins the endpoint certificate or public key, and subsequently does not establish connections with endpoints that offer a different certificate or key, even if it signed by a trusted CA.
Goal 7: Aadhaar Authentication Logs
Requirement Description
Press ALT + Left Arrow Key to go back
31 | P a g e
Common Requirements Requirement 1: Ensure for each
Aadhaar authentication
request (auth, e-KYC etc.) audit log is generated with all the mandatory
fields
• Aadhaar authentication logs should mandatorily contain –
o Aadhaar reference key3 (Global KUA)
o UID Token (both Global and Local KUA)
o Parameters submitted as part of request XML
o Parameters received (from UIDAI) as part of authentication response
o Record of disclosure of information and consent
• Ensure Aadhaar authentication logs do not contain Aadhaar number.
• Ensure device identifiers are stored in the logs.
• Ensure that date and time stamp for request and response is included in log
entries.
• Aadhaar number/ VID captured during user input should not be stored
anywhere in the system.
Note: Aadhaar number can only be stored in the Aadhaar Data Vault and only those entities which receive complete Aadhaar number from the UIDAI in authentication response can store Aadhaar number (that too in the Aadhaar Data Vault). All other agencies which have not been allowed to store Aadhaar number cannot store Aadhaar number anywhere within their systems.
Requirement 2: Ensure logs are
stored online for 2 years and
archived for 5 years (even if the application has
been decommissioned, requirement for log maintenance
prevails)
• Ensure that Aadhaar authentication logs are maintained online for a period
of 2 years.
• Upon expiry of the 2-year period, the logs shall be archived and stored for a
period of 5 year or the number of years as required by the laws or
regulations governing the entity (whichever is later).
• The logs shall be deleted upon expiry of the aforementioned period unless
required to be retained by a court of law or for pending disputes.
3 For reference key implementation, refer UIDAI circular https://uidai.gov.in/images/resource/Circular_Reference_Key_02082017.pdf
Press ALT + Left Arrow Key to go back
32 | P a g e
Goal 8: Application Logs
Requirement Description
Common Requirements Requirement 1: Ensure Aadhaar Application logs are maintained
• The application must log all user access and should be able to link all
activities to individual users (Operators).
• Log shall contain identifier for type of event.
• Ensure date and timestamp for each event is logged.
• Ensure success or failure indication for each transaction is included in log
entries.
• Application must provide automated audit trails to reconstruct the following
events at the minimum:
o All actions taken by any individual with administrative privileges as
assigned in the application.
o Invalid logical access attempts.
o Use of, and changes to the application’s identification and
authentication mechanisms (including but not limited to creation of
new accounts, elevation of privileges, etc.), and all changes,
additions, deletions to application accounts with root or
administrative privileges
o Initialization, stopping, or pausing of the application audit logs.
o Creation and deletion of system-level objects within or by the
application.
o Access to application audit trails managed by or within the
application.
Requirement 2: Ensure
Application facilitates
centralized logging
Examples of this functionality may include, but are not limited to:
• Logging via industry standard log file mechanisms such as Common Log File System (CLFS), Syslog, delimited text, etc.
• Providing functionality and documentation to convert the application’s proprietary log format into industry standard log formats suitable for prompt, centralized logging.
Press ALT + Left Arrow Key to go back
33 | P a g e
Goal 9: Application Version Control
Requirement Description
Common Requirements Requirement 1: Ensure a unique
application version number is maintained using a version control
system
• Production and pre-production environment should be physically and logically separated.
• Code repository tools such as SVN, GIT, SCCS, etc. can be used.
Requirement 2: Ensure different nomenclature is
used for pre-production and
production application
version
• The application developer must document and follow a software-versioning methodology as part of their system development lifecycle (SDLC).
Requirement 3: Ensure a Change
Management Form is
maintained for each application
level change
• Change management form with detailed description of the changes
implemented along with the version control information should be
maintained.
• Change-control procedures must be followed for all application changes.
• Change control procedures must follow the same software development
process that is followed during new releases.
• Maintain documentation of impact of change.
• Document approval of change by appropriate authorized parties.
• Conduct functionality testing to verify that the change does not adversely
impact the security of the system.
Press ALT + Left Arrow Key to go back
34 | P a g e
Goal 10: Information Storage and Privacy
Requirement Description
Common Requirements Requirement 1:
Ensure core biometric
information is not stored anywhere
in the application/syste
m
• PID block and core biometric information as defined in API specifications
should not be stored anywhere.
Requirement 2: Ensure that e-KYC data is stored in
an encrypted manner within the database
tables
• Ensure that the e-KYC data is stored in the databases in encrypted manner.
• Ensure the KYC data is not shared over a public network in plain text.
Requirement 3: Ensure resident Data (e-KYC and Aadhaar) is not
stored on a server connected to the
internet
• Resident data shall not be stored on servers with access to internet.
• Data storage component of the application shall not be on the same server or in the same network zone as the server on which the AUA/KUA application is running.
Requirement 4: Ensure that no
sensitive data is written to
application logs
• Ensure sensitive information such as user credentials, resident information etc. is not written to the application logs.
Requirement 5: Ensure that no
sensitive data is shared with third
parties
• Ensure that no sensitive data is shared with third parties unless it is a
necessary part of the architecture and is allowed by law.
Requirement 6: Ensure that the
application does not store any sensitive data
even in temporary
memory
• PID block and core biometric information as defined in API specifications
should not be stored anywhere including any temporary storage such as
application cache / browser cache / application temporary files.
• Storage of core biometric data including the PID block is strictly prohibited.
Additional Requirements for Mobile Applications
Press ALT + Left Arrow Key to go back
35 | P a g e
Requirement 7: Ensure that
system credential storage facilities
are used appropriately
• Ensure that the system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys.
Requirement 8: Ensure that the
keyboard cache is disabled on text
inputs
• Ensure the keyboard cache is disabled on text inputs that process sensitive data.
Requirement 9: Ensure that the
clipboard is deactivated on
text fields
• Ensure the clipboard is deactivated on text fields that may contain sensitive data.
Requirement 10: Ensure that no
sensitive data is included in backups.
• Ensure that sensitive data such as user credentials, eKYC data etc. is not included in backups.
Requirement 11: Ensure that the
app removes sensitive data
from views while running in
background
• Ensure that sensitive information is not viewed in the mobile while the application is running in background.
Requirement 12: Ensure that the
app does not hold sensitive data in memory longer than necessary
• Ensure the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.
Requirement 13: Ensure that the app enforces a
minimum device-access-security
policy
• Ensure the app enforces a minimum device-access-security policy, such as requiring the user to set a device passcode.
Additional Requirements for Thick-client Applications Requirement 14:
Ensure that system credential storage facilities
• Ensure that the system credential storage facilities are used appropriately to store sensitive data, such as user credentials or cryptographic keys.
Press ALT + Left Arrow Key to go back
36 | P a g e
are used appropriately
Requirement 15: Ensure that no
sensitive data is included in files,
registry or computer memory
• Ensure that the application does not write sensitive data in files, registry or computer memory.
Requirement 16: Ensure that the
app does not hold sensitive data in memory longer than necessary
• Ensure the app does not hold sensitive data in memory longer than necessary, and memory is cleared explicitly after use.
Goal 11: Application Configuration Management
Requirement Description
Common Requirements Requirement 1:
Ensure the configuration
parameters are not hardcoded in the application
code
• Ensure that application configurations such as database IP, database credentials etc. are not hardcoded.
Requirement 2: Ensure
environment variables or DB calls are used to
invoke application parameters
• Use environment variables or database calls to invoke application parameters.
Requirement 3: Ensure license
keys are stored in config or
properties file
• As a rule of thumb, ensure that no sensitive details such as license key are hardcoded in the application code that is distributed to the public/operators for usage.
Note: Security of license key is one of the most important aspect of developing and maintaining a secure Aadhaar authentication application. Storage of license
Press ALT + Left Arrow Key to go back
37 | P a g e
key in the application code (front-end) or any other system without having proper access control and security measures in place is strictly prohibited.
Requirement 4: Ensure proper
mapping between sub-AUAs and
their respective sub-AUA code is maintained (if
applicable)
• Ensure that mapping of sub-AUA and their code is maintained in the application to ensure proper log trail.
• Ensure that only sub-AUA license key and code is used when catering to sub-AUA requests.
Additional Requirements for Mobile Applications Requirement 5: Ensure that the
app is signed and provisioned with valid certificate.
• Ensure that the application code is signed and provisioned with a valid certificate issued by a CA.
Requirement 6: Ensure that the app has been
built in release mode
• Ensure that app has been built in release mode, with settings that are appropriate for a release build (e.g. non-debuggable).
Requirement 7: Ensure that
debugging code has been removed
• Ensure that debugging code has been removed, and the app does not log verbose errors or debugging messages.
Requirement 8: Ensure that the error handling logic is verified
• Ensure that error handling logic in security controls denies access by default.
Additional Requirements for Thick-client Applications Requirement 9: Ensure that the
app is signed and provisioned with valid certificate.
• Ensure that the application code is signed and provisioned with a valid certificate issued by a CA.
Requirement 10: Ensure that the error handling logic is verified
• Ensure that error handling logic in security controls denies access by default.
Press ALT + Left Arrow Key to go back
38 | P a g e
Goal 12: Secure Application Development and Management
Requirement Description
Common Requirements Requirement 1: Ensure that the application is
tested for at the minimum OWASP Top 10, SANS Top
25 controls before go-live
testing. Result of testing should be
documented
• Application should be tested against OWASP Top 10, SANS Top 25 controls at
the minimum before go-live testing. Result of testing should be documented.
• Actual Aadhaar data should not be used for testing. Only dummy data
available on UIDAI website shall be used.
• Test data and accounts should be removed before release.
Requirement 2: Ensure OWASP secure coding guidelines are referred to, for
code best practices
• Code changes should be reviewed by individuals other than the originating
code author, and by individuals who are knowledgeable in code-review
techniques and secure coding practices. Code reviews will ensure that the
code is developed according to secure coding guidelines.
• Appropriate corrections should be implemented prior to release.
• Code-review results should be reviewed and approved by management prior
to release.
• Code-review results should be documented with management approvals,
code author, code reviewer, and what corrections were implemented prior
to release.
Requirement 3: Ensure periodic
source code reviews and VAPT assessments are
conducted for the application
• Applications assessment should include, at the minimum: o Identification of new security vulnerabilities using reputable sources for
obtaining security vulnerability information. o Assigning a risk ranking to all identified vulnerabilities, including
vulnerabilities involving any underlying software or systems provided with or required by the application.
o Test applications and updates for the presence of vulnerabilities prior to release.
Requirement 4: Ensure measures are deployed to
prevent tampering of
deployed code
• Implement anti tamper mechanisms such as verifying the download source of application, verifying the application hash etc. to prevent application tampering.
• For web apps, implement checks on the application source code, such as File Integrity Monitoring (FIM) solution etc. to identify any unauthorized changes to the code at server side.
• For Mobile apps, implement features to prevent dynamic analysis of application using tools such as Frida, Xposed etc.
Press ALT + Left Arrow Key to go back
39 | P a g e
• For thick client apps, implement anti-tamper mechanism such as signature verification etc. on the application at client and server side.
• Implement mechanisms to prevent debugging of application code through obfuscation etc.
Requirement 5: Ensure
applications are developed in a way to prevent common coding vulnerabilities in
software development
processes
• At the minimum the application should cover the OWASP Top 10, SANS CWE Top 25, CERT Secure Coding, etc.):
o Injection flaws, particularly SQL injection. Also consider OS Command Injection, LDAP and XPath injection flaws as well as other injection flaws
o Buffer Overflow o Insecure cryptographic storage o Insecure communications o Improper error handling o Cross-site scripting (XSS) o Improper access control such as insecure direct object references,
failure to restrict URL access, and directory traversal) o Cross-site request forgery (CSRF) o Broken authentication and session management
Requirement 6: Ensure secure development trainings are
provided to the developers
• Provide trainings on secure development practices for application
developers, that are applicable to the developer’s job function and
technology used, for example:
o Secure application design.
o Secure coding techniques to avoid common coding vulnerabilities
(for example, vendor guidelines, OWASP Top 10, SANS CWE Top 25,
CERT Secure Coding, etc.).
o Managing sensitive data in memory.
Requirement 7: Ensure an updated
application documentation is
maintained
• Acceptable usage guidelines/ SOPs for applications should be documented and shared with operators.
• Develop a secure SDLC process and document the application development as per the SDLC.
• At the minimum the application documentation must include: o Technical Manual (Functional Requirement Specifications,
Technology Stack). o Software Source Code build process. o Usage Instructions. o Instructions for troubleshooting. o Deployment Diagram. o License specifications of libraries used. o API specifications along with endpoints, sample response, error
codes.
Additional Requirements for Mobile Applications
Press ALT + Left Arrow Key to go back
40 | P a g e
Requirement 8: Ensure that all
inputs from external sources
are validated
• Ensure all inputs from external sources and users are validated and, if necessary, they should be sanitized. This includes data received via UI, IPC mechanisms such as intents, custom URLs, and network sources.
Requirement 9: Ensure that the
app does not export sensitive functionality via
custom URL
• Ensure app does not export sensitive functionality via custom URL schemes, unless these mechanisms are properly protected.
Requirement 10: Ensure that JavaScript is disabled in
WebViews unless explicitly required
• In case the application requires the use of web views, JavaScript must be disabled in the same.
• For cases where JavaScript is needed for implementing application functionality, proper input sanitization must be performed.
Requirement 11: Ensure that the
object serialization in API is verified
• Ensure object serialization, if any, is implemented using safe serialization APIs.
Additional Requirements for Thick-client Applications Requirement 12:
Ensure a registration
process is built into the
application to ensure only authorized
personnel can install and use the
application
• Implement registration process in application such as product key based registration, account base registration, machine-based registration etc. to ensure that application is installed by authorized personnel only.
• Implement controls to restrict the number of registrations per product key/ account.
Press ALT + Left Arrow Key to go back
41 | P a g e
Goal 13: Cryptography, Key Management and HSM
Requirement Description
Common Requirements Requirement 1: Ensure HSM is
provisioned for Key Management
• Use of HSM is a mandatory requirement for storing various keys pertaining to Aadhaar related operations.
• Develop code to make API calls to the HSM device.
• Given below is a code snippet for HSM API call that can be used as reference:
Additional Requirements for Mobile Applications and Thick-client Applications Requirement 2: Ensure that the
app does not rely on symmetric cryptography
with hardcoded keys
• Ensure that the app does not rely on symmetric cryptography with hardcoded keys as a sole method of encryption.
Requirement 3: Ensure that the app doesn't re-use the same
cryptographic key for multiple
purposes
• Ensure that the application does not use the same key for multiple purposes. Eg: Keys used to encrypt locally stored data shall not be used for any other purpose such as encrypting user credentials etc. in the application.
Requirement 4: Ensure that the
app does not use deprecated
cryptographic protocols
• Ensure that the app does not use cryptographic protocols or algorithms that are widely considered deprecated for security purposes.
Press ALT + Left Arrow Key to go back
42 | P a g e
Goal 14: Resiliency against Reverse Engineering
Requirement Description
Additional Requirements for Mobile Applications Requirement 1: Ensure that the app implements
two or more functionally independent
methods of root detection
• Ensure that app implements two or more functionally independent methods of root detection and responds to the presence of a rooted device either by alerting the user or by terminating the app.
Requirement 2: Ensure tamper
detection is implemented
• Ensure app detects and responds to tampering with executable files and critical data.
Requirement 3: Ensure SSL pinning is
implemented
• Ensure SSL pinning is implemented so that an adversary could not intercept the traffic at application level as well as network level.
Requirement 4: Ensure detection
of widely used reverse
engineering tools
• Ensure that app detects the presence of widely used reverse engineering tools, such as code injection tools, hooking frameworks and debugging servers.
Requirement 5: Ensure detection
of emulator
• Ensure that app detects and responds to being run in an emulator using any method.
Requirement 6: Ensure detection of modification of process memory
• Ensure that app detects and responds to modifications of process memory,
including relocation table patches and injected code.
Requirement 7: Ensure all
executable files and libraries
belonging to the app are verified
• Ensure all executable files and libraries belonging to the app are either
encrypted on the file level and/or ensure that the important code and data
segments inside the executables are encrypted or packed. Trivial static
analysis should not reveal important code or data.
Requirement 8: Ensure code
obfuscation is implemented
• Ensure that code is properly obfuscated and is non-readable.
Additional Requirements for Thick-client Applications Requirement 9: Ensure tamper
• Ensure app detects and responds to tampering with executable files and critical data.
Press ALT + Left Arrow Key to go back
43 | P a g e
detection is implemented
Requirement 10: Ensure all
executable files and libraries
belonging to the app are verified
• Ensure all executable files and libraries belonging to the app are either
encrypted on the file level and/or ensure that the important code and data
segments inside the executables are encrypted or packed. Trivial static
analysis should not reveal important code or data.
Requirement 11: Ensure code
obfuscation is implemented
• Ensure that code is properly obfuscated and is non-readable.
Press ALT + Left Arrow Key to go back
44 | P a g e
4. ANNEXURE: Checklist
4.1 Aadhaar Authentication Application Security Standards – Checklist for Web
Applications
S.No Goals Requirements Compliance (Yes /No) Remarks
1.
Protect Aadhaar holder data
Mask Aadhaar number on input
2. Mask Aadhaar number on display
3. Do not send Aadhaar number in the URL in cleartext
4. Ensure Aadhaar number is not auto populated
5. Encrypt transmission of Aadhaar number across open, public networks
6. Perform Aadhaar number validation checks
7. Provide Virtual ID as an alternative input option
8. Wherever possible capture domain specific identifier or ANCS token or Virtual ID at the front-end
9. Ensure there is no local storage of Aadhaar Number / PID block
10.
Architecture, Design and Threat Modelling
Ensure all third-party components used by the application are verified
11. Ensure that security controls are enforced on both the client side and server side
12. Ensure that the high-level architecture is verified
13. Ensure that the security testing is performed as part of the development lifecycle
14.
Authentication API compliance and Encryption
Refer the latest UIDAI API specifications for implementing API available on UIDAI website
15. Ensure application authentication API is protected using appropriate access control
16. Ensure PID block is encrypted on capture
Press ALT + Left Arrow Key to go back
45 | P a g e
S.No Goals Requirements Compliance (Yes /No) Remarks
17. Ensure use of Registered Devices for capturing biometrics
18. Ensure latest API specifications is in use
19. Implement OTP verification controls in front-end application
20.
Delivery of consent message for Aadhaar authentication within application
Ensure disclosure of information / consent is provided prior to Aadhaar authentication
21. Implement the functionality to change the text of disclosure of information/consent to local language
22. Ensure disclosure of information/consent checkbox is not ticked by default
23. Ensure provision for sharing disclosure of information/ consent message with differently abled persons is in place
24. Ensure disclosure of information/consent is provided separately each time before carrying out authentication
25. Ensure appropriate consent implementation in case Aadhaar authentication is mandatory by law
26. Ensure appropriate consent implementation in case Aadhaar authentication is voluntary by law
27.
Operator Authentication and Session Management
Ensure operator authentication is performed for accessing the application
28. Implement two factor authentication for the operator login
29. Implement Password hygiene controls
30. Ensure ‘Remember Me’ option is disabled, and login credentials are not stored anywhere.
31.
Secure Network Communication
Ensure that data is encrypted on the network using TLS
32. Ensure that the TLS settings are in line with current best practices
33. Ensure that the app verifies the X.509 certificate of the remote endpoint
Press ALT + Left Arrow Key to go back
46 | P a g e
S.No Goals Requirements Compliance (Yes /No) Remarks
34. Ensure that application doesn’t rely only on insecure communication channels (email or SMS) for critical operations
35.
Aadhaar Authentication Logs
Ensure for each Aadhaar authentication request (auth, e-KYC etc.) audit log is generated with all the mandatory fields
36. Ensure logs are stored online for 2 years and archived for 5 years (even if the application has been decommissioned, requirement for log maintenance prevails)
37.
Application Logs
Ensure Aadhaar Application logs are maintained
38. Ensure Application facilitates centralized logging
39.
Application Version Control
Ensure a unique application version number is maintained using a version control system
40. Ensure different nomenclature is used for pre-production and production application version
41. Ensure a Change Management Form is maintained for each application level change
42.
Information Storage and Privacy
Ensure core biometric information is not stored anywhere in the application/system
43. Ensure that e-KYC data is stored in an encrypted manner within the database tables
44. Ensure resident Data (e-KYC and Aadhaar) is not stored on a server connected to the internet
45. Ensure that no sensitive data is written to application logs
46. Ensure that no sensitive data is shared with third parties
47. Ensure that the application does not store any sensitive data in temporary memory
Press ALT + Left Arrow Key to go back
47 | P a g e
S.No Goals Requirements Compliance (Yes /No) Remarks
48.
Application Configuration Management
Ensure the configuration parameters are not hardcoded in the application code
49. Ensure environment variables or DB calls are used to invoke application parameters
50. Ensure license keys are stored in config or properties file
51. Ensure proper mapping between sub-AUAs and their respective sub-AUA code is maintained (if applicable)
52.
Secure Application Development and Management
Ensure that the application is tested for at the minimum OWASP Top 10, SANS Top 25 controls before go-live testing. Result of testing should be documented
53. Ensure OWASP secure coding guidelines are referred to, for code best practices
54. Ensure periodic source code reviews and VAPT assessments are conducted for the application
55. Ensure measures are deployed to prevent tampering of deployed code
56. Ensure applications are developed in a way to prevent common coding vulnerabilities in software development processes
57. Ensure secure development trainings are provided to the developers
58. Ensure an updated application documentation is maintained
59. Cryptography, Key Management and HSM
Ensure HSM is provisioned for Key Management
Press ALT + Left Arrow Key to go back
48 | P a g e
4.2 Aadhaar Authentication Application Security Standards – Checklist for Mobile
Applications
S.No. Goals Requirements
Compliance (Yes /No)
Remarks
1.
Protect Aadhaar holder data
Mask Aadhaar number on input
2. Mask Aadhaar number on display
3. Do not send Aadhaar number in the URL in cleartext
4. Ensure Aadhaar number is not auto populated
5. Encrypt transmission of Aadhaar number across open, public networks
6. Perform Aadhaar number validation checks
7. Provide Virtual ID as an alternative input option
8. Wherever possible capture domain specific identifier or ANCS token or Virtual ID at the front-end
9. Ensure there is no local storage of Aadhaar Number / PID block in Shared preference folder
10.
Architecture, Design and Threat Modelling
Ensure all third-party components used by the application are verified
11. Ensure that security controls are enforced on both the client side and server side
12. Ensure that the high-level architecture is verified
13. Ensure that the security testing is performed as part of the development lifecycle
14. Ensure that connecting clients use the current version of the mobile application
15. Ensure that the remote endpoints are verified
16.
Authentication API compliance and Encryption
Refer the latest UIDAI API specifications for implementing API available on UIDAI website
17. Ensure application authentication API is protected using appropriate access control
18. Ensure PID block is encrypted on capture
19. Ensure use of Registered Devices for capturing biometrics
20. Ensure latest API specifications is in use
Press ALT + Left Arrow Key to go back
49 | P a g e
S.No. Goals Requirements
Compliance (Yes /No)
Remarks
21. Implement OTP verification controls in front-end application
22.
Delivery of consent message for Aadhaar authentication within application
Ensure disclosure of information / consent is provided prior to Aadhaar authentication
23. Implement the functionality to change the text of disclosure of information/consent to local language
24. Ensure disclosure of information/consent checkbox is not ticked by default
25. Ensure provision for sharing disclosure of information/ consent message with differently abled persons is in place
26. Ensure disclosure of information/consent is provided separately each time before carrying out authentication
27. Ensure appropriate consent implementation in case Aadhaar authentication is mandatory by law
28. Ensure appropriate consent implementation in case Aadhaar authentication is voluntary by law
29.
Operator Authentication and Session Management
Ensure operator authentication is performed for accessing the application
30. Implement two factor authentication for the operator login
31. Implement Password hygiene controls
32. Ensure ‘Remember Me’ option is disabled, and login credentials are not stored anywhere.
33. Ensure authentication is performed at the remote endpoint
34. Ensure that the remote endpoint uses randomly generated access tokens to authenticate
35. Ensure that the remote endpoint terminates the existing session when the user logs out.
36. Ensure that the remote endpoint implements an exponential back-off
37. Ensure that biometric authentication, if any, is not event-bound
Press ALT + Left Arrow Key to go back
50 | P a g e
S.No. Goals Requirements
Compliance (Yes /No)
Remarks
38.
Secure Network Communication
Ensure that data is encrypted on the network using TLS
39. Ensure that the TLS settings are in line with current best practices
40. Ensure that the app verifies the X.509 certificate of the remote endpoint
41. Ensure that application doesn’t rely only on insecure communication channels (email or SMS) for critical operations
42. Ensure that the app either uses its own certificate store, or pins the endpoint certificate
43.
Aadhaar Authentication Logs
Ensure for each Aadhaar authentication request (auth, e-KYC etc.) audit log is generated with all the mandatory fields
44. Ensure logs are stored online for 2 years and archived for 5 years (even if the application has been decommissioned, requirement for log maintenance prevails)
45.
Application Logs
Ensure Aadhaar Application logs are maintained
46. Ensure Application facilitates centralized logging
47.
Application Version Control
Ensure a unique application version number is maintained using a version control system
48. Ensure different nomenclature is used for pre-production and production application version
49. Ensure a Change Management Form is maintained for each application level change
50.
Information Storage and Privacy
Ensure core biometric information is not stored anywhere in the application/system
51. Ensure that e-KYC data is stored in an encrypted manner within the database tables
52. Ensure resident Data (e-KYC and Aadhaar) is not stored on a server connected to the internet
53. Ensure that no sensitive data is written to application logs
Press ALT + Left Arrow Key to go back
51 | P a g e
S.No. Goals Requirements
Compliance (Yes /No)
Remarks
54. Ensure that no sensitive data is shared with third parties
55. Ensure that the application does not store any sensitive data in temporary memory
56. Ensure that system credential storage facilities are used appropriately
57. Ensure that the keyboard cache is disabled on text inputs
58. Ensure that the clipboard is deactivated on text fields
59. Ensure that no sensitive data is included in backups.
60. Ensure that the app removes sensitive data from views while running in background
61. Ensure that the app does not hold sensitive data in memory longer than necessary
62. Ensure that the app enforces a minimum device-access-security policy
63.
Application Configuration Management
Ensure the configuration parameters are not hardcoded in the application code
64. Ensure environment variables or DB calls are used to invoke application parameters
65. Ensure license keys are stored in config or properties file
66. Ensure proper mapping between sub-AUAs and their respective sub-AUA code is maintained (if applicable)
67. Ensure that the app is signed and provisioned with valid certificate.
68. Ensure that the app has been built in release mode
69. Ensure that debugging code has been removed
70. Ensure that the error handling logic is verified
71. Secure Application Development
Ensure that the application is tested for at the minimum OWASP Top 10, SANS Top 25 controls before go-live testing. Result of testing should be documented
Press ALT + Left Arrow Key to go back
52 | P a g e
S.No. Goals Requirements
Compliance (Yes /No)
Remarks
72. and Management
Ensure OWASP secure coding guidelines are referred to, for code best practices
73. Ensure periodic source code reviews and VAPT assessments are conducted for the application
74. Ensure measures are deployed to prevent tampering of deployed code
75. Ensure applications are developed in a way to prevent common coding vulnerabilities in software development processes
76. Ensure secure development trainings are provided to the developers
77. Ensure an updated application documentation is maintained
78. Ensure that all inputs from external sources are validated
79. Ensure that the app does not export sensitive functionality via custom URL
80. Ensure that JavaScript is disabled in WebViews unless explicitly required
81. Ensure that the object serialization in API is verified
82.
Cryptography, Key Management and HSM
Ensure HSM is provisioned for Key Management
83. Ensure that the app does not rely on symmetric cryptography with hardcoded keys
84. Ensure that the app doesn't re-use the same cryptographic key for multiple purposes
85. Ensure that the app does not use deprecated cryptographic protocols
86.
Resiliency Against Reverse Engineering Requirements
Ensure that the app implements two or more functionally independent methods of root detection
87. Ensure tamper detection is implemented
88. Ensure SSL pinning is implemented
89. Ensure detection of widely used reverse engineering tools
90. Ensure detection of emulator
Press ALT + Left Arrow Key to go back
53 | P a g e
S.No. Goals Requirements
Compliance (Yes /No)
Remarks
91. Ensure detection of modification of process memory
92. Ensure all executable files and libraries belonging to the app are verified
93. Ensure code obfuscation is implemented
4.3 Aadhaar Authentication Application Security Standards – Checklist for Thick Client
Applications
S.No Goals Requirements
Compliance (Yes /No)
Remarks
1.
Protect Aadhaar holder data
Mask Aadhaar number on input
2. Mask Aadhaar number on display
3. Do not send Aadhaar number in the URL in cleartext
4. Ensure Aadhaar number is not auto populated
5. Encrypt transmission of Aadhaar number across open, public networks
6. Perform Aadhaar number validation checks
7. Provide Virtual ID as an alternative input option
8. Wherever possible capture domain specific identifier or ANCS token or Virtual ID at the front-end
9. Ensure there is no local storage of Aadhaar Number / PID block in system volatile memory
10.
Architecture, Design and Threat Modelling
Ensure all third-party components used by the application are verified
11. Ensure that security controls are enforced on both the client side and server side
12. Ensure that the high-level architecture is verified
13. Ensure that the security testing is performed as part of the development lifecycle
14. Ensure that connecting clients use the current version of the thick client application
15. Ensure thick client application architecture is secure
Press ALT + Left Arrow Key to go back
54 | P a g e
S.No Goals Requirements
Compliance (Yes /No)
Remarks
16.
Authentication API compliance and Encryption
Refer the latest UIDAI API specifications for implementing API available on UIDAI website
17. Ensure application authentication API is protected using appropriate access control
18. Ensure PID block is encrypted on capture
19. Ensure use of Registered Devices for capturing biometrics
20. Ensure latest API specifications is in use
21. Implement OTP verification controls in front-end application
22.
Delivery of consent message for Aadhaar authentication within application
Ensure disclosure of information / consent is provided prior to Aadhaar authentication
23. Implement the functionality to change the text of disclosure of information/consent to local language
24. Ensure disclosure of information/consent checkbox is not ticked by default
25. Ensure provision for sharing disclosure of information/ consent message with differently abled persons is in place
26. Ensure disclosure of information/consent is provided separately each time before carrying out authentication
27. Ensure appropriate consent implementation in case Aadhaar authentication is mandatory by law
28. Ensure appropriate consent implementation in case Aadhaar authentication is voluntary by law
29.
Operator Authentication and Session Management
Ensure operator authentication is performed for accessing the application
30. Implement two factor authentication for the operator login
31. Implement Password hygiene controls
32. Ensure ‘Remember Me’ option is disabled, and login credentials are not stored anywhere.
33. Ensure authentication is performed at the remote endpoint
Press ALT + Left Arrow Key to go back
55 | P a g e
S.No Goals Requirements
Compliance (Yes /No)
Remarks
34. Ensure that the remote endpoint uses randomly generated access tokens to authenticate
35. Ensure that the remote endpoint terminates the existing session when the user logs out.
36. Ensure that the remote endpoint implements an exponential back-off
37. Ensure that biometric authentication, if any, is not event-bound
38.
Secure Network Communication
Ensure that data is encrypted on the network using TLS
39. Ensure that the TLS settings are in line with current best practices
40. Ensure that the app verifies the X.509 certificate of the remote endpoint
41. Ensure that application doesn’t rely only on insecure communication channels (email or SMS) for critical operations
42. Ensure that the app either uses its own certificate store, or pins the endpoint certificate
43.
Aadhaar Authentication Logs
Ensure for each Aadhaar authentication request (auth, e-KYC etc.) audit log is generated with all the mandatory fields
44. Ensure logs are stored online for 2 years and archived for 5 years (even if the application has been decommissioned, requirement for log maintenance prevails)
45.
Application Logs
Ensure Aadhaar Application logs are maintained
46. Ensure Application facilitates centralized logging
47.
Application Version Control
Ensure a unique application version number is maintained using a version control system
48. Ensure different nomenclature is used for pre-production and production application version
49. Ensure a Change Management Form is maintained for each application level change
Press ALT + Left Arrow Key to go back
56 | P a g e
S.No Goals Requirements
Compliance (Yes /No)
Remarks
50.
Information Storage and Privacy
Ensure core biometric information is not stored anywhere in the application/system
51. Ensure that e-KYC data is stored in an encrypted manner within the database tables
52. Ensure resident Data (e-KYC and Aadhaar) is not stored on a server connected to the internet
53. Ensure that no sensitive data is written to application logs
54. Ensure that no sensitive data is shared with third parties
55. Ensure that the application does not store any sensitive data in temporary memory
56. Ensure that system credential storage facilities are used appropriately
57. Ensure that no sensitive data is included in files, registry or computer memory
58. Ensure that the app does not hold sensitive data in memory longer than necessary
59.
Application Configuration Management
Ensure the configuration parameters are not hardcoded in the application code
60. Ensure environment variables or DB calls are used to invoke application parameters
61. Ensure license keys are stored in config or properties file
62. Ensure proper mapping between sub-AUAs and their respective sub-AUA code is maintained (if applicable)
63. Ensure that the app is signed and provisioned with valid certificate.
64. Ensure that the error handling logic is verified
65. Secure Application Development and Management
Ensure that the application is tested for at the minimum OWASP Top 10, SANS Top 25 controls before go-live testing. Result of testing should be documented
66. Ensure OWASP secure coding guidelines are referred to, for code best practices
Press ALT + Left Arrow Key to go back
57 | P a g e
S.No Goals Requirements
Compliance (Yes /No)
Remarks
67. Ensure periodic source code reviews and VAPT assessments are conducted for the application
68. Ensure measures are deployed to prevent tampering of deployed code
69. Ensure applications are developed in a way to prevent common coding vulnerabilities in software development processes
70. Ensure secure development trainings are provided to the developers
71. Ensure an updated application documentation is maintained
72. Ensure a registration process is built into the application to ensure only authorized personnel can install and use the application
73.
Cryptography, Key Management and HSM
Ensure HSM is provisioned for Key Management
74. Ensure that the app does not rely on symmetric cryptography with hardcoded keys
75. Ensure that the app doesn't re-use the same cryptographic key for multiple purposes
76. Ensure that the app does not use deprecated cryptographic protocols
77. Resiliency Against Reverse Engineering Requirements
Ensure tamper detection is implemented
78. Ensure all executable files and libraries belonging to the app are verified
79. Ensure code obfuscation is implemented