⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ 🔑 KEY RULE: Upload your answer in PDF only, raw spoilers will be deleted. PS: Don't forget to add comments in your code. ===== For today's livestream we will be solving this Capture The Flag. This is a Cryptographic Challenge. We'll get into the details of how Symmetric Ciphers work and why it's important for you to learn to become an ethical hacker. HERE'S THE CAPTURE THE FLAG Your more then welcome to attempt solving it before the livestream. ===== Goodluck. ~ aScriptKiddie

⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ 🔑 KEY RULE: Upload your answer in PDF only, raw spoilers will be deleted. PS: Don't forget to add comments in your code. ===== Given a password string, return "weak", "medium", or "strong" based on the strength of the password. A password is evaluated according to the following rules: - It is at least 8 characters long. - It contains both uppercase and lowercase letters. - It contains at least one number. - It contains at least one special character from this set: !, @, #, $, %, ^, &, or *. Return "weak" if the password meets fewer than two of the rules. Return "medium" if the password meets 2 or 3 of the rules. Return "strong" if the password meets all 4 rules. HERE'S YOUR TERMINAL Your code should pass all this tests: 1. check_strength("123456") should return "weak". 2. check_strength("pass!!!") should return "weak". 3. check_strength("Qwerty") should return "weak". 4. check_strength("PASSWORD") should return "weak". 5. check_strength("PASSWORD!") should return "medium". 6. check_strength("PassWord%^!") should return "medium". 7. check_strength("qwerty12345") should return "medium". 8. check_strength("S3cur3P@ssw0rd") should return "strong". 9. check_strength("C0d3&Fun!") should return "strong". ===== Goodluck. ~ aScriptKiddie

⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ 🔑 KEY RULE: Upload your answer in PDF only, raw spoilers will be deleted. PS: Don't forget to add comments in your code. ===== Given a phone number in the format "+A (BBB) CCC-DDDD", where each letter represents a digit as follows: - "A" represents the country code and can be any number of digits. - "BBB" represents the area code and will always be three digits. - "CCC" and "DDDD" represent the local number and will always be three and four digits long, respectively. Determine if it's a spam number based on the following criteria: - The country code is greater than 2 digits long or doesn't begin with a zero (0). - The area code is greater than 900 or less than 200. - The sum of first three digits of the local number appears within last four digits of the local number. - The number has the same digit four or more times in a row (ignoring the formatting characters). HERE'S YOUR TERMINAL Your Code Should Pass The Following Tests: 1. is_spam("+0 (200) 234-0182") should return False. 2. is_spam("+091 (555) 309-1922") should return True. 3. is_spam("+1 (555) 435-4792") should return True. 4. is_spam("+0 (955) 234-4364") should return True. 5. is_spam("+0 (155) 131-6943") should return True. 6. is_spam("+0 (555) 135-0192") should return True. 7. is_spam("+0 (555) 564-1987") should return True. 8. is_spam("+00 (555) 234-0182") should return False. ===== Goodluck. ~ aScriptKiddie

⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ 🔑 KEY RULE: Upload your answer in PDF only, raw spoilers will be deleted. PS: Don't forget to add comments in your code. ===== All operations in RSA involve modular exponentiation. Modular exponentiation is an operation that is used extensively in cryptography and is normally written like: 210mod 17210mod17 You can think of this as raising some number to a certain power (210=1024210=1024), and then taking the remainder of the division by some other number (1024mod 17=41024mod17=4). In Python there's a built-in operator for performing this operation: pow(base, exponent, modulus). In RSA, modular exponentiation, together with the problem of prime factorisation, helps us to build a "trapdoor function". This is a function that is easy to compute in one direction, but hard to do in reverse unless you have the right information. It allows us to encrypt a message, and only the person with the key can perform the inverse operation to decrypt it. To grab the flag, find the solution to 10117mod 2266310117mod22663 HERE'S YOUR TERMINAL (if applicable) ===== Goodluck. ~ aScriptKiddie

⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ ⚠️!!SPOILERS IN COMMENTS!!⚠️ 🔑 KEY RULE: Upload your answer in PDF only, raw spoilers will be deleted. PS: Don't forget to add comments in your code. ===== This is a challenge about JSON Web Tokens. The traditional way to store sessions is with session ID cookies. After you login to a website, a session object is created for you on the backend (the server), and your browser (the client) is given a cookie which identifies that object. As you make requests to the site, your browser automatically sends the session ID cookie to the backend server, which uses that ID to find your session in its own memory and thus authorise you to perform actions. JWTs work differently. After you login, the server sends your web browser the whole session object in a JWT, containing a payload of key-value pairs describing your username, privileges, and other info. Also included is a signature created using the server's secret key, designed to prevent you from tampering with the payload. Your web browser saves the token into local storage. ** View the second image attached below ** On subsequent requests, your browser sends the token to the backend server. The server verifies the signature first, and then reads the token payload to authorise you. 💡To summarise, with session ID cookies, sessions live on the server, but with JWTs, sessions live on the client. The main advantage of JWTs over session ID cookies is that they are easy to scale. Organisations need a way to share sessions across multiple backend servers. When a client switches from using one server or resource to another, that client's session should still work. Furthermore, for large orgs there could be millions of sessions. Since JWTs live on the client, they solve these problems: any backend server can authorise a user just by checking the signature on the token and reading the data inside. Unfortunately there are some downsides to JWTs, as they are often configured in an insecure way, and clients are free to modify them and see if the server will still verify them. We'll look at these exploits in the next challenges. For now, the flag is the name of the HTTP header used by the browser to send JWTs to the server.