This lesson's interactive features are locked, please to keep using them
Verifying Solutions
Let's circle back to this idea of "slow to solve, fast to verify".
Even when we aren't specifically talking about P and NP, the concept of "slow to solve, fast to verify" is very important in real-world software. As a trivial example, imagine the password on an email account. When a user inputs a password like:
p@ssword4Mi
It's easy to verify if that password matches the one we have saved on file. It's literally as easy as:
should_grant_access = user_input == saved_password
The useful bit is that it takes much longer to guess the correct password.
This password example demonstrates the guess/verify concept well, but when it comes to storing passwords in plain text this example is very insecure. We'll cover how to handle passwords in a production system in a future course.
Assignment
The LockedIn influencers are worried about account security. We've assured them that their passwords are secure enough, but they want data. Assuming a brute-force guessing strategy on the part of an attacker, we want to know the maximum number of passwords they would have to try.
Complete the get_num_guesses function. It takes a password length as input and returns the number of all possible passwords of that length and shorter. Only the 26 lowercase English letters can be used in these passwords for the sake of simplicity.
For example, here's the math for calculating the total number of possible passwords for a password length of up to 3:
26 + 26^2 + 26^3 = 18278
More examples:
| Password Length | Num of Possibilities |
|---|---|
| 1 | 26 |
| 2 | 702 |
| 3 | 18278 |