Original subtitles

[MUSIC PLAYING]

SPEAKER: All right.This is SC50.

And this is First Year Family Weekends here at Harvard,

so welcome to all of the moms and dads, brothers, sisters, cousins, aunts,

uncles, grandparents, and beyond.

CS50 here is Harvard University's introduction

to the intellectual enterprises of computer science

and the arts of programming.

And what that means is that what we've been doing in here,

over the past several weeks, is introducing students

to computational thinking, the process of cleaning up one's thoughts

and expressing oneself all the more correctly, all the more

precisely, and ultimately translating those thoughts,

of course, to a computer in the form of programming, which

is where we've spent quite a bit of time-- programming,

writing code-- over the past several weeks.

But toward that end, we've also been equipping students

with some basic building blocks.

You might already know, if a parent, that computers only somehow speak

zeros and ones, even if you're not necessarily a computer person yourself

or know what that means.

But with those zeros and ones can we represent numbers and letters

and colors and videos and more.

And in fact, your child perhaps sitting next to you

could perhaps tell you what today's message says.

Here, we have 64 light bulbs on stage.

And if you look at eight of them at a time,

there's a pattern of bulbs that are either on or off

that, if you know the code so to speak, can you actually convert these bits--

these zeros and ones in light bulb form--

to today's particular message.

Now, before we begin, we thought we'd make this

as engaging, as interactive as possible.

Rather than focus on any assumptions of prior computing knowledge,

you need know nothing today other than how

to operate, for instance, your own phone or a laptop or desktop or the like.

And indeed, we'll assume a general audience.

And in this Halloween week, will we also see

if we can't scare you a little bit into practicing better practices when

it comes specifically to the security or cybersecurity of the device

you carry with you every day in your pocket, use on your desk,

on your laptop, or beyond.

So if you haven't already, whether you're here

in person or tuning in online, go to this URL

here, which will lead you to an interactive polling tool.

Any phone or laptop or desktop suffices.

If it's a little easier than typing in this URL,

you can just scan this code with your phone's camera.

Take a moment to just open your camera.

And hopefully, if you're at a good enough angle

and we've made this thing big enough, this

is a two-dimensional bar code or QR code embedded

in which is that exact same URL.

We're increasingly seeing this throughout the world as a mechanism

for doing what many of you are doing right now, linking

the physical world to the virtual.

But that URL, again, is simply this one here.

And in a moment, you'll see on your screen.

It's OK if you weren't quite able to get that working.

Feel free to glance to the left or to the right of you

for someone else who did.

Let me go ahead and full-screen a question just

to ask of everyone here as we focus today on cybersecurity.

Is your phone secure?

Whether an Android phone, an iPhone, or anything else,

if you're holding it in your hand right now here in person or online,

you should see three possible answers-- yes or no or unsure.

We've got over 300 responses come in already.

In a moment, I'll flip over and reveal the results

and see if we can't see how much work we have to do together here today.

A few more seconds.

Almost up to 400 answers.

Almost up to 400.

It's OK if those keep coming in.

I'm going to toggle back and show the results in just a moment here.

And the results are now in.

According to a response rate of over 400, it looks like 36% of you

don't need what we're about to do here today, which is great.

We'll see if we can't poke some holes though and maybe some assumptions you

all are making.

31%, 32% maybe of you are saying no, your phone

is not secure, so so glad you came.

And then understandably, to another third of you are unsure.

So in very good company today, and we'll see

if we can't open the eyes of everyone in each of these disparate audiences.

Well, let's consider first for a moment exactly how we

might think about the security of our phones, representative

of just any computing device.

And in fact, everything we discuss today could be extrapolated

to laptops and desktops and servers.

But all of us being so familiar with phones,

let's start with phones themselves.

Now, odds are you have on your phone, like so many

other things in your life, a password or a passcode.

And in fact, without raising your hands and, therefore, leaking information,

think to yourself, well, what is my password or passcode?

It's probably four digits.

It's maybe four letters.

Maybe it's even longer.

Maybe it's even nothing.

And I think maybe, from the chart earlier,

we can assume that we have a third of each of those possible responses.

So a password of course, is this super common mechanism

that you and I are all using all the time to keep our devices secure.

But do passwords keep things secure?

Like how many of you, thinking about your phone right

now and that specific password, might think it's secure?

And if so, why do you think it's secure?

We have at least 33% of you are ready to say that your password's secure.

Don't want to know it.

But why might it be, in your mind, secure?

Why might you think it's secure?

Or more generally, what makes your password secure?

AUDIENCE: Random.

SPEAKER: It's random.

OK.

So it's random.

So random letters and numbers and the like.

And that's great, because it's not just a word in the dictionary

that someone could guess and type in.

Downside, of course, I daresay is that it

might take you as well as anyone else quite a bit of time

to guess or figure out what or just to remember

what it is, if it was indeed random.

But randomness is going to be a primitive that really actually helps

us.

Unfortunately, you and I and really the whole world

are not very good even at passwords, as omnipresent

as they are as a defense against adversaries.

In fact, if we look at the most common passwords from the past year, in 2020,

I thought we'd share with you some of those results.

This is the result of security researchers having

found big exploited, compromised databases, analyzing them

for what passwords are in them and then inferring

from that what the most common passwords you and I are all using.

Unfortunately, in 2020, the most common password, according to one measure,

was one, two, three, four, five, six.

[LAUGHING]

Now, funny, yes.

But if you're seeing your password on the screen already,

not so funny perhaps.

[LAUGHING]

The number two password was not much better.

Number three, picture one presumably for a device,

a website that requires that it not just be a word,

it have at least one number, which this person took--

these hundreds of thousands of people took literally.

Password was number four this past year.

1, 2, 3, 4, 5, 6, 7, 8.

1, 1, 1, 1, 1, 1, really not trying hard there.

1, 2, 3, 1, 2, 3, varying it a little bit.

1, 2, 3, 4, 5, was number eight.

1, 2, 3, 4, 5, 6, 7, 8, 9, 0 was number nine.

And then number 10, in 2020, was "senha," which--

any Portuguese speakers here-- means?

AUDIENCE: Password.

AUDIENCE: Password.

SPEAKER: Password.

Means "password."

[LAUGHING]

So made the list twice in this case.

So one take away already today should be, if your password's on this list,

like probably you're in one of those other 33%

whereby we can do better than this.

Why?

I mean, really the obvious.

If you're in this list, there's so many bad guys,

so to speak, out there that are going to try guessing your password first.

Why?

Because just statistically, if they try 1, 2, 3, 4, 5, 6, 1, 2, 3, 4, 5, 6, 7,

8, 9, they're just going to get into a lot of devices

quickly, because they're just so commonly used, those passwords.

You don't want to be on this list.

Ideally, you want to be random, but we want to somehow balance randomness

with memorability so that you don't actually

keep forgetting your password, which, of course, defeats

the whole point of these things in the first place.

But in a class like this, CS50 and computer science more generally,

let's be a little more thoughtful as to what we mean by a device being secure.

Like what does it mean to be secure?

And can we even slap some numbers on it so that we can make measurements,

so that we can ideally compare and contrast

one system versus another, one password versus another

so it's not just our instincts arguing that my password is better than these,

but how can you quantify that perhaps?

Well, let's start simply.

A lot of Android phones and iPhones these days

require minimally that you have a four-digit passcode.

You're minimally encouraged to have at least this bar

set so that you're not having no passcode altogether.

So if you do have a four-digit passcode, well,

let me go ahead and ask this question.

How much time might it take to go about cracking, so to speak-- that is,

figuring out--

what a four-digit passcode is?

In fact, let me go ahead.

If you want to pull up your devices again, you should see on the screen

this question now.

How long might it take to crack--

that is, figure out, guess--

a four-digit passcode?

For instance, on someone's phone.

A few seconds, a few minutes, a few hours, a few days?

Thinking here, from the adversarial perspective,

if someone got ahold of your phone somehow,

how long do they need to get into your phone if it has a four-digit passcode?

A few seconds, few minutes, few hours, few days?

Got about 300 responses so far.

Let's give folks another few seconds here.

Another few seconds here.

All right.

Up to 350 or so.

In a moment, let me go ahead and flip screens over to the results.

So we'll see the preliminary results here.

And if I now pull this screen up, we see that 50% of you

claim that it's going to take only a few seconds.

Few of you say, about a third, fewer of you

are saying that it takes a few minutes, few hours, and even a few days.

Well, let's answer that first.

Because honestly, if it's already a few days or even longer,

our work is here probably already pretty done.

Unfortunately, the problem with things like four-digit passcodes

is that anyone who grabs your phone-- you step out of the room,

you leave it behind, you lose it-- they could certainly mimic your input device

and just use their finger pretending to be you, trying 0, 0, 0, 0.

Nope.

0, 0, 0, 1.

Nope.

0, 0, 0, 2.

Nope.

And it's a little slow, to be fair.

It would take me a while to count all the way up to 9,999.

That's 10,000 total possibilities there.

But let's go ahead and consider exactly how else you could do it.

For instance, here is an example of, in computer science,

what we call a "brute force attack."

And just an adversary using their finger is a brute force attack

if they're trying all possible passcodes.

The problem is, even if your passcode is way at the end of the list of numbers,

eventually they're going to get it by brute force.

Sort of like in yesteryear, using a battering ram or the like to brute

force your way into a building, a castle, or the like.

In software sense, it just means trying all possibilities.

And you don't even have to just use your finger.

Right?

Anyone with some programming savvy, who's good with hardware,

could maybe do something like this.

Here's a quick video I'll hit play on.

No sound.

But a little bit of a robot that has an Android phone underneath it,

and it's got a little robotic finger that's doing the work for you.

You can step out of the room now as the adversary.

Let the robot do its work trying 0, 0, 0, 0 through 9, 9, 9, 9.

And ultimately, presumably get into that phone.

So let's see if we can't quantify then exactly how fast the human or the robot

could get in.

Well, how many total possibilities are there?

That's the right way to begin thinking about it.

If you have 10 digits for the first one, 0 through 9,

and then another 10 possibilities, another 10, another 10,

the total number of possibilities, of course, between 0, 0, 0, 0 and 9, 9, 9,

9 is 10,000--

10 times 10 times 10 times 10--

which gives us that much of a search space, a universe of possible

passcodes to choose among.

Unfortunately, you can do even better than your own finger

or even that robot.

Anyone in CS50 now who knows a bit of programming and languages called "C"

or "Python" or anything else could open up a programming window and actually

just start writing some code.

And so let me do that.

What you're seeing here, if a family member,

is a programming environment called "Visual Studio Code"

that students have been using for the past several weeks.

Up here, we have a tabbed window where we can type our code.

Down here, we have what's called a "terminal

window" where I can type commands to make the computer run that code.

And then over here is just a menu bar.

So crack.py means I'm going to write a program to crack--

that is, figure out passwords-- using this language called "Python."

And even though most CS50 students wouldn't

know what code to start writing, they'd have

to look up some of what I'm about to do, it's only going to be a few lines.

So I'm going to go up here and say from string import digits.

This is a fancy way of saying, hey, Python.

Give me access to all decimal digits.

It just avoids my having to type out 0 through 9 manually.

All right.

Then I'm going to say from either tools import product.

This is another feature of Python that CS50 students, for the most part,

have not yet seen that just says, hey, Python.

Give me the ability to do like the cross product of a whole bunch of numbers.

So these 10 times these 10 times these 10 times these 10.

And then what am I going to do with that?

Well, for each possible passcode in the product of those digits repeated

four times, I'm going to go ahead and, for now, let's just

print out what the passcode is.

In other words, assume that I am now the adversary.

I don't want to waste time using my finger.

I don't have a robot that I made, but I am good at writing software.

And heck, I've got like a USB or a lightning cable in my bag

that I could connect your phone to my Mac or PC.

And I could just have my code that I'm writing now

send all the possible codes from laptop to phone

to automate this process just using the little port at the bottom of all

of our phones.

Well, let me go ahead and maximize this so-called terminal

window, which is, again, where I'm going to run this code.

And again, the question a moment ago was, does it

take seconds, minutes, hours, days?

Well, let me go ahead and run Python of crack.py.

I'm pretending, for the moment, that I did grab that cable from my bag

and plug it into the phone.

Hitting Enter and it didn't actually do anything.

That was not supposed to happen.

[LAUGHING]

So in CS50, we spent a lot of time introducing students to bugs,

which are mistakes in programs.

Sometimes, not so deliberate.

Let me go ahead and apologize.

Let me open this file.

This didn't technically happen.

OK.

Python.

There we go.

OK.

In CS50, we now will run the code here.

And I'm going to go ahead and run a command called Python of crack.py.

I had the file in the wrong location a moment ago.

And this is the equivalent, on a Mac or PC, of double-clicking an icon.

Here we go.

Is it seconds, minutes, hours, or days?

Barely one second to try all 10,000 possibilities.

You can't even see them all on the screen, but this printed out 0, 0, 0,

0 all the way down, of course, to 9, 9, 9, 9.

Plug in that cable and boom.

The adversary doesn't need to be in that room for very long

in order to get into that phone.

All right.

So what would be better than?

Like clearly, four-digit passcodes, bad if you have someone in your life

who has a finger or a robot or the ability to write code.

And unfortunately, because of us, you now all

have someone in the family with at least the third of those.

How might we do better than this?

What's better than a four-digit passcode?

Anyone?

Yeah.

AUDIENCE: Six digits.

SPEAKER: OK.

So six digits.

Heck, or seven digits or eight digits.

Why?

Because that's going to make, of course, the passcode longer, which means

we're going to have to try more possibilities, which

doesn't mean that the adversary is fundamentally stopped.

But it is going to slow them down.

It's going to take them more time probabilistically

to get to your passcode.

And it in a sense then increases the cost to the adversary.

And indeed, that's the theme in cybersecurity,

raising the cost to the adversary, either financially or time-wise

or the like.

Just like in the real physical world.

Most of you go home.

You lock your doors at night.

You might have invested in a better deadbolt than another.

Why is that?

You really just want to be more secure than the house next door.

You want to make sure that it takes too much time, too much effort,

too much risk to the adversary to get into your home.

And that's, again, what cybersecurity is all about.

To say my phone is secure is sort of nonsensical.

To say that your phone is more secure than someone else's, that's really

a reasonable, fair statement to make.

So I like this instinct.

Let's see if we can't make things a little harder.

And actually, let's go one step further.

Rather than just numbers, you've probably noticed, on your phones,

you can use letters of the alphabet, too.

If you click the right option on the phone,

you can start typing in words and letters.

So how might we do that instead?

Well, let's transition to four-letter passcodes.

Four-letter passcodes.

And if we do four-letter passcodes where the letters of the alphabet,

for instance, are A through Z in English alone,

let's go ahead and ask this question here

if you have four letters of the alphabet.

So let's not increase length yet.

Let's just change to a bigger vocabulary.

Now, we have A through Z instead of 0 through 9.

How many four-letter passcodes are possible?

How big is that universe that the adversary is going

to have to search via brute force?

So I'm seeing a lot of 7 millions, a bunch of 52,000s, 26,000s, 10,000s,

9,999, a few smaller numbers here.

Hopefully, it's not this low, right.

Because we've already set the bar at 10,000 possibilities for numbers alone.

Hopefully, if we've got English letters, A through Z,

we can at least do better than 10,000.

So I think we'll start to see maybe some of these bars change a little bit.

But we've got 60% of you proposing 7 million.

Well, let's go to the math.

So here we might have a way of thinking about this,

both uppercase and lowercase.

Even better if you consider it that way, lowercase A through Z,

uppercase A through Z. That's 52 possibilities for the first digit

times 52 times 52 times 52, or 52 to the fourth power.

That indeed gives you 7 million-plus possibilities.

All right.

Well, let's now translate this to code.

That already sounds way better, 10,000 versus 7 million.

This is definitely going to slow that hacker down.

Well, let's consider exactly how fast or slow it might now be.

Let me go into my crack.py program.

And let me make a little tweak so that, instead of just using digits,

this time I'm going to use letters--

otherwise, known as Ascii letters, as CS50 students will know.

That just means familiar English letters of the alphabet.

And I'm going to change my code to use these Ascii letters, four

of them still, instead of digits alone.

And that's the only change.

Now, I'm going to pretend to plug my phone that I just stole from someone

into a USB or a lightning cable.

Let me maximize my window just so we can see things a bit more.

Let me run Python of crack.py now, and let's

consider how long it takes to do 7 million possible codes.

OK.

Slower.

Slower.

Can't dramatically just say in one breath that we're done,

but we're already at the Gs and then the Hs.

And it's kind of flying by.

This is where the adversary is probably getting nervous in the TV

show or movie.

Right?

Someone is tiptoeing around in the other room.

You don't want them to come in.

You only have this much time to crack the code.

And we're at the Rs, the Ss, the Ts, Us, Vs. So this feels like, what a minute

or so?

It's a good number of seconds, but it's still pretty brief,

certainly if someone has the ability to.

And now, we've got to do the capital letters, too.

Certainly, if someone has the ability not to just secretly do it

like in Hollywood in the next room but just take it with them

and do it over the course of a minute or two at home, this seems to be faster.

Sorry.

This seems to be slower, because we're trying so many more possibilities.

But if the adversary takes your phone, has it long enough,

this doesn't feel like terribly long.

So what might be better than this?

Let's take it one step further.

What might be better than four letters?

What do most websites ask you to add to the mix?

AUDIENCE: Special characters.

SPEAKER: So special characters.

Right?

And those things are darn annoying.

Right?

Because sometimes, they even tell you what letters or punctuation

symbols you have to use.

And then you type one and, oh, it's not on the damn list.

I mean, it's frustrating.

Why?

Well, it's going to raise the bar, though, to the adversary.

And that's, indeed, going to be the goal here, again

just to increase the cost or time required for the adversary

so that it doesn't finish like it did just now, after a couple of minutes.

But it's going to keep going and going hopefully, such

that they're going to lose interest in your phone

and go try to crack into someone else's, presumably.

So let's try this.

Let me now go over to one other question here.

And this question will now just be-- let's go from four characters.

How about let's take it one step further and mix the two ideas here?

More digits and longer passcodes.

How many eight character passcodes are possible?

And by character, as a CS50 will know, I mean number or letter

or punctuation symbol now.

And there's like 32 or so standard punctuation symbols, so we're

up to a good set of numbers now.

How many eight-character passcodes do you think are possible?

Million, billion, trillion, quadrillion, or quintillion?

All of which, of course, are better than 10,000 possibilities.

So we're in a whole different space now.

Looks like these answers are coming in a little more

slowly, perhaps as folks think about this.

Is 10 digits plus 52 letters plus 32 punctuation symbols.

Much more secure, it would seem.

All right.

We're up to 230 responses.

Give folks another second or so.

If you're trying to do the math, 10 plus 52 plus 32,

that's going to give you 94 possibilities for each of the digits.

All right.

We're just about at our 350.

All right.

I'm going to toggle over the screen here.

Going to click over to the results, show them in just a second on the screen

now.

And this is an interesting distribution.

I think some of you perhaps have the instinct now

of just go for the biggest one.

[LAUGHING]

It's not quintillion, nice as that would be.

Maybe it's quadrillion, trillion, billion, or million.

We have more of a split there.

So let's consider the math.

So if we've got eight characters, and I claim

that that's 94 possibilities for each.

10 digits, 52 letters, 32 punctuation symbols.

That's 94 to the eighth power, essentially.

And that indeed is six quadrillion possibilities.

Now, that's crazy big at this point.

I daresay we're pretty safe from the human finger now.

We're probably pretty safe from that robot,

which is going to take a while, too.

But Macs and PCs are pretty darn fast.

And God forbid the adversary have a big server, use the cloud, so to speak,

and really use a big expensive machine.

How long does it take to get into six quadrillion possible passcodes?

Well, how might we think about this?

Suppose, just for the sake of discussion,

it takes the adversary one second per code.

Just so we have some unit of measure to start with.

One second per code, which means, in the worst case,

the adversary really gets screwed and my passcode

is like 9, 9, 9, 9, 9, 9, 9 or with a lot of crazy punctuation symbols in it.

If each passcode takes a second to guess,

how long is it going to take the adversary if, in the worst case,

they spend six quadrillion seconds?

How many hours or minutes or days or--

AUDIENCE: A lot.

SPEAKER: --years?

I'm hearing a lot.

A lot is in fact correct.

I did do the math.

The adversary, if they're lucky and get all this way,

they're going to be 193,000 years old by the time they

get to all of those possible passcodes.

So this sounds alluring.

And in fact, let's just change our code one final time just

to get a sense of how this might look and behave.

In this version here, let me go back into my code

and let me change this now to use, not just Ascii letters, but digits.

And I'm going to add in punctuation.

For CS50 students, there is, again, this library

called the string library that lets you just import all of these symbols

automatically.

So we don't have to type out every character on my keyboard manually.

And then down here, I'm going to take the product of those Ascii letters

again, plus those digits, plus the punctuation

repeated eight times I claim this time.

I'm going to now increase the size of my window

just so we can see more on the screen.

Rerun the code, and this is going to take

us some hundreds of thousands of years.

So we won't run to the end of this demo.

Now, we seem to be in a better place.

All right.

So what's the takeaway here?

Clearly, you should use a passcode, a password

that's eight characters with letters and numbers and punctuation.

Yes?

OK.

There's a mix here.

Some of you are saying yes.

Some are no.

How about someone who says no.

Why?

Why no?

Yeah.

AUDIENCE: Recapture.

SPEAKER: Recapture.

OK.

So there's other mechanisms.

More on that in a second.

Other instincts?

Yeah.

AUDIENCE: The computers are much faster than just one code per second.

SPEAKER: Yes.

I'm kind of cheating with my verbal simplification here.

Even this computer is way faster than one code per second.

So it's not going to be hundreds of thousands of years.

Might be tens of thousands of years or hundreds of years,

but it's not going to be quite as dramatic as this.

So that's a concern.

AUDIENCE: Can't some passwords be made secure

where you can guess a certain number every hour?

SPEAKER: Yes.

So maybe there's other mechanisms.

So maybe we don't have to be so extreme as to introduce all of this randomness,

as was proposed before.

Because honestly, there's this theme in computer science, too, and really

information technology of trade-offs.

Right?

Sure, I can use a really big random password.

But my God, I'm going to end up writing it on my monitor

on a post-it note, which I suspect statistically some of you

are guilty of.

Right?

And you shouldn't necessarily just blame yourself

or your colleague who's doing this.

Like this is a symptom perhaps of bad IT policy.

If we don't have necessarily very usable systems,

maybe we shouldn't blame the human for forgetting their very random password.

Maybe we shouldn't require the human to have a very random password.

So what could we do?

A couple of technical mechanisms were just proposed.

Let's go down this road of how we might try to defend against this.

And I'll keep this running just for fun in the background.

Let me switch back over to a Visual here now

that we've considered that many codes.

What if we do something that some of your own phones

already have that slow the adversary down?

And some of you might have seen, on your iPhone, a screen like this.

Let me zoom in.

IPhone is disabled.

Try again in one minute.

Has anyone locked themselves out of their phone like this?

I have.

I mean, it's embarrassing to admit, but it's not leaking any information.

All right.

So many of you have done that already.

But why is this actually a compelling feature?

Just to be clear, annoying as this might be,

because you probably don't want your phone locked

at the very moment you're trying to get into it, why might it be a good thing?

Yeah.

Let's go somewhere else if we may.

Yeah, in back.

AUDIENCE: Slows down.

SPEAKER: Sorry?

AUDIENCE: Slows down your response.

SPEAKER: It slows down the process.

It annoys you, to be fair.

Like you pay a bit of this price, but it really slows down the adversary.

Now, they're going to be able to type in not one code per second but one

code per minute, a 60 times difference.

That's really going to force them to pump the brakes.

And unless that adversary is after you specifically,

odds are they're going to go take someone else's phone

or lose interest because you've raised the bar high enough to their

getting in.

On Android, if you do this, it depends on the operating system version.

Here, might be something similar on Android.

Too many attempts.

Try again later.

I mean, this is even more annoying.

It doesn't even tell you when to try again later,

but it does slow down the adversary.

So if you don't have features like this enabled, you should.

And if you're particularly security conscious or paranoid even,

you can even enable a feature on these phones

nowadays where they self-destruct, so to speak, after 10 wrong guesses.

Right?

Why 10?

The presumption is, among Apple and Google and others,

that, if you type your passcode 10 times wrong,

you're probably not who you say you are.

You're probably someone else.

Although if you're a little groggy first thing in the morning

or if you've been out late and having a good time,

you might not be a high enough threshold to protect your phone from you.

And so there, too, is this trade-off again, and that's an extreme one.

If your phone deletes itself, which is what I meant by self-destruct, then

that might actually be to your detriment.

Unless you have backups and all of that, but that's another technology

question altogether.

So there, too, this theme of trade-offs.

You raise the bar to the adversary, but you've got to pay the price.

You're not going to get any such feature for free.

All right.

What's another mechanism that many of us increasingly, thankfully, are doing?

Might be when you log into a website, like Gmail,

to have two-factor authentication.

Sometimes, called "two-step authentication."

I mean, how many of you use two-factor or two-step authentication

with at least one account?

All right.

So that's amazing.

How many of you use it with all of your accounts?

All right.

Fewer of us.

And there, too, that's not necessarily the wrong answer.

Right?

I have a lot of stupid websites that I have accounts on,

like I bought something once on them.

I don't really care about it.

So there's a judgment call there in terms of what you really care about.

But maybe your financial websites, your health care websites,

or anything that's mildly sensitive to you probably

should be raising the bar to the adversary by enabling this.

So what is this?

Particularly for those of you who didn't raise your hand, someone else, what is

two-factor or two-step authentication?

What's two-factor?

Yeah.

AUDIENCE: When you have to use your phone to verify that it's really you.

SPEAKER: Yeah.

So when you have to pull out your phone and verify that it's really you.

And in the corporate world, you might have

a little dongle, a key fob on your keychain

that's got a little number on it.

But generally speaking, two-factor authentication

is all about, indeed, a second factor.

It's kind of oversimplified as two steps,

but it's really key technologically that it be a different factor.

It is not two-factor authentication if you just

have two passwords that you have to remember, because both of those

could be forgotten by you.

Both of those could be stolen by someone else

if you write them down on the post-it note or the like.

Two-factor authentication is about having a fundamentally different factor

available to you so that the odds that someone

get at something you know, like your password, and something you have,

like your phone, is just much, much smaller

than the threat of just figuring out something you know, like a password

alone.

So the factor is something that's fundamentally

different from the other thing.

And so once you configure this, the user typically

sees a screen like this, for instance, in the context of Gmail.

The screens vary here at Harvard and Yale.

Students are familiar with something called "Duo mobile," which

is the exact same idea.

And they typically use one-time codes, six digits thereabouts.

And you can only use that code once.

And the idea is it's texted to you or pushed to your device

so that you and only you can use it.

Does this fundamentally secure your account?

Is this enough, to just have a good password and two-factor authentication?

Does that keep the adversaries out altogether?

AUDIENCE: Not if someone wants to get in.

SPEAKER: Not if someone what?

AUDIENCE: Really wants to get in.

SPEAKER: OK.

Not if someone really wants to get in.

Then you have other problems are certainly of concern,

but you do want to ideally keep most adversaries at bay.

And there are two.

All we're doing is like raising the bar.

Right?

There's nothing stopping someone in physical proximity

to me stealing my phone and getting into all of those accounts I just

raised my hand about.

But you at least protect yourself against the billions

of other potential adversaries in the world that

are geographically not near us, so you at least narrow the threat.

So that's a good thing.

But what else could we do?

Because I feel like it's not fair for us to say, all right.

Everyone go home.

Start using better passwords-- longer, more complicated.

Because again, there's this trade-off.

We don't want to send everyone home essentially with a pad of post-it notes

to then counterbalance what's an unrealistic expectation.

So how many of you, perhaps with a show of physical hands,

use a password manager already?

This is something practical we can equip you with.

OK.

So that was relatively few hands.

And those of you who are in the habit still of memorizing your password,

or worse, writing down the password, there are better solutions today.

But here, too, there's going to be a caveat.

There's no clear win necessarily.

A password manager is a piece of software

that you install on your Mac or PC or your phone that

manages your passwords for you.

And these come either built into the operating system.

Windows has credential manager.

Mac OS has something called "keychain."

There's third-party software like 1password or LastPass.

Companies and universities often have site licenses

so that students in particular can use these kinds of things for free,

but the ones that come with your operating system or phone

are themselves already free.

And not using them is really the missed opportunity here.

So what is a password manager?

It's a program that, yes, manages your passwords.

But it does a few things more.

It generates passwords for you, typically.

I mean, honestly, it's been years since I have

chosen my own password on a website.

I instead click a button in my password manager software

or I use a keyboard shortcut to generate something

that's eight characters, heck, maybe 16, 24, 32 characters long.

I don't care because the software's job is to manage that password for me.

That is, the software remembers this crazy long password for me.

And better yet, it comes with a button or a keyboard

shortcut that will automatically fill out forms for me on the web.

When I say log me in, it will grab my password from my computer,

plug it in, and voila.

I'm logged in.

The upside of this is that, even if that website is compromised

and my password leaks out, I'm not using that password presumably

anywhere else because the software's job is generally to create

unique passwords for each website.

And it's not going to be guessed via brute force,

by one of you writing code, because it's just too long.

Probabilistically, we're all going to be gone by the time your computer finishes

trying to crack it.

So what's the downside?

I mean, this sounds great.

If the software generates passcodes for you and plugs them in for you,

where's the downside?

Anyone?

Yeah.

AUDIENCE: If you're using somebody else's computer

and you need to access it, then you don't know the password.

SPEAKER: Yeah.

If you use someone else's computer or you're

in like a library environment, a lab environment,

you don't have your passwords accessible.

Now, there's a way to mitigate that so long as you

sync the same software to your phone.

You might have to pay another $1.99 or $20

to have the same software on your phone.

You can at least mitigate that by sharing the passcodes

across your devices.

Not as user-friendly.

You're going to have to now manually type out this really long password

and that, too, is annoying if you get one character wrong.

But that's one way to mitigate that.

Other concerns?

AUDIENCE: If someone cracks the code, then they now have all your passwords.

SPEAKER: That's maybe the biggest threats.

I mean, you're kind of putting all of your proverbial eggs

in the same basket.

If someone now gets into my password manager, which I should stipulate

is supposed to itself have a really big long password

that I do have to remember, but only one such long password,

I mean, then I'm really out of luck.

Now, every single account I own is compromised except for those

that at least have two-factor.

Unless the adversary also steals my phone or my key fob.

Other concerns?

AUDIENCE: If someone is like [INAUDIBLE]..

SPEAKER: Exactly.

If someone gets physical access to your device, honestly in general,

all bets are off.

And this is why some of today's listeners are really important.

It's only going to matter when you first lose your phone or someone walks off

with your laptop or the like.

There are certain things you can do to defend

against that inevitability, dare say.

But you want to make sure that, if you are

using some of these solutions like a password manager,

that that long primary password you use for it is itself really hard to guess.

And I would say, I'm OK with you writing that down even

but putting it in like a safe deposit box

or hiding it somewhere in the house that's

just very low probability of someone finding.

Because the other problem with putting all of your eggs in one basket,

if you forget your password, then you lose everything.

And that, too, seems like a pretty serious price to pay.

But this is a constant battle in computing nowadays, usability

and security and finding that inflection point.

But there, too, you can be selective.

Right?

I called out financial information, health information,

your personal email, your calendar.

Anything that's mildly more sensitive to you or important,

raise the bar at least on those accounts even

if you're not quite ready to go all in on all of these other factors.

Well, let's consider then where we're using these passwords.

Consider just a couple of specific examples.

Email, of course.

Gmail is the example I used earlier.

Gmail and email accounts, more generally,

are increasingly offering us features.

And in fact, there's one that I thought we

could highlight as an example of something

that, as a CS50 student, a CS50 family member,

you should really start viewing the world with a more

skeptical eye, a little more paranoid eye,

and not necessarily just believe things that websites say.

I mean, it's mostly meaningless when a website says--

sometimes, with a pretty little logo or emblem--

our website is secure.

What does that even mean?

And it's again, all about relativity.

And even Gmail, I daresay somewhat irresponsibly,

has this feature in recent years.

Confidential mode.

Is anyone-- if you're using G Suite or Google Apps at work or workspace

nowadays-- in the habit of using confidential mode?

I mean, it sounds--

OK.

No one's using this, so this is great.

And I worry now that I'm introducing you to a feature

that you shouldn't necessarily use.

But all this time, if you're a Gmail user,

there is, along the little menu bar, an icon

that lets you enable confidential mode.

And later tonight, play around for it.

Just look for it, and you'll see exactly this screenshot,

which I took yesterday.

According to Google, recipients won't have the option to forward,

copy, print, or download this email.

Right?

Great for lawyers, it would seem.

Great for business.

Great for private correspondence.

But why is this perhaps a bit misleading?

Where should the skepticism come from here?

Even a company like Google, I dare say, they've

probably buried the caveats that I'm hinting at under the Learn More.

But unfortunately, that might be too late.

Yeah.

In back.

AUDIENCE: Will they be able to take screenshots of the mail?

SPEAKER: Yeah.

I mean, those of you who know how to take

a screenshot, that's the simplest way.

If you don't know how to do that, well, here's a phone.

I can just take a picture of what it is I see on the screen.

And so these are software defenses that are

in place that essentially disable the Forward button,

disable the Print button.

But honestly, as you probably already know,

once something is already digital, I mean, it's out there.

And there are other ways to get it.

It might not be as high quality if you're taking out your phone to do it,

but you should view things like this with skepticism.

And even I, when I occasionally receive something like this,

I kind of roll my eyes but regret that the user thinks what they're

doing is consistent with this language.

But it isn't necessarily.

And so indeed, in part, from an introduction to computer science,

you begin to get a little scared from what's going on out there.

Because there are so many different threats and so many things

that you can't, in fact, do.

And the onus is, unfortunately, often on us users to read between the lines

and see what actually is possible.

Here's another one that you might be more in the habit of using,

incognito mode or private mode in Chrome or Safari

or Firefox or Edge or the like.

What does incognito mode do, if familiar?

What's incognito mode?

Yeah.

It doesn't log locally what you're doing.

It doesn't log locally what you're doing.

Exactly.

Most people here probably generally know about things called cookies, even

if you're not quite sure how they work.

But they're like these little remnants or bread crumbs

you leave behind when visiting websites that allow the websites to keep track

of who you are in some sense.

According to Google here, when you're using incognito mode,

Chrome won't save your browsing history.

So that's good.

Cookies and site data, information entered into forms.

But to their credit, they do disclaim that your activity might still

be visible to the websites you visit, your employer or school,

your internet service provider.

So they're getting better at at least helping

you evaluate by giving more of the facts whether you

do or don't want to do this.

But this doesn't mean that the websites you're visiting, indeed,

don't know who you.

Are all of our computers have unique addresses,

these things called IP addresses that you might have heard about.

In CS50, we'll explore these in another week's time.

Your computer is constantly leaking information that

could be used to infer who you were.

So this is really just best left when you

don't want to accidentally, on like a friend's computer or a lab computer,

remain logged in.

Because cookies are typically used to just remember that you've logged in.

So if you use a friend's computer, you use incognito mode

and just close the window.

Boom.

You're effectively logged out.

But even as Google disclaims, there's other caveats there, too.

So what else might we keep in mind?

Let's consider one other big one that's another thing

to start looking for increasingly in order to keep yourself secure,

and this one's a little more technical.

Encryption.

And as CS50 students will know, this is something you can implement in code.

And in fact, let me ask this question.

What does it mean to encrypt something?

Think back to pset2 and Caesar and the like.

Let me look a little farther back.

Almost any student hands should theoretically be up here.

Yeah.

AUDIENCE: You can substitute characters [INAUDIBLE]

so that you can't read it as the first ones.

SPEAKER: Exactly.

Encryption is all about substituting one letter for another

and generally scrambling the appearance of some message

up so that the recipient knows how to reverse that process

and see what you actually sent.

But anyone intervening in between you can't actually

see the information between you.

So just to impress the parents in the room, any students, what does this say?

We're not ending here.

AUDIENCE: This was CS50.

SPEAKER: This was CS50.

That's what it would say, but notice the scramble.

Let me go back and forth, back and forth.

In this message, t becomes u, h becomes i, i becomes j, s becomes t.

This is what we called a few weeks ago, in CS50, a rotational cipher a Caesar

cipher, that literally does, as you described,

substitutes one letter for the next.

But it does so in a very predictable way.

A becomes B, B becomes C, and so forth.

And we also talked, weeks ago, that you don't have to keep it that simplistic.

You can use a bigger mathematical formula

to make it at least harder for some adversary to figure out.

But you and I, as users these days, are constantly thankfully using encryption.

You probably generally know that you should be hoping for,

expecting this these days.

Like HTTPS is a good thing.

S means secure, literally.

And any website that has that in its URL indicates

to you that you and the website are having an encrypted,

a scrambled communication, which means, if you

type in your password, your credit card information,

anything else personally, no one between you theoretically, points A and B,

should be able to know what it is you've typed into that web page.

The web page absolutely can, because they

have the ability to decrypt that information, to reverse the process.

But at least encryption is generally a good thing.

But today, let's take that one step further and encourage you all

to be looking for, expecting, if you will, as consumers increasingly

in the coming years, something better than encryption alone

but end-to-end encryption.

And you're starting to hear about, read about this a little bit more.

But it's perhaps a little less familiar.

Someone in the room, who's familiar, what is end-to-end encryption?

Let me give folks a moment.

What is end-to-end encryption?

OK.

Yeah.

AUDIENCE: It's where you always try [INAUDIBLE]..

WhatsApp encrypts a message on one side and sends it

where it's encrypted on the other side.

SPEAKER: Good.

So it's when an app, like WhatsApp, encrypts a message,

but it's encrypted all the way to the other side, to the recipient.

Even though Facebook, in this case, owns WhatsApp,

even though your message is going through Facebook or MetaServers,

they do not have theoretically the ability

to decrypt your message, whatever chat message you've sent to a friend.

They are just sending seemingly random zeros and ones all the way to the end

user who can then decrypt it.

If you're an iPhone user, iMessage, for instance, does this automatically.

So long as your text messages are blue and not green,

that means you're using iMessage in Apple's platform that does this.

But let's focus perhaps on something that's

been all too familiar to most of us over this past year, Zoom.

Right?

Zoom actually took some flack some months ago.

Because in their marketing literature, they

were advertising end-to-end encryption.

They were not implementing end-to-end encryption, at least initially.

This was probably marketing gone awry, not quite

understanding what end-to-end encryption means.

They were using encryption.

And what that meant is that, if I were having a meeting with a colleague

or you were sitting in on a class with a teacher,

you might have an encrypted connection-- all of you-- to Zoom centrally,

but they had the ability-- early on and still now if you leave this feature

off--

to decrypt that information and see and listen to theoretically anything

going on in that meeting or that classroom.

Now, technologically, there's not really a good defense against that

if using that older approach.

All it really is is policy.

Or hopefully, there's rules in place, there's contracts in place that say,

well, yeah, that's possible, but don't do that.

End-to-end encryption is a stronger guarantee for you

that circumvents that risk altogether by ensuring

that, if you're tuning into that class or you're logging into that meeting,

all of the zeros and ones are going through Zoom servers,

just like Facebook's, but only the end users--

only the students and teachers, only the colleague and colleague--

can actually decrypt and see and hear what it is that's being said.

And if you're one who schedules Zoom meetings, you can actually see this.

For instance, here's a screenshot that I took yesterday, too,

scheduling like a Zoom meeting for today.

And you'll see that you can choose the day and the time, the password.

Haha.

And also down here, the encryption level.

And by default, it's typically enhanced encryption, which is stupid.

Like enhanced encryption.

It's just encryption.

And in fact, it's sort of worse encryption than the other checkbox,

which is end-to-end encryption.

But there's this little caveat.

And here, too, consistent with this reality in computing,

there's always a trade-off.

Right?

It's not all upside and all win.

Several features will be automatically disabled

when using end-to-end encryption, including

cloud recording and some phone stuff.

I mean, that's already kind of a big loss for a class,

for instance, a conference that wants to keep the sessions.

But it kind of makes sense.

Right?

If the data is encrypted between all of the end users

and, therefore, Zoom has no eyes into the data or ears,

then it makes sense that they can't record it for you in the cloud.

Because it's completely, completely scrambled to them, too.

So a good primitive to have in place but also something

that you need to sacrifice in terms of usability.

Well, in our final moments here, let me flip back over

to where our hacking tool is.

It would seem that eight characters is doing really well, because we still

got three As at the beginning of this.

So that might be, in fact, one take away.

And in fact, let me flip over and proposed three pieces of homework

for everyone here.

One, use a password manager, the one that's

built into your phone or your operating system

or pay a little something more for something

that you might like a little better.

Two, use two-factor authentication for more of your accounts.

Maybe not all but at least more of your accounts,

and that's certainly a net improvement.

And then three, use not just encryption but end-to-end encryption.

And unfortunately, these features are not all quite as simple as, oh, well,

let me just check the box and turn on something

that's always been available to me, because it's not always been available.

And Zoom, only once they got in trouble for this,

did they acquire some other company that implements this feature

and then add it to their software.

But as users, as consumers, as parents, as students,

considering choosing one tool or another because of these features

is really something you are empowered to do.

And do not use those tools that you don't think

meet some threshold of comfort for you.

For more on this and computer science more generally,

any of you can take CS50 online at edx.org/cs50.

It's been so nice to see you.

Happy to chat one-on-one.

But otherwise, have a wonderful day here on campus.

This was CS50.

[APPLAUSE]

[MUSIC PLAYING]