Trust – CS50 Podcast, Ep. 1
Articles,  Blog

Trust – CS50 Podcast, Ep. 1

This is CS50. 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. Usually source code into machine
code, at least in our case of C. And who’s to say that Clang, the
compiler we happen to use in CS50, doesn’t have some malicious
lines of code in there. Such that if you’re implementing
any program that does use usernames and passwords, what if
the author of the compiler is inserting his or her user name
automatically always into your code? Even unbeknownst to you. So there too, unless you actually
built the hardware yourself and wrote the software
that’s running it. At some point, you either need
to just curl up into a ball, terrified that you can’t< 500 Internal Server Error

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.