Foursquare's response: http://blog.foursquare.com/post/990202740/changes-to-our-aut... tl;dr version: Implementing HTTPS, should be live in "coming weeks'.
Incompetence of the highest order.
[deleted]
Foursquare iPhone app sends passwords in plain text, don't use
51–59 of 59 posts
Re: Foursquare iPhone app sends passwords in plain text, don't use
#521) 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... ) will warn you, so it should come as no surprise that mobile doesn't.
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.
Yeah, I got the warning on quite some sites incl. get satisfaction and even twitter at one point. Does it give false positives?
Re: Foursquare iPhone app sends passwords in plain text, don't use
#53Only 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 e…
This is why I prefer sites using openid or oauth.
Re: Foursquare iPhone app sends passwords in plain text, don't use
#54Ok - 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.
Re: Foursquare iPhone app sends passwords in plain text, don't use
#55What's the best way to handle this? Use HTTPS? I'm working on an app that will have a similar architecture.
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 encryp…
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).
Re: Foursquare iPhone app sends passwords in plain text, don't use
#56Oh 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.
Re: Foursquare iPhone app sends passwords in plain text, don't use
#57Earlier quoted context omitted.
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.
Yeah, I got the warning on quite some sites incl. get satisfaction and even twitter at one point. Does it give false positives?
See the FAQ. It is unable to tell if a form submitted by JavaScript is in fact submitted securely, so it warns.
Re: Foursquare iPhone app sends passwords in plain text, don't use
#58What's the best way to handle this? Use HTTPS? I'm working on an app that will have a similar architecture.
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 encryp…
Thank you for this information.
Re: Foursquare iPhone app sends passwords in plain text, don't use
#59Earlier quoted context omitted.
Use tokens issued for a user and IP combination. Use HTTPS to carry the auth for the user and return a token. Use the token with HTTPS or HTTP to continue talking to the server. Expire tokens after some reasonable time. Expired tokens indicate you need to reauth. If you lose a token, it could only be used by someone pretending to be you (and with your IP), so limit what a token can do via the service's API if you wan…
Yes, that's basically the way to do it. If you're doing it on a mobile phone you can even add HMAC (via SHA-1 or SHA-2, MD5 is still ok for that but we all know it's possible to produce MD5 collisions now) on that token when you're talking on HTTP. That way, all messages on the network will be at least authenticated. The IP checking bit is probably not a good idea. A mobile phone user can be switching between 3G and…
I agree don't use IP as a part of token - it will require user to re-authenticate very often.
And don't forget about the salt. Store password something like SHA-1(MD5(password)+password)