DAVID MALAN: Hello, world.

This is the CS50 podcast, and my name is David Malan.

COLTON OGDEN: And my name is Colton Ogden.

DAVID MALAN: And so glad to have everyone back with us today

for our second ever episode of the CS50 podcast.

COLTON OGDEN: Yeah, super excited.

So curious, before we start.

I walked in to your office just before this podcast started,

and you were on the phone.

Who were you on the phone with?

DAVID MALAN: You couldn't have asked that before we started rolling?

COLTON OGDEN: You seemed a little bit disgruntled.

DAVID MALAN: No, if you can believe it.

It was a robocall.

And in fact, ever since our discussion thereof,

and since the last week's Tonight Show with John Oliver started

focusing on this topic, I have legitimately

started getting more and more of these calls.

Where they're just spam calls.

And then you pick up and there's a very cheery computer

voice on the other end of the line.

COLTON OGDEN: You know, actually, I had to block a number,

because I was actually getting called consistently.

I got called--

DAVID MALAN: I'm sorry I'll call you less.

COLTON OGDEN: I got called everywhere every five to 10 seconds.

The same phone number was calling me after I called.

It must've been on a loop or something.

DAVID MALAN: That's awful.

Well, I mean the nice thing about iPhone is that you can actually

block calls pretty easily.

And I'm guessing you can do the same on Android.

But landlines from yesteryear, you're pretty much out of luck

unless you punch in some code with your phone provider to do it as well.

COLTON OGDEN: Yeah you can bet that actor got blocked.

DAVID MALAN: You know it's really obnoxious too.

And they think they're being clever.

Because most of the spam calls I get nowadays, like in the past week

are 617- 555- something, something, something, something.

Where 617- 555- matches my own phone number's prefix.

And I think the presumption is, and I think

John Oliver might have pointed this out, that they're

trying to trick you sort of social engineering-wise into thinking like,

oh, this must be a neighbor down the road

because their phone number is so similar.

And it's really frustrating now.

This really has peaked.

COLTON OGDEN: I don't think I ever got a call from anybody

in my life who is a legitimate actor who had the same prefix to my phone number.

DAVID MALAN: Yeah that's a good point actually.

I don't even notice, frankly, because it comes up sometimes

with my contact information.

And, anyhow.

Thanks for that.

Well, sort of a tie back into actually the last podcast episode,

where we talked about Facebook.

And they're sort of storing unhashed passwords out in the clear.

It looks like recently they committed another sort of offense

where they were actually asking people for their email passwords.

Not a Facebook password, but their actual external email passwords

through Facebook.

COLTON OGDEN: Yeah.

I read this, and I think they were trying to do this for well-intentioned,

at least we can perhaps give them the benefit of the doubt, in that they

wanted people to be able to confirm that some email address was

in fact their own.

And I presume some developer thought, well,

it'll be easy if we just ask them for their username, their password,

pretend to log into that actual system on the user's behalf,

and if they get in successfully, hopefully just

disconnect without poking around.

And just assume that the address is indeed theirs.

But this is just so unnecessary and so wrong on multiple levels.

I mean this is why companies actually instead send

you an email, usually with a special number, or word in it,

or URL that you can then click.

Because the presumption there is that.

Well if we send you an email, and you are

able to click on that email within 15 minutes,

presumably you do indeed know the username and password to that email.

And so therefore you are indeed who you say you are.

That's sort of the right, or at least the industry standard way

of doing this.

Even though it does add some friction.

You have to go check your mail.

You might have to hit refresh a few times.

So there's some UX downsides.

User experience downsides.

But that's secure, because you're not asking the user

to divulge private information.

This is just reckless, especially for a company

as big as Facebook to be conditioning people into thinking this is OK.

DAVID MALAN: I think letting big entities

like this act on our behalf in the security realm.

I mean, especially Facebook given that they've recently been

caught storing plain text passwords.

Putting my email password in Facebook's hands,

I don't know where that's going to end up at the end of the day.

COLTON OGDEN: No.

And honestly, even if it's not malicious,

and it is just foolish or accidental.

The reality is that servers log input or log transactions in their databases.

And so the data may end up just sticking around unintentionally so.

So it doesn't matter even that the intentions are good.

This is just bad practice.

And again to my point earlier, if you see this behavior being normalized

on very popular websites like Facebook.

Well what's to stop a user, especially a less technically proficient user

from thinking, oh, I guess that's OK.

That's the norm.

That's how this is done.

If they see it on some random adversaries

website that they get socially engineered into clicking on.

DAVID MALAN: It was kind of entertaining when

it was sort of brought to their Facebook attention that this was a bad idea.

In the Daily Beast article that I actually read about this,

someone actually brought this to Facebook's attention.

And Facebook came out, and to the world said, you know,

this probably wasn't the best way to approach solving this problem.

Because they had been caught doing [INAUDIBLE]..

COLTON OGDEN: To say the least.

You know, and it's interesting because big companies, Facebook among them,

presumably do have code review processes in place.

Involving multiple humans and design reviews.

And so what's especially worrisome here, or certainly surprising,

is how did this even ship?

Right.

At no point did some human presumably object to doing this.

And so that's I think the sort of fundamental flaw

or the fundamental concern is that how did something like this even happen?

Because students coming out of CS50 might certainly

be inclined to implement things in this way

and frankly, if you don't really think about it adversary,

or if you haven't been taught to think about things defensively,

you might make this mistake too.

But that's what mentorship is there for, more experienced personnel

or older folks are there for.

To actually catch these kinds of things.

And so that's the sort of process flaw that's of concern too.

DAVID MALAN: I'm certainly grateful that we have so many folks online who

are getting more technically literate in this domain

and are bringing this to everyone's attention.

Looking for these kinds of patterns and catching Facebook red-handed

when they do these types of things.

Not necessarily just Facebook, I'm sure this

happens at scale with many companies.

But it's nice to know that people are actually on the lookout for this.

COLTON OGDEN: Yeah.

And you know I should disclaim too, because I'm

sure we have students out there who will remember this.

Some 10 or so years ago, even CS50 actually

did foolishly use this technique on one or more of our web apps.

Because at the time there actually was no,

I believe, sort of standard that we could have used

to authenticate users in a better way.

OAuth, for instance has come onto the scene since.

And maybe even if it existed then, it wasn't nearly as omnipresent

as it is now.

So in short, there are technical solutions to this problem.

Whereby, the right way to do this is you don't ask the user

for their username and password.

You redirect them to Yahoo or Gmail or whatever

the account owner's website is.

Have them log in and then be redirected back to you.

Essentially with some kind of cryptographic token.

Something that's mathematically significant and very hard to forge that

proves, yes.

Colton did in fact just log into his actual Yahoo email account.

You can trust that he is who he say says he is.

That mechanism either didn't exist, or wasn't familiar

even to me back in the day.

And so we would just have a web form on CS50 site

to log in with their Harvard email address and their password.

And again, we were not intending this to be malicious.

We certainly didn't log anything deliberately, or thankfully,

accidentally.

But we could have.

And I think the fact that even we, as a course,

conveyed the message that, oh, this is OK, was a very bad message to send.

And so thankfully, some years ago we actually transitioned

to using more industry standard approaches like OAuth,

again this mechanism where you bounce the user to their Harvard Law login

then back to CS50 as just a sample client, or an application.

That's a much better way of doing this.

DAVID MALAN: Yeah.

Because in that scenario, you're actually allowing a third party

to let you perform this handshake I think

more securely than just having one entity perform

all the security for you.

COLTON OGDEN: Yeah.

No, and if you look closely, there might actually be examples of this elsewhere.

For instance, and it's been a few months since I looked.

In Gmail, I believe under your settings you can actually

add accounts to your account so that you can retrieve mail

from another account via POP.

Post Office Protocol.

Which is a way of downloading email.

There too, you're doing exactly the same thing.

You are trusting Google with your username and password

to some other email account.

The design there, though, is to enable Google to import that email for you

into this account.

And so as such, there's really no other way

to do that unless there is some other process involved where, via OAuth, they

can do that.

But that's actually not how POP works.

And so there, it's too is a technical constraint.

And that's kind of an artifact of yesteryear's designs

with a lot of these systems.

But it's worth keeping in mind that these things still happen.

And I think even when you log into sites for the first time

you're sometimes prompted for a username and password.

Maybe it's LinkedIn I'm thinking of, or Yahoo.

Because they want to make it easy to import your contacts.

So what better way than to just access your outright account.

But there, too.

You're trusting someone.

You are normalizing a behavior that's probably not best.

And so I think we as a society should really

start to resist this and distrust this.

Just don't do that.

DAVID MALAN: I feel like distrust is a very common theme

in the world of higher CS.

What was the article?

The very famous article on trust?

COLTON OGDEN: Oh, Trusting Trust.

DAVID MALAN: Yeah.

Yeah, indeed.

It was actually a Turning Award acceptance speech

that was then put into paper form.

If you really get into the weeds here, nothing is really trustable.

Right.

In CS50, we talk about compilers, which are programs that, of course, convert

one language into another.