31–40 of 54 posts
Pretty off topic, but I submitted this story last night [1] with the exact same URL and title. I thought whenever duplicate stories were submitted, it just upvoted the original submission without posting a duplicate story (that's what's happened to me in the past). I originally saw this, and thought the URL was just different (even if just slightly), so I wasn't even going to say anything. But since the URLs are iden…
Pretty off topic, but I submitted this story last night [1] with the exact same URL and title. I thought whenever duplicate stories were submitted, it just upvoted the original submission without posting a duplicate story (that's what's happened to me in the past). I originally saw this, and thought the URL was just different (even if just slightly), so I wasn't even going to say anything. But since the URLs are iden…
I think this one got more traction just because of the timing of the post too being in the morning and getting enough traction to make it to front page.
"If you grab someone's phone, you can effectively go through this log and see effectively where this person has been," Wood said. "It's a bad thing for user privacy" Compared to what? The implicit assumption is that Starbucks gathering and storing geolocation data is not a potential invasion of privacy or a meaningful risk. The person who steals my iPhone is very unlikely to do so for the data it contains. Their goal…
So are passwords broken or not? (Hint: they are.) You can't use the inherent drawbacks of passwords as an excuse for introducing even more vulns. ISTM the location data is stored client-side not because of some wise decision to spread data out (and then what, include it as query data in future reqs to the server?) but rather because their error handling module wasn't configured.
"If you grab someone's phone, you can effectively go through this log and see effectively where this person has been," Wood said. "It's a bad thing for user privacy" Compared to what? The implicit assumption is that Starbucks gathering and storing geolocation data is not a potential invasion of privacy or a meaningful risk. The person who steals my iPhone is very unlikely to do so for the data it contains. Their goal…
This is completely off-topic, but am I the only one who wondered why his wife would hire a PI to find out if he is an attractive lab technician?
Not as a critique, I just find grammatically-correct ambiguous cases like this one interesting.
Pretty off topic, but I submitted this story last night [1] with the exact same URL and title. I thought whenever duplicate stories were submitted, it just upvoted the original submission without posting a duplicate story (that's what's happened to me in the past). I originally saw this, and thought the URL was just different (even if just slightly), so I wasn't even going to say anything. But since the URLs are iden…
It's not the same URL. Yours was the mobile version (it has a m.) and his was the normal URL. I think this one got more traction just because of the timing of the post too being in the morning and getting enough traction to make it to front page.
That's what I get for posting submissions from my phone.
Earlier quoted context omitted.
It's crazy to think that a developer would publish an application that would store username/password in clear text. iOS has a keychain API that would require maybe 3 hours of work to make it work/test. I'm sure Android has something similar.
There are tons of "developers" out there that don't know much about security or really care about it. This is especially true in the mobile space where anyone that has published a Hello World app to the app store can get a job working as a contractor. This makes me think though that there could be some good money to be made by opening every single app like this to check it's security then offering services to said co…
Ok so try it this way.
Contact the company [1] [2] and tell them you believe there might be security holes in their app (and make reference to cases like starbucks while pointing out that even if they are ok on that there could be other issues) and offer to tell them the results of your testing (a written report) in exchange for your fee.
You haven't said you found anything in particular (and you haven't), haven't specifically said you've intruded and you can get paid for a security review which if written and done correctly will give the executive hiring you cover.
[1] Suggest postal letter rather than email but you could start by email I just think it will be ignored and that it's worth the stamp to get more attention.
[2] I've done similar things (not with security) and it's worked pretty well.
I don't get why not at least AES it.
With a static key? I mean, sure... but that's just obfuscation.
It goes like something like this:
1. Starbucks' server has the private key, the iPhone app
has the public key.
2. The app locks the plaintext up in AES with the public
key, local to the phone, and keeps the locked data,
and sends a copy to the server. The server has the
private key, and can unlock the data locked up with
the public key anytime, even though the app (in
possession of the public key only) cannot unlock the
data by itself.
3. The app needs network access to operate properly,
because honestly, why is Starbucks attempting to
transact without a network connection, so if there's
no network access and the protected data can't be
accessed, oh well. Oh, and by the way, if the app
really needs the plaintext, why not just ask the user?
Oh right, thinking is hard. Don't ask a lazy user to
do anything.
4. Each time the app needs to unlock the protected data
and use it locally, it sends a GET request to the
server via HTTPS. Maybe it sends XML, maybe it sends
JSON. Who cares, as long as it's not keeping and using
the plaintext.
5. Based on the nature of the request, the server decides
whether it needs to send the plain text back over
HTTPS, or whether the app is just asking the server to
do something server-side involving sensitive data. If
the app *REALLY* needs the locked data sent back in
plaintext, the server sends it back for one time use
via HTTPS (still protected from interception, even
though it's being sent over network), to be nulled out
after the process or function returns complete.
6. The server is a fortress, and has the private key
(...somewhere). It does not store the sensitive data
in plain text. It too only stores the locked data, but
is capable of unlocking the data on the fly, per
request, each request, every time. The server should
actively garbage collect the plaintext data, and not
leave stale copies lying around.
7. The server *NEVER* give an app a copy of the private
key. NEVER, EVER. The iPhone app can rot in hell if it
can't get the data unlocked. If it has to wait, it
waits. Find something else to do. Mine bitcoins,
unfold some proteins, whatever.
But hey, lazy users can't be bothered to type passwords and such. Gee whiz! Isn't this Starbucks app easy to use? How did they do that?
http://seclists.org/fulldisclosure/2014/Jan/64
The file in question is a log generated by the application. They are NSLog'ing stuff to the console, and Crashlytics must be capturing it up and putting it in this file. Along with debug tracing messages like this below, they're logging server interactions and JSON responses that contain personal information (I see my home address, telephone number, etc coming back from the server and being logged).
2539 $ -[CardDetailViewController refreshCardDetails:] line 798 $
2548 $ -[CardDetailImageViewController viewDidLoad] line 28 $ view did load
2551 $ -[CardDetailImageViewController viewWillAppear:] line 48 $ view will appear
2551 $ -[CardDetailImageViewController viewDidAppear:] line 53 $ view did appear
2588 $ -[CardDetailViewController refreshCardDetails:] line 798 $
2607 $ -[CardDetailViewController doPageChange:] line 684 $ :
2652 $ -[CardDetailViewController viewDidAppear:] line 301 $ I APPEARED!!
2652 $ -[StarbucksAppDelegate trackView:] line 1084 $ 2014-01-14 18:50:37 +0000 /Card/MyCard
2791 $ -[CardDetailViewController viewDidAppear:] line 301 $ I APPEARED!!
edit: This also means that all that personal information of mine is presumably on some Crashlytics host as a side effect of all this having been logged and sucked up by Crashlytics.
Earlier quoted context omitted.
With a static key? I mean, sure... but that's just obfuscation.
Not really. It goes like something like this: 1. Starbucks' server has the private key, the iPhone app has the public key. 2. The app locks the plaintext up in AES with the public key, local to the phone, and keeps the locked data, and sends a copy to the server. The server has the private key, and can unlock the data locked up with the public key anytime, even though the app (in possession of the public key only) ca…
Sounds like a complicated way of saying "don't store anything on the phone and remember a token instead of the password"
Earlier quoted context omitted.
There are tons of "developers" out there that don't know much about security or really care about it. This is especially true in the mobile space where anyone that has published a Hello World app to the app store can get a job working as a contractor. This makes me think though that there could be some good money to be made by opening every single app like this to check it's security then offering services to said co…
" Of course the way the world works today; instead of taking me up on the help they would probably just contact the police." Ok so try it this way. Contact the company [1] [2] and tell them you believe there might be security holes in their app (and make reference to cases like starbucks while pointing out that even if they are ok on that there could be other issues) and offer to tell them the results of your testing…