docs: replace dead links with archive.org & alternative

cheatsheets/Secrets_Management_Cheat_Sheet.md

@@ -199,7 +199,7 @@ Secrets follow a lifecycle. The stages of the lifecycle are as follows:
 
 New secrets must be securely generated and cryptographically robust enough for their purpose. Secrets must have the minimum privileges assigned to them to enable their required use/role.
 
-You should transmit credentials securely, such that ideally, you don't send the password along with the username when requesting user accounts. Instead, you should send the password via a secure channel (e.g., mutually authenticated connection) or a side-channel such as push notification, SMS, email. Refer to the [Multi-Factor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet) to learn about the pros and cons of each channel.
+You should transmit credentials securely, such that ideally, you don't send the password along with the username when requesting user accounts. Instead, you should send the password via a secure channel (e.g., mutually authenticated connection) or a side-channel such as push notification, SMS, email. Refer to the [Multi-Factor Authentication Cheat Sheet](Multifactor_Authentication_Cheat_Sheet.md) to learn about the pros and cons of each channel.
 
 Applications may not benefit from having multiple communication channels, so you must provision credentials securely.
 

cheatsheets/Transaction_Authorization_Cheat_Sheet.md

@@ -53,15 +53,15 @@ Some applications allow a user to chose how their transactions will be authorize
 Since developers need to prevent users from authorizing fraudulent operations, their applications should not require a user to perform the same actions for authentication and transaction authorization. Consider the following example:
 
 1. An application is using the same method for user authentication and for transaction authorization {i.e. with an OTP token).
-2. Malware could use a man-in-the-middle attack to present a user with a false error message when they submit credentials to the application, which could trick the user into repeating the authentication procedure. The first credential will be used by the malware for authentication and the second credential would be used to authorize a fraudulent transaction. Even challenge-response schemes could be abused using this scenario, since malware can present a challenge taken from a fraudulent transaction and trick the user to provide a response. Such an attack scenario is used widely in [malware attacks against electronic banking](http://securityintelligence.com/back-basics-malware-authors-downgrade-tactics-stay-radar/#.VX_qI_krLDc).
+2. Malware could use a man-in-the-middle attack to present a user with a false error message when they submit credentials to the application, which could trick the user into repeating the authentication procedure. The first credential will be used by the malware for authentication and the second credential would be used to authorize a fraudulent transaction. Even challenge-response schemes could be abused using this scenario, since malware can present a challenge taken from a fraudulent transaction and trick the user to provide a response. Such an attack scenario is used widely in [malware attacks against electronic banking](https://web.archive.org/web/20241210210645/https://securityintelligence.com/back-basics-malware-authors-downgrade-tactics-stay-radar/).
 
 To stop such attacks, developers can make sure that authentication actions are different than transaction authorizations by:
 
 - Using different methods to authenticate and to authorize
 - Employing different actions in an external security component (i.e using a different mode of operation in a CAP reader)
 - Presenting the user with a clear message about what they are "signing" (What You See Is What You Sign Principle)
 
-Social engineering methods [can be used despite authentication and operation authorization methods](http://securityintelligence.com/tatanga-attack-exposes-chiptan-weaknesses/#.VZAy9PkrLDc) but the application shouldn't make it easier for such attack scenarios.
+Social engineering methods [can be used despite authentication and operation authorization methods](https://web.archive.org/web/20250206121430/https://securityintelligence.com/tatanga-attack-exposes-chiptan-weaknesses/) but the application shouldn't make it easier for such attack scenarios.
 
 ### 1.5 Each transaction should be authorized using unique authorization credentials
 

cheatsheets/Transport_Layer_Security_Cheat_Sheet.md

@@ -117,7 +117,7 @@ Additionally, there are a number of offline tools that can be used:
 
 ### Use Strong Keys and Protect Them
 
-The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits when using RSA keys. Additional information on key lifetimes and comparable key strengths can be found [here](http://www.keylength.com/en/compare/) and in [NIST SP 800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf).
+The private key used to generate the cipher key must be sufficiently strong for the anticipated lifetime of the private key and corresponding certificate. The current best practice is to select a key size of at least 2048 bits when using RSA keys. Additional information on key lifetimes and comparable key strengths can be found [here](https://www.keylength.com/en/compare/) and in [NIST SP 800-57](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf).
 
 The private key should also be protected from unauthorized access using filesystem permissions and other technical and administrative controls.