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

Starbucks caught storing mobile passwords in clear text

computerworld.com

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Starbucks caught storing mobile passwords in clear text

#21

Post by jessaustin »

nly wrote: post #15

Every single app on your phone that remembers a username and password combination, or any other credential, is likely vulnerable. Imho its about time that Google required the presence of a HSM in Android devices for key storage. A HSM that locked me out after ~10 x 6 digit PIN guesses (with software locking me out at a lower number) strikes me as a good thing. If someone wants to destroy my $500 phone, prise out a ch…

A HSM that locked me out after ~10 x 6 digit PIN guesses...

And now you've got a DOS enforced by hardware. Hopefully if I bring it back to the store I can get it reset? The existence of this reset sort of negates the point of an HSM.

However, I could see the point of an Android module that, rather than locking the user out, would simply delete keys the password to which had been entered incorrectly a configurable number of times. For an app like this, the user would simply have to enter a password and CC again.

Re: Starbucks caught storing mobile passwords in clear text

#22

Post by prolifically »

ZoFreX wrote: post #16

> Starbucks could have chosen not to store the password on the phone, but users would then be forced to key in their username and password every time they wanted to use the app to make a purchase. These aren't the only two options. Storing a token would let users remain logged in without having the same security implications as storing the password. Some advantages of a token vs a password: 1. Lots of users use the s…

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.

Re: Starbucks caught storing mobile passwords in clear text

#23

Post by bigtunacan »

I LOL'ed so big just reading the headline. It is absolutely terrible, but I have seen this before with big companies that should know better. About 6 years ago I was working on a project for The Wall Street Journal (yeah; that WSJ) in which all customer data was being stored in the DB in plain text then exported nightly to an Excel report and emailed unencrypted to client managers so they could review daily sales.

On numerous occasions I told them that was extremely risky and that we were violating PCI compliance and opening the companies to huge potential fines in addition to just putting customers information at risk.

Every time I brought this up I was told there wasn't time to fix the application and that the client managers thought it was too difficult to deal with encrypted files so just leave everything the way it was.

Eventually they got busted on a PCI compliance audit and started using PGP to encrypt the files sent via email; but by the time I left they still were not encrypting the backend data or actually maintaining PCI compliance. Extremely sad; but this happens all the time.

Re: Starbucks caught storing mobile passwords in clear text

#24

Post by [deleted] »

eli wrote: post #8

Storing a token isn't really much more secure than storing the password itself. (If I steal your token, I'm buying coffee with your account even though I don't know your password. A token that authenticates account access is a password.) But it seems much more secure (which, it turns out, matters) and it does somewhat protect people who reuse the same password everywhere.

[deleted]

Re: Starbucks caught storing mobile passwords in clear text

#25

Post by jessaustin »

ctdonath wrote: post #18
jessaustin wrote: post #10

Only when adding money to the app is the password required. This seems precisely backwards.

"Adding money" means applying a credit card to purchase Starbucks credit, usually by a sequence like "Reload card -> $25 -> Confirm" on a pre-stored credit card number. Buying from the app has a small cash pool to draw from; reloading from a CC can get one a whole lot more money.

I'm not a Starbucks regular so I may have missed a detail. Transferring money from a stored bank account to the app seems to be a server action, so the server should be doing the auth. What then is the point of storing the password on the client? If it's just to confirm possession of the phone, a token would be better for usability, as well as in all the other ways a token is superior to a password. TFA says the password is also used to activate the app, but a token signed with a timestamp and emailed to the user would be better for that.

Re: Starbucks caught storing mobile passwords in clear text

#26

Post by bigtunacan »

prolifically wrote: post #22
ZoFreX wrote: post #16

> Starbucks could have chosen not to store the password on the phone, but users would then be forced to key in their username and password every time they wanted to use the app to make a purchase. These aren't the only two options. Storing a token would let users remain logged in without having the same security implications as storing the password. Some advantages of a token vs a password: 1. Lots of users use the s…

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 company to secure their application. Of course the way the world works today; instead of taking me up on the help they would probably just contact the police.

Re: Starbucks caught storing mobile passwords in clear text

#27

Post by jader201 »

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 identical, was just curious how the HN logic works when submitting duplicate URLs like that. Is it that too much time had passed, considering them "different" submissions?

[1] https://news.ycombinator.com/item?id=7068298

Re: Starbucks caught storing mobile passwords in clear text

#28

Post by jessaustin »

brudgers wrote: post #5

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

Re: Starbucks caught storing mobile passwords in clear text

#29

Post by prolifically »

bigtunacan wrote: post #26
prolifically wrote: post #22

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…

Well said. I think the deceiving part is the compiling/sandboxing environment phones have. New developer don't really know what's happening when they hit the 'Build & Run' so they can't understand that the key value they are storing are in plain text somewhere in the phone easily extractable.

Re: Starbucks caught storing mobile passwords in clear text

#30

Post by nly »

jessaustin wrote: post #21
nly wrote: post #15

Every single app on your phone that remembers a username and password combination, or any other credential, is likely vulnerable. Imho its about time that Google required the presence of a HSM in Android devices for key storage. A HSM that locked me out after ~10 x 6 digit PIN guesses (with software locking me out at a lower number) strikes me as a good thing. If someone wants to destroy my $500 phone, prise out a ch…

A HSM that locked me out after ~10 x 6 digit PIN guesses... And now you've got a DOS enforced by hardware. Hopefully if I bring it back to the store I can get it reset? The existence of this reset sort of negates the point of an HSM. However, I could see the point of an Android module that, rather than locking the user out, would simply delete keys the password to which had been entered incorrectly a configurable num…

Yes, a reset/unlock is a bad idea. Keys should be erased, and it should be up to apps/services to determine an appropriate means to re-authenticate users.
Post reply on HN