All language subtitles for [English (United States)] CS50 2021 - Cybersecurity (SDR) [DownSub.com]

[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]