Foursquare iPhone app sends passwords in plain text, don't use
martinkou.blogspot.com
Did a Wireshark session vs. Foursquare for iPhone's traffic after reading the news today. Found something very unpleasant.
martinkou.blogspot.com
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.
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.
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.
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.
2) Their desktop site doesn't use SSL either, as my Unencrypted Password Warning Chrome extension (https://chrome.google.com/extensions/detail/mjpinemnkjlppmem...) will warn you, so it should come as no surprise that mobile doesn't.
tl;dr version: Implementing HTTPS, should be live in "coming weeks'.
http://lh4.ggpht.com/_UrFI48Xbj8g/THD6IyfkCYI/AAAAAAAAALg/ZT...
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.
Additionally, keeping a user's clear text password in a local datastore is usually a 'bad idea'. At least store the MD5 or SHA-2 of the password (MD5 is considered insecure now though) and then pass the hash along to auth the user before giving them a token.
The IP checking bit is probably not a good idea. A mobile phone user can be switching between 3G and a public Wifi hotspot as he goes. It can negatively affect user experience.
And don't forget about the salt. Store password something like SHA-1(MD5(password)+password)
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.
POP - 4.3% FTP - 6.7% IMAP - 10% HTTP - 23% Four Square - 23% Twitter - 33%
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?
maybe because people usually check in over the Cellular data network and not wireless networks. I guess it'll be the same if there was a way to sniff out cellular data. Simple oversight or absence of a security mindset in app development.
I think one of the other geo-social-apps mandated checkins over WiFi (Loopt star i believe) .. It'll be interesting to see if they have the same flaw. In that case, it actually might be a bigger threat as the only way to send over information is over the wi-fi network.
However, unfortunately, there are people out there who will probably have the same password for their Facebook/Twitter accounts and even email accounts. Those are the people at threat here.
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.
GET /v1/checkins?geolat=34.2842613&geolong=-118.2471837&geohacc=112.0 HTTP/1.1
User-Agent: com.joelapenna.foursquared:2010080500
Host: api.foursquare.com
Connection: Keep-Alive
Authorization: Basic dXNlckBleGFtcGxlLmNvbTpwYXNzd29yZA==
POST /v1/checkin.json HTTP/1.1
Host: api.foursquare.com
User-Agent: Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2 like Mac OS X; en-us)
Content-Type: application/x-www-form-urlencoded
Authorization: Basic dXNlckBleGFtcGxlLmNvbTpwYXNzd29yZA==
Accept-Encoding: gzip
Accept: */*
Accept-Language: en-us
Content-Length: 250
Connection: keep-alive >>> base64.decodestring("dXNlckBleGFtcGxlLmNvbTpwYXNzd29yZA==")
'user@example.com:password'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).
I wish service providers would force app developers to use strong encrypted authentication channels.
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.
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.
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?
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.