

Foursquare iPhone app sends passwords in plain text, don't use - bitanarch
http://martinkou.blogspot.com/2010/08/foursquare-considered-harmful-dont-use.html
Did a Wireshark session vs. Foursquare for iPhone's traffic after reading the news today. Found something very unpleasant.
======
TheEzEzz
Only tangentially related:

The other day I was trying to log on to a service I rarely use, and couldn't
remember my password. So I started chugging through all the different
passwords I use. Then I realized what a _horrible idea that is_. If the
service wasn't benign (or if they were using plain text), I could have just
let out ALL of my passwords.

Really, really stupid, but I wonder how many people do this, and how effective
it could be as a way to collect passwords.

~~~
parenthesis
A similar case is typing in your email password by mistake when (trying to)
log in to a site where your email address is your username.

~~~
TheEzEzz
Good point.

I've been thinking about lazy registration a lot. I'm considering implementing
a service where the user will be prompted at some point to enter their email
to be remembered, but making a password optional.

The service would be worthless to hackers, but I suppose griefers could still
have some fun.

~~~
mason55
Instapaper does this; you only have to set up a password if you want.

------
tswicegood
Ok - so welcome to last year? I recall a PyCon talk on security a few years
ago where one of the speaker's first slides was a list of passwords with the
text "if this is your Twitter password, change it, then change your Twitter
client."

Most of these startups treat the iPhone as if it were some magical device
that's plugged straight into their API. I actually participated on a Get
Satisfaction thread for Gowalla where one person claimed they liked that it
was iPhone only (which dates how long ago it was) because it made it "secure"
and couldn't be "hacked the way Foursquare can."

Needless to say, they were disabused of that notion pretty quickly when
checked in at the Gug, the Apple flagship store in London, and my home within
the space of 30 seconds. It literally took 3 minutes to figure out - most of
which was spent setting up my iPhone to proxy through my laptop. They were
(and keep in mind, this is back when Gowalla was still iPhone only) sending
everything in clear text.

They also didn't regenerate session IDs for anything at the time. I logged out
and logged back in, same session ID. I logged out via my iPhone, loaded up
their site and changed my password, then logged back in, same session ID.
Basically, once you had sniffed one session ID you were set. I tried it a week
later and was still able to use the same session ID without any problem.

It's amazing that things like session hijacking are so unknown and unfamiliar
to people people relying on web frameworks to do everything for them. At the
time they were using Merb---I found out by hitting an
"/unknown/and/unknowable/" page and seeing their backtrace output. Session
hijacking is a solved problem, why they were subject to it I can't fathom.

------
bitanarch
Double, and triple checked. You can reproduce this yourself. I'm using a
MacBook Pro for this.

1\. Plug your MBP to wired ethernet - you have one of these in your home,
right?

2\. Open an ad-hoc network in your MBP, and share Internet access via that ad-
hoc network.

3\. Connect your iPhone to your MBP's ad-hoc network, now it should be able to
access the Internet via your MBP.

4\. Install and fire up Wireshark in your MBP - make sure to read the
instructions or otherwise it can't capture packets.

5\. Get Wireshark to capture packets on the ad-hoc Wifi interface.

6\. Filter out the HTTP packets going to *.foursquare.com by adding the filter
'http.host contains "foursquare"'

7\. Fire up Foursquare on your iPhone, login if you haven't already

8\. Boom, you've just sent your password in plain text, over the Internet.

~~~
kyro
I'm doubtful. Have you quadruple checked?

------
swolchok
1) Foursquare was one of the most popular targets for DEFCON'S Wall of Sheep
this year, next to Twitter. I believe the mayor of the con was also made the
mayor of Sheeptown.

2) Their desktop site doesn't use SSL either, as my Unencrypted Password
Warning Chrome extension
([https://chrome.google.com/extensions/detail/mjpinemnkjlppmem...](https://chrome.google.com/extensions/detail/mjpinemnkjlppmemjfabdaelpfgfjgkj))
will warn you, so it should come as no surprise that mobile doesn't.

~~~
varaon
Interesting extension, but Chrome gives an ominous "This extension needs
access to your data on all sites." I assume this is necessary to be able to
read the targets of forms.

~~~
desigooner
Yeah, I got the warning on quite some sites incl. get satisfaction and even
twitter at one point. Does it give false positives?

~~~
swolchok
See the FAQ. It is unable to tell if a form submitted by JavaScript is in fact
submitted securely, so it warns.

------
starnix17
Foursquare's response: [http://blog.foursquare.com/post/990202740/changes-to-
our-aut...](http://blog.foursquare.com/post/990202740/changes-to-our-
authentication-system)

tl;dr version: Implementing HTTPS, should be live in "coming weeks'.

~~~
foobarbazetc
Incompetence of the highest order.

------
mvip
Well, that's the case for their regular website too! No SSL at all
(<http://foursquare.com/login>).

------
bitanarch
I've been notified that Gowalla is also having the same problem - and
unfortunately it's confirmed. I've uploaded another screenshot showing the
same problem with Gowalla 2.2.1 on iPhone:

[http://lh4.ggpht.com/_UrFI48Xbj8g/THD6IyfkCYI/AAAAAAAAALg/ZT...](http://lh4.ggpht.com/_UrFI48Xbj8g/THD6IyfkCYI/AAAAAAAAALg/ZTgmRQ9bX98/s800/Screen%20shot%202010-08-22%20at%203.13.35%20AM.png)

Note that "Authorization: Basic" line - same problem with foursquare. If
you're running the same procedures I outlined with Gowalla you'd see your own
username:password right after the HTTP authorization line.

------
jacoblyles
What's the best way to handle this? Use HTTPS? I'm working on an app that will
have a similar architecture.

~~~
bitanarch
You can follow Facebook Connect's example. A few points there..

1\. Logins must be done on HTTPS. On the SSL level, the client must
authenticate the server's certificate - i.e. the client must check whether the
server's certificate is properly signed by a trusted CA, and whether the
server peer name matches the name that's being connected to, e.g.
api.example.com. This means nobody will be able to intercept the encrypted
passwords via man-in-the-middle attacks (e.g. by hijacking a DNS and
redirecting traffic to his fake api.example.com server).

With proper server certificate authenticate in place, only the
person/company/server with api.example.com's private key will be able to
decrypt the HTTPS traffic going into api.example.com. So as long as nobody
working for example.com posts the private key on Slashdot or HN, nobody
outside of example.com will be able to intercept the login passwords -
assuming they don't have other security holes like SQL injection problems.

2\. HMAC or HMAC-like scheme based on shared secrets and sequence numbers. If
you intend to let clients use your API via HTTP instead of HTTPS after the
login step, e.g. for performance reasons - frequent HTTPS handshake can slow
your app down a lot when you take network latency into account - you'd need to
have a way to authenticate your clients on the clear without using passwords
or just simple cookies.

What Facebook's HMAC-like scheme does is that they'll send a shared secret to
you on HTTPS, in addition to just the open session key, when you login. Any FB
Connect requests would have a session key, a sequence number, and an md5 hash
of the whole requests appended to the session secret. Because nobody else
knows the the session secret, the only person who can generate the correct md5
hash for that request is you. So even if an attacker can intercept e.g. a
Facebook status update from HTTP, he wouldn't be able to change it or post
something else to your wall later. The sequence number is there to prevent
replay attacks so the attacker wouldn't be able to post the same message
again.

~~~
revetkn
RE: point 2, The Facebook Graph API (which will at some point deprecate the
Old REST API) does not operate in this fashion. You receive an OAuth access
token and pass it back to FB over HTTPS. Unlike the Old REST API, no
MD5ing/secret key signing/etc. is required. And the sequence number passed to
the Old REST API is _not_ there to prevent replay attacks - it simply needs to
be a number larger than any of the previous messages' sequence numbers (as an
attacker, I'd just pass in a very large value; in practice, everyone just
passes the UNIX timestamp).

------
valentin
Traffic captured at Defcon 2010 Wall of Sheep

POP - 4.3% FTP - 6.7% IMAP - 10% HTTP - 23% Four Square - 23% Twitter - 33%

------
EricButler
Foursquare doesn't support SSL at all. The best you can do is request a long-
lived OAuth token, but even doing that requires sending the user's
email/password in plaintext (although only once!).

~~~
whakojacko
Yea I mentioned this on twitter to one of their engineers a several months ago
and he said it was "on their to-do list." Seems a little too important for
that.

~~~
j0
it's been an issue on their getsatisfaction page for 10 months ...
<http://getsatisfaction.com/foursquare/topics/https-o65c> ...

------
tszming
I hope all browser makers should show a warning message when user submit a
form contain the field "password", if that action is not protected by SSL.

------
ramine
Have you double checked? Seems weird, especially for a mobile checkin app that
is much more likely to encourage using open wlans :/

~~~
phjohnst
Yeah, I have a hard time believing that this is accurate. Definitely scary if
true, but I would like to put my faith in Foursquare having checked this box a
long time ago.

Also: why, after millions of checkins over public networks, is this only
coming up now? Surely someone would have got burned by this by now?

~~~
jsz0
Probably just because it's not very practical and there is no obvious payoff.
You would have to sit around a popular spot for hours with a laptop sniffing
the wifi to collect logins. What do you do with them? For SPAM purposes it
would be easier to just make new accounts. As far as I know there's not a
whole lot of valuable information in a FourSquare account like credit card
numbers or banking information. Seems like the only thing you could really do
is embarrass people.

~~~
bitanarch
A lot of people use the same passwords for GMail, bank, credit card, Facebook,
..., and Foursquare. So it's a big deal if you can easily collect passwords
from any one of these services.

~~~
phjohnst
Exactly... I guess this is just another lesson that security of a network (in
this case meaning all the different services we use) is only as strong as the
weakest link. Certainly not going to be firing up the foursquare app for a
while

~~~
Timothee
Related to the "security of a network":

one of my Facebook friends got his account compromised recently and a scam
email was sent to many of his contacts. I think the scammer got the FB account
somehow, and found the email of my friend as well as the emails of his FB
friends shown on FB (like mine…).

It made me realize that your info on Facebook is as safe as the weakest
account of your Facebook friends. I'm in control of my own passwords and make
sure that all my passwords are different. But I can't control my friends'
password policies, which are probably very weak overall.

------
callmeed
Is it easier or harder to intercept a password over 3G than wifi? (I'm just
curious)

~~~
theBobMcCormick
It depends. Obviously unencrypted wifi is trivial to sniff, and WEP encrypted
wifi is only modestly harder. However, wifi _can_ be configured to be highly
secure, with for example WPA2/AES, etc.

Both GSM and CDMA are encrypted, but I believe both have been broken and
aren't considered as secure as something like WPA2/AES.

Keep in mind though, that it's not _just_ the trip over the wireless network
that's at issue, it's also anywhere on the Internet between you and the
service you're using (Foursquare in this case).

------
st3fan
Oh you don't want to know how many apps are doing this. People just have no
idea.

I wish service providers would _force_ app developers to use strong encrypted
authentication channels.

------
tlrobinson
Guess what: unfortunately most websites do. If you share a password with a
website that does, then game over.

------
natch
Good to know. I'm out.

------
pmjordan
Unless you're reusing passwords (which of course you shouldn't be), this
doesn't really seem any worse than any other unencrypted website login, or
hijacking authentication cookies from an unencrypted connection. The latter
you could even do with gmail until they defaulted to SSL.

If you were using, say, Hacker News on a public wifi without going through a
VPN or so, I could trivially log in as you just by looking at the Cookie:
headers you send to it. I don't need your password to post as you and I
probably could even change it because HN doesn't ask for your old password,
but maybe it requires email confirmation in which case you just need to
notice. Of course, HN is a similarly low-key target as 4sq for this sort of
thing.

~~~
bitanarch
The damage of an intercepted cookie is limited to the site you're logged into
- if I intercepted your Hacker News cookie, I can't use it to log into your
bank account.

The damage of an intercepted password is much bigger. It's a fact that most
people reuse passwords. You can't say the issue doesn't exist just because you
shouldn't do it.

There're also services that are a lot more careful than that. e.g. Facebook
Connect's API uses HTTPS for (at least) the login so you can't intercept the
passwords, and then it uses an HMAC-like authentication so that even if an
attacker can intercept any non-encrypted messages, they can't change it or
impersonate you.

~~~
pmjordan
My point is I fail to see how this is an unusual or new situation. You can
probably accuse millions of sites of sending passwords in the clear on login.

Besides: say I steal your HN (or whatever) cookie and hit _logout_ from your
account. Your auth cookie is now no longer valid, you get a login prompt. You
assume it's some kind of glitch and re-login with your password, which I
intercept. Is that much better?

~~~
bitanarch
Thing is.. very few people go into random restaurants and login (and I mean,
login, in which you type in your password) to sites like Hacker News or
Slashdot every day. The chance of you opening a public AP in a crowded place
and getting back a Hacker News password is slim to none - I'm not saying it's
safe though.

Foursquare passwords, on the other hand, is something you can very easily
intercept in the open - due to the way it's used, and that it sends your
passwords out every time you open it without you typing anything - that's
already unusual. There're surely a lot more poorly secured sites and mobile
apps, but something like Foursquare's authentication scheme is a big problem
for its users.

