Comments on: I’m in ur 4sq, snarfin ur password — Part I

By: Zach

Zach — Thu, 25 Mar 2010 18:49:06 +0000

You presume (incorrectly) that command is available on my box :>

By: Base64

Base64 — Wed, 24 Mar 2010 20:49:44 +0000

Just a short comment. You can append a newline so that the output of base64 -d is clean by using && echo. You also don't need to use openssl. So, for example:

$ echo "emFjaEBzb21lLnRsZDpteXBhc3N3b3Jk" | base64 -d && echo
zach@some.tld:mypasswordsome
$

By: whakojacko

whakojacko — Tue, 23 Mar 2010 20:52:50 +0000

foursquare.com (the regular website) just transmits both in cleartext…Hurray for security

By: Security Musings » Blog Archive » New Security Horizons with Geolocation

Tue, 16 Mar 2010 22:26:05 +0000

[...] fake check-ins trivial. But Foursquare also uses HTTP Basic authentication, meaning an attacker could steal logins sent over open Wi-Fi [...]

By: Zach

Zach — Tue, 09 Mar 2010 21:40:27 +0000

@anon:

Seems to be a bit of an issue with consistency in that particular custom style we use (for code blocks/snippets). We'll look into it. Thanks for the comment and the heads up!

By: AnonymousReader

AnonymousReader — Tue, 09 Mar 2010 21:36:21 +0000

Great article.

Your code listings are a bit confusingly formatted, because they make it look like the credentials are an argument to openssl rather than something printed by openssl.

For instance, take the first one where you have 'echo "emFjaEBzb21lLnRsZDpteXBhc3N3b3Jk" | openssl enc -base64 -d zach@some.tld:mypassword'. There is no newline after the '-d' and before the 'zach@…', which makes it look like you need to know zach's password to decode the string 'emFja..'. That's misleading — actually, decoding 'emFjaE…' yields 'zach@…'.

So you might want to adjust the formatting.

By: Best of Application Security (Friday, Mar. 5) | Portable Digital Video Recorder

Mon, 08 Mar 2010 15:10:43 +0000

[...] I’m in ur 4sq, snarfin ur password — Part I [...]

By: iginsight

iginsight — Wed, 03 Mar 2010 16:29:39 +0000

Thanks for the comments Paul. Yes, we've been doing mobile application security work since Intrepidus started.. this is really par for the course. (unfortunately)

We are in the early infant stages of uncovering all the problems. It's not easy because each platform, (windows mobile, rim, iphone, droid, webos, brew, etc…) has it's own API and it's own way of doing things. Then throw in the handsets themselves… even inside the platform not every handset has the capabilities needed to make use of security features. So that forces developers to roll their own solutions — and BAM! it's security like it's 1999 all over again. clear-text everything, base64, homemade XOR obfuscation, shared symmetric key on a handset because "no one will ever jailbreak the handset."

Thanks for reading our blog!

-Intrepidus

By: Paul

Paul — Wed, 03 Mar 2010 12:39:19 +0000

I found a similar issue with the way Squarespace was handling my website’s Admin account password.

I gave them a full report about it last year. Posted about it on my blog. Got so little response from readers and Squarespace that at first I was surprised and then shocked. They really didn’t seam to see that handling user passwords this way, and for that matter website admin user passwords, was any risk and saw no need to resolve the problem. In the end I gave up the call for action and just took steps to protect my own account. If anyone is interested here is the link to my blog that details what I found: http://j.mp/bPScL3

By: cji

cji — Mon, 01 Mar 2010 13:06:46 +0000

"Basic Auth over plaintext HTTP" is really the key here, to me. If they were at least doing this over SSL (which I believe was TweetDeck's solution – switch to SSL, not OAuth), it would mitigate some level of concern until they could take the time to do it the right way with OAuth.