Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Foursquare iPhone app sends passwords in plain text, don't use

martinkou.blogspot.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Foursquare iPhone app sends passwords in plain text, don't use

#31

Post by bl4k »

pmjordan wrote: post #15

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…

sessions are a one-time token. passwords are an all time token. biometrics are a forever token.

Re: Foursquare iPhone app sends passwords in plain text, don't use

#34

Post by theBobMcCormick »

callmeed wrote: post #32

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

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).

Re: Foursquare iPhone app sends passwords in plain text, don't use

#37

Post by mason55 »

TheEzEzz wrote: post #25
parenthesis wrote: post #24

Earlier quoted context omitted.

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.

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.

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

Re: Foursquare iPhone app sends passwords in plain text, don't use

#38

Post by varaon »

_cbsz wrote: post #20

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... ) 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.

Re: Foursquare iPhone app sends passwords in plain text, don't use

#39

Post by kordless »

jacoblyles wrote: post #36

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

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 want.

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.

Re: Foursquare iPhone app sends passwords in plain text, don't use

#40

Post by jacoblyles »

kordless wrote: post #39
jacoblyles wrote: post #36

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

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…

Do cell phones keep the same IP address for any significant period of time?
Post reply on HN