DOCSLIB.ORG

Information Security Guideline | Version 2.1 Confidential

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Information Security Guideline | Version 2.1 Confidential Secure Software Development | Information Security Guideline | Version 2.1 Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 1 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI Communications Security [DG 1-1] Utilize TLS certificates issued by the officially supported certification authority issued for the correct domain scope. Do not utilize self-signed TLS certificates. Ensure components requiring TLS connectivity cease to function if TLS certificates are invalid (expired, X X X revoked, not issued from a trusted authority, not issued for the correct subject, etc.). If possible, implement OCSP stapling to enhance the usability and availability of Online Certificate Status Protocol validation. If possible, implement HTTP Public Key Pinning to resist man-in-the-middle attacks. Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 2 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI [DG 1-2] Ensure login form pages and other pages used to submit sensitive data to or retrieve sensitive data from the server are loaded over strongly encrypted TLS 1.2+ connections. Protocol obfuscation is not X X X a sufficient means of protecting data transmissions. [DG 1-3] Ensure authentication credentials, security tokens, and session identifiers are only sent over strongly encrypted TLS 1.2+ connections. Protocol obfuscation is not a sufficient means of protecting data X X X transmissions. [DG 1-4] Disable HTTP and other clear text communication protocols for access to protected resources. If HTTP is required for initial ease of availability (e.g., for an external customer typing a domain name into a web browser address bar), redirect all HTTP requests to HTTPS and avoid transmitting sensitive X X X information in requests and responses until HTTPS is in use. Encrypt the channel for all communications involving protected resources. [DG 1-5] Send and receive sensitive communications (e.g., Top Secret, Confidential, PCI, PII, HIPAA/HITECH, SOX, proprietary, or otherwise used in decisioning) exclusively over encrypted HTTPS, encrypted IPsec, or equivalently encrypted channels. Use HTTP Strict Transport Security (HSTS) headers to force user agents to connect to domain names X X X only over HTTPS. The “max-age” attribute value should be far in the future (e.g., 7776000, representing 90 days) and should be the same value in every response. Include the “includeSubDomains” attribute. Include the “preload” attribute and submit the domain to browser vendor HSTS preload lists (e.g., https://hstspreload.appspot.com/). [DG 1-6] Use a 2048-bit or larger RSA modulus in certificate generation. X X X [DG 1-7] Issue and use certificates only with the correct trust anchor and chain of trust order. X X X [DG 1-8] Disable client-initiated TLS renegotiation. X X X [DG 1-9] Disable TLS compression. X X X [DG 1-10] During the TLS handshake, select the strongest cipher suite supported by both the client and server. X X X [DG 1-11] TLS connections should use TLS 1.2 or higher. Disable SSL 2.0, SSL 3.0, and TLS 1.0. X X X [DG 1-12] Disable TLS cipher suites utilizing the following components: For key exchange: • Anonymous Diffie Hellman algorithm (no authentication) For bulk encryption: • Camellia algorithm • DES and 3DES algorithms • IDEA algorithm • RC4 algorithm • SEED algorithm • Block sizes under 128 bits X X X • Electronic codebook (ECB) mode For message authentication: • MD5 algorithm • MD2 algorithm If possible, avoid operating bulk encryption algorithms in cipher block chaining (CBC) mode. If possible, support the following components: • Key exchange algorithms that support forward secrecy, including Diffie Hellman and Elliptic Curve Diffie Hellman. Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 3 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI • Authenticated encryption with associated data (AEAD), including AES-GCM and ChaCha20- Poly1305. [DG 1-13] For protected resources, ensure that active content (e.g., scripts, CSS, embedded controls, and XMLHttpRequest requests) is embedded and loaded with HTTPS URIs to avoid man-in-the-middle attacks and browser blocking of “mixed content.” Consider loading passive content (e.g., images and HTML5 video) over HTTPS to avoid man-in-the-middle attacks and browser warnings. Where third party APIs do not support encrypted channels, perform pre-load data validation to ensure X X X malicious content cannot be executed unwittingly or through social engineering. Refer to the W3C Mixed Content specification and individual browser vendors to determine what content types are “blockable” and “optionally-blockable.” [DG 1-14] Use a cryptographically strong signature algorithm in certificate generation. Do not use MD5 or SHA-1. X X X Privacy [DG 2-1] Do not pass sensitive parameters, including PCI data, GLBA data, HIPAA/HITECH data, SOX data, PII data, transactional data, security tokens, session identifiers, or passwords within the URL request path. When parameters must be logged, utilize the application server platform’s supported logging X X X mechanism in a secure manner (see DG 9-6). [DG 2-2] Apply the following anti-caching HTTP headers to pages containing identifiers (e.g., username, email address, and account number), form input fields for identifiers (e.g., input fields on login, registration, forgotten password request, forgotten username request, forgotten associated email request, and username change workflows) and other sensitive form fields: X X X Cache-Control: no-cache, no-store Expires: 0 [DG 2-3] Apply the following anti-caching HTTP headers to pages containing sensitive information: Cache-Control: no-cache, no-store Expires: 0 X X X Ensure end user agents observe anti-caching headers. [DG 2-4] Never return passwords to clients, including for forgotten password requests, and limit returning other unnecessary sensitive information (visible or otherwise). X X X [DG 2-5] Never permit passwords to be displayed (e.g., in form fields). X X X [DG 2-6] Set the TYPE attribute to PASSWORD for HTML password fields. X X [DG 2-7] Do not cache passwords. X X X [DG 2-8] Set the AUTOCOMPLETE attribute to OFF for HTML password fields, credit card numbers, and other sensitive form fields. X X [DG 2-9] Ensure files persisted to disk during application usage are only accessible with appropriate permissions by authorized users. X X X [DG 2-10] Do not unnecessarily persist files (especially those containing sensitive data elements) to disk. X X X [DG 2-11] Delete data files containing sensitive information after use. Securely overwrite data files containing sensitive information with a cryptographically random data sequence prior to deletion. X X X [DG 2-12] Scrub sensitive data from memory (e.g., sensitive variables) as soon as possible after use. X X X [DG 2-13] Protect temporary files. Only write temporary files to the runtime-specific temporary directory, and ensure the filenames of temporary files are generated randomly. X X X [DG 2-14] Clear payment card information stored for non-recurring payments (i.e., payment for web purchases) upon successful completion of a password change initiated using an out-of-band activation X X code sent in response to a forgotten password request. Password/PIN Length and Complexity Confidential – For Internal Use Only Publish Date: 05/18/2017 Page 4 of 27 Secure Software Development | Information Security Guideline | Version 2.1 Requirement WA WS GUI [DG 3-1] Permit one password change per user per day. X X X [DG 3-2] Do not permit the ability to change the password to the most recent value. X X X [DG 3-3] For employees, do not permit reuse of the previous six (6) passwords. For elevated access such as administrator or service accounts, do not permit reuse of the previous twenty (20) passwords. For X X X customers, do not permit reuse of the previous password. [DG 3-4] Require passwords to have a minimum length of eight (8) characters for employees, sixteen (16) characters for elevated access such as administrator or service accounts, or six (6) characters for X X X customers. If possible, permit passwords to have a length of up to 64 or more characters. [DG 3-5] Permit passwords to contain uppercase letters, lowercase letters, digits, and special characters including but not limited to ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } and ~. X X X Treat uppercase and lowercase versions of the same letter as distinct characters. [DG 3-6] For employees or for elevated access such as administrator or service accounts, do not permit the following types of passwords: • Passwords including the user’s username in any combination of casing. For example, the user “jdoe” would not be permitted to have a password of “3jDOE4”. • Passwords based on simple constructions of identifying information entered during registration sequences. For example, John Doe, born February 19, 1991, with a phone number of 555-777- 7777, and username of “mr_doe”, would not be permitted to have a password of “johndoe”, “2/19/91”, or “5557777777”. • Passwords listed in various top 1,000; 500; 200; and 100 most common passwords lists. For example, no user would be permitted to have a password of “mountain”. • Passwords based on dictionary words (in any language). X X X • Passwords matching known weak password patterns. For example, no user would be permitted to have a password containing only repeated characters (e.g., “1111111”, “YYYYYYYYYY”, “;;;;;;;;;;;;;;;;;;;”) or obvious sequences (e.g., “98765432”, “asdfghjk”, “ASDFASDF”, “HIJKLMNOP”, “!@#$%^&*”).Passwords matching a component of the application’s domain (or, for servers without a domain name, the server name). For example, no user would be permitted to have a password of “screenshots” or “thisisareallyfunwebsite” if the domain name of hosted content was screenshots.thisisareallyfunwebsite.com.
Load more

Recommended publications
  • Security Token Service Application Pool
    Security Token Service Application Pool Unshipped and snobby Paolo never totalize his hurtfulness! Sorediate Wright retted his pandemonium postures sizzlingly. Inimitable Charlie emit: he rivetting his unfortunates costively and bareheaded. When joined to an AD domain it supports Windows Integrated Authentication. Otherwise, BDLC is unable to find and access the given secure store application. READ rights on all the web applications, the SP_Search will now run the Windows Service. Stops sharing the specified service application outside the farm. From here you need to bind that farm to whichever host you choose. Add the following to the web. In the Internet Information Services management console, in the Connections pane, expand the tree view, and then click Application Pools. Rename your object or delete the existing object. When the user hits the site, a central server will be contacted. The Security Token Service is no. Completely deletes an existing site collection and all subsites. But i am now not able to login to the site using windows authentication. Error: The Security Token Service is not available. Platform for creating functions that respond to cloud events. Restores one or more items from a backup. Checks and repairs the specified site collection and its contents. How can we make this translation better? Adds an endpoint to the Apps denied endpoint list. Sets a new credential mapping for a Secure Store Service application. Deletes a Secure Store application. Unless, there is a need due to business rules or performance constraint, these services may share single application pool in IIS. Can you copy the exact error code and I will be able to better help you! At what point in the install do I use the service account script? What do i need to do to resolve this? Three Service Instances are by default set up to run under the Local System or Local Service accounts: Claims to Windows Token Service, Document Conversions Launcher Service, and Document Conversions Load Balancer Service.
    [Show full text]
  • Step 4 How to Install Security Token to PC/Laptop & Change Token
    Classification : PUBLIC Step 4 How to Install Security Token to PC/Laptop & Change Token PIN How to Install Security Token to PC/Laptop 1. Plug the Security Token to PC/Laptop and copy the Trust_Key Software from Security Token. 2. Extract the content & install software Double Click on Trust Key Application Install the Trust Key Authentication ClientDouble click Classification : PUBLIC Click Install (Then it will install the driver) Click Finish Click the Trust key icon desktop. The display will look like this before plugging in the token. Classification : PUBLIC Plug in token After plugging in the token, display will look like this. Classification : PUBLIC Click user certificate Click View Classification : PUBLIC Click view to appear the certificate details. Click *Start*. Type *Run* and select it. Classification : PUBLIC Type *certmgr.msc* and click *OK* Certificate of current user appears Classification : PUBLIC Click *Personal* Click *Certificates* Classification : PUBLIC The Certificate will be displayed as User Certificate Installing SafeNet Authentication Client on Mac To install with the installer: 1. Double click the SafeNetAuthenticationClient.10.2.x.x.dmg file 2. To start the installation, double click SafeNet Authentication Client 10.2.pkg Classification : PUBLIC 3. Click Continue The Welcome to the SafeNet Authentication Client Installer window opens 4. Click Continue The Software License Agreement window opens 5. Click Agree to accept the software license agreement Classification : PUBLIC 6. Click Install The Standard Install window opens 7. Enter Username and Password and click Install Software NOTE: Administrator permissions are required to install SafeNet Authentication Client 8. Click Close and then perform a Restart (recommended) Classification : PUBLIC How to Change Security Token PIN The security token contains your Private Key, therefore neither the security token nor the token PIN should be shared with anyone under any circumstances.
    [Show full text]
  • Security Target
    Acronis SCS Acronis Cyber Backup 12.5 SCS Hardened Edition Server v12.5 Security Target Document Version: 0.14 Prepared for: Prepared by: Acronis SCS Corsec Security, Inc. 6370 E. Thomas Road, Suite 250 13921 Park Center Road, Suite 460 Scottsdale, AZ 85251 Herndon, VA 20171 United States of America United States of America Phone: +1 781 782 9000 Phone: +1 703 267 6050 www.acronisscs.com www.corsec.com Security Target, Version 0.14 August 19, 2020 Table of Contents 1. Introduction .......................................................................................................................................................4 1.1 Purpose .....................................................................................................................................................4 1.2 Security Target and TOE References .........................................................................................................4 1.3 Product Overview ......................................................................................................................................5 1.3.1 Product Components........................................................................................................................5 1.4 TOE Overview ............................................................................................................................................6 1.4.1 TOE Environment..............................................................................................................................7 1.5
    [Show full text]
  • Multi-Factor Authentication Version: 1.0 Date: February 2017 Author: PCI Security Standards Council
    INFORMATION SUPPLEMENT Multi-Factor Authentication Version: 1.0 Date: February 2017 Author: PCI Security Standards Council INFORMATION SUPPLEMENT Guidance for Multi-Factor Authentication Table of Contents Overview ....................................................................................................................................................................1 MFA and PCI DSS .................................................................................................................................................1 Terminology ............................................................................................................................................................1 Authentication Factors ............................................................................................................................................2 Independence of Authentication Mechanisms ......................................................................................................2 Out-of-Band Authentication .....................................................................................................................................3 Cryptographic Tokens .............................................................................................................................................3 Protection of Authentication Factors .....................................................................................................................5 Multi-step vs. Multi-Factor .......................................................................................................................................5
    [Show full text]
  • Security Token Service for SAP Single Sign-On and SAP Identity Management Document Version: 1.1 – 2018-07-31
    IMPLEMENTATION GUIDE | PUBLIC Security Token Service for SAP Single Sign-On and SAP Identity Management Document Version: 1.1 – 2018-07-31 Security Token Service for SAP Single Sign-On and SAP Identity Management company. All rights reserved. All rights company. affiliate THE BEST RUN 2018 SAP SE or an SAP SE or an SAP SAP 2018 © Content 1 Security Token Service for SAP Single Sign-On and SAP Identity Management.............3 1.1 What is a Security Token Service..................................................3 STS in Business-to-Business Scenarios...........................................4 1.2 Before Starting...............................................................6 System Requirements.......................................................6 Authorizations............................................................ 6 Limitations of the Security Token Service..........................................7 Keys and Keystores.........................................................8 1.3 Adding a Security Token Service to Your Network.......................................9 Downloading and Installing the Federation Software..................................9 Configuring the Security Token Service.......................................... 10 Enabling the Security Token Service.............................................12 Selecting Authentication Types for Web Services....................................12 Configuring Issued Security Tokens.............................................14 Trusting Application Service Providers...........................................16
    [Show full text]
  • Security, Encryption, and Certificates FAQ
    Security, Encryption, and Certificates FAQ Overview In Security Center 5.4, several new capabilities will be added that further strengthen the security of the platform itself, as well as the privacy of data. The aim is to prevent unauthorized access to stored and transmitted messages and data, as well as prevent attacks through the use of stronger encryption and authentication mechanisms. With growing demand for privacy, new capabilities in Security Center 5.4 will strengthen Genetec’s position and overall value proposition. This FAQ addresses some of the most common questions in relation to the new capabilities of Security Center: Encryption, Authentication, and Digital Certificates. These concepts are first described in generic terms; the FAQ then outlines how these new measures are used within Security Center 5.4. Encryption vs. Authentication vs. Authorization What is the difference between encryption, authentication, and authorization? Encryption is used to encrypt data so that only authorized users can see it. Authentication determines whether an entity is who they claim to be, eg. in the case of an individual, it is usually based on a username/password combination. Authentication does not actually say anything about what someone is authorized to do or has the right to do. o Client-side authentication uses username/password combinations, tokens (dual authentication), and other techniques. o Server-side authentication uses certificates to identify trusted third parties. Authorization is the function of specifying the rights, eg. defining the access rights someone has over a set of recourses such as a private data, computing resources, or an application. When users log into a Security Center system, what they are allowed or authorized to do depends on the set of privileges assigned to them by administrators.
    [Show full text]
  • The First Line of Defense in Security Is the Management of User Ids and Passwords
    User Credential Management The first line of defense in security is the management of user IDs and passwords RouteOne eBook User Credential Management - page 1 User IDs When establishing new user IDs verify that the access (permissions) granted is only what is needed for a user to perform their job. This is referred to as ‘least privilege.’ Often users are granted more access than necessary to perform their responsibilities. A single dealer employee (preferably the Dealer Security Manager) should be given the responsibility to administrator user accounts (IDs and passwords); a second individual should be given responsibility of the backup administrator. Passwords Rules Users that have been terminated by the dealership must have Do not share your passwords. Always make new passwords their access to dealership systems terminated immediately. difficult to guess by mixing letters, numbers, characters and Regardless of whether the user is voluntarily or involuntarily punctuation. The greater the mix, the more difficult the password terminated, their access to dealership systems should be will be to guess. terminated no later than the close-of-business on their last Additional Password Rules: day of employment with the dealership. A user ID that is not deactivated or terminated could be used by the former o Avoid using dictionary words employee or, if known, current employees for malicious o Change your password often activity. o Don’t share them with anyone o The longer, the better o Make it a phrase o Don’t leave them lying around RouteOne eBook User Credential Management - page 2 Multi Factor Authentication RouteOne has implemented Multi-Factor Authentication to further enhance the security of the RouteOne system.
    [Show full text]
  • Cointelegraph Security Token Report
    The Security Token Report 2021 Research Partners We thank our research partners for their support of this report. Authors Demelza Hays, Ph.D. Demelza Hays is the director of research at Cointelegraph, and formerly was a Forbes 30 Under 30, U.S. Department of State Fulbright Scholar, and fund manager of two regulated crypto funds. Katharina Gehra Katharina Gehra is the CEO & Co-Founder of Immutable Insight GmbH and the fund manager of the first German crypto hedge fund, a 3-times Capital Top 40 under 40 and a supervisory board member at Fürstlich Castell’sche Bank. She is the co-host of the blockchain pod- cast Block52. Silvan Thoma and Martin Liebi Silvan Thoma ([email protected]) / Martin Liebi ([email protected]) both PwC Legal, Switzerland advise and have advised multiple digital assets operators in the legal aspects of the issuance of digital assets and the set-up and licensing process of the operation of mul- tilateral trading facilities. Urszula McCormack Partner, Cross-Border Finance and Technology, King & Wood Mallesons. Urszula McCormack is one of Asia’s leading regulatory and digital economy lawyers, with a focus on emerging technologies. Urszula advises global banks, payment institutions, large technology com- panies, virtual asset issuers and innovators on new products, compliance and financial services licensing. She also advises on privacy regulation, digital transformation and algorith- mic design. Urszula is a member of multiple advisory bodies and is regularly invited to brief governments, regulators and transnational policymakers. Urszula is admitted to practice law in Hong Kong, Australia and England & Wales. © Crypto Research Report, © Cointelegraph Research, Security Token Report, 2021 3 Rika Khurdayan and Lee Schneider Rika Khurdayan is a lawyer and strategist, with a particular focus on blockchain and DLT.
    [Show full text]
  • Is Payment Tokenization Ready for Primetime?
    Is Payment Tokenization Ready for Primetime? Perspectives from Industry Stakeholders on the Tokenization Landscape Marianne Crowe and Susan Pandy, Federal Reserve Bank of Boston David Lott, Federal Reserve Bank of Atlanta Steve Mott, BetterBuyDesign June 11, 2015 Marianne Crowe is Vice President and Susan Pandy is Director in the Payments Strategies Group at the Federal Reserve Bank of Boston. David Lott is a Payments Risk Expert in the Retail Payments Risk Forum at the Federal Reserve Bank of Atlanta. Steve Mott is the Principal of BetterBuyDesign. The views expressed in this paper are solely those of the authors and do not reflect official positions of the Federal Reserve Banks of Atlanta or Boston or the Federal Reserve System. Mention or display of a trademark, proprietary product or firm in this report does not constitute an endorsement or criticism by the Federal Reserve Bank of Boston or the Federal Reserve System and does not imply approval to the exclusion of other suitable products or firms. The authors would like to thank members of the MPIW and other industry stakeholders for their engagement and contributions to this report. Table of Contents I. Executive Summary ................................................................................................................. 3 II. Introduction .............................................................................................................................. 4 III. Overview of Tokenization ......................................................................................................
    [Show full text]
  • Microsoft Windows Common Criteria Evaluation Security Target
    Microsoft Common Criteria Security Target Microsoft Windows Common Criteria Evaluation Microsoft Windows 10 version 1809 (October 2018 Update) Microsoft Windows Server 2019 (October 2018 Update) Security Target Document Information Version Number 0.05 Updated On June 18, 2019 Microsoft © 2019 Page 1 of 126 Microsoft Common Criteria Security Target Version History Version Date Summary of changes 0.01 June 27, 2018 Initial draft 0.02 December 21, 2018 Updates from security target evaluation 0.03 February 21, 2019 Updates from evaluation 0.04 May 6, 2019 Updates from GPOS PP v4.2.1 0.05 June 18, 2019 Public version Microsoft © 2019 Page 2 of 126 Microsoft Common Criteria Security Target This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. This work is licensed under the Creative Commons Attribution-NoDerivs- NonCommercial License (which allows redistribution of the work). To view a copy of this license, visit http://creativecommons.org/licenses/by-nd-nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA.
    [Show full text]
  • Microsoft Windows Vista and Windows Server 2008 EAL1 Security Target
    Microsoft Windows Vista and Windows Server 2008 EAL1 Security Target Version 1.0 August 14, 2008 Prepared For: Microsoft Corporation Corporate Headquarters One Microsoft Way Redmond, WA 98052-6399 Prepared By: Science Applications International Corporation Common Criteria Testing Laboratory 7125 Gateway Drive Columbia, MD 21046-2554 Version 1.0, 8/14/2008 This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein. The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, AS TO THE INFORMATION IN THIS DOCUMENT. Complying with all applicable copyright laws is the responsibility of the user. This work is licensed under the Creative Commons Attribution-NoDerivs-NonCommercial License (which allows redistribution of the work). To view a copy of this license, visit http://creativecommons.org/licenses/by-nd- nc/1.0/ or send a letter to Creative Commons, 559 Nathan Abbott Way, Stanford, California 94305, USA. Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
    [Show full text]
  • Security and Trust in Open Source Security Tokens
    IACR Transactions ISSN XXXX-XXXX, Vol. 0, No. 0, pp. 1–26. DOI:XXXXXXXX Security and Trust in Open Source Security Tokens Marc Schink, Alexander Wagner, Florian Unterstein and Johann Heyszl Fraunhofer Institute for Applied and Integrated Security (AISEC), Germany, [email protected] Abstract. Using passwords for authentication has been proven vulnerable in countless security incidents. Hardware security tokens effectively prevent most password-related security issues and improve security indisputably. However, we would like to highlight that there are new threats from attackers with physical access which need to be discussed. Supply chain adversaries may manipulate devices on a large scale and install backdoors before they even reach end users. In evil maid scenarios, specific devices may even be attacked while already in use. Hence, we thoroughly investigate the security and trustworthiness of seven commercially available open source security tokens, including devices from the two market leaders: SoloKeys and Nitrokey. Unfortunately, we identify and practically verify significant vulnerabilities in all seven examined tokens. Some of them are based on severe, previously undiscovered, vulnerabilities of two major microcontrollers which are used at a large scale in various products. Our findings clearly emphasize the significant threat from supply chain and evil maid scenarios since the attacks are practical and only require moderate attacker efforts. Fortunately, we are able to describe software-based countermeasures as effective improvements to retrofit the examined devices. To improve the security and trustworthiness of future security tokens, we also derive important general design recommendations. Keywords: security token · second factor authentication · FIDO · fault injection attack · side-channel attack · firmware protection 1 Introduction Passwords are the most common authentication mechanism for private as well as profes- sional IT services such as social media, banking or enterprise infrastructure.
    [Show full text]