Live data from Hacker News

Starbucks caught storing mobile passwords in clear text

computerworld.com

41–50 of 54 posts

Re: Starbucks caught storing mobile passwords in clear text

#41
post #40
post #36

Earlier quoted context omitted.

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

This sounds almost like extortion. I would not suggest doing this with security.

It's not extortion.

And it's done quite frequently by home security companies whenever there is a burglary in a particular area. "You're neighbor just had a burlary and you might be vulnerable as well!"

And the wording can be altered to suit one's taste or level of comfort.

Of course you can blaze a large "this is a solicitation across it" but I would suggest that if you aren't willing to push the envelope with marketing you are going to not make out as well. This is based on my many years of experience doing similar things. Business involves taking and assessing risks and rewards. (Everyone's level of comfort or ability to do this differs of course).

And it's not the same (nor was I suggesting) that you say to someone "hey I found a hole in your app and if you don't pay me I will publish the results of the security hole". Details matter.

By the way saying to a homeowner "I saw you have a few windows at your house that appear to be broken (that would allow entry!) and I'll tell you the broken windows if you pay me $50" is not extortion. Anymore than saying "You have an outdated HVAC and for $100 I will give you a proposal on the best system to replace it with".

Re: Starbucks caught storing mobile passwords in clear text

#42
post #39

Earlier quoted context omitted.

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…

I didn't really follow that. Doesn't that still leave a token (the encrypted password that is sent with each request) that I can steal from your phone and use to log in to your account and impersonate you? Sounds like a complicated way of saying "don't store anything on the phone and remember a token instead of the password"

EDIT: As drdaeman pointed out, none of what I'm describing is AES. I am describing something completely different. I am describing public key cryptography, which is completely different from AES.

...but if you still want to know about asymetric public key cryptography, read on, but ignore any references to AES, because it isn't AES at all.

...

Well, this is just one layer in a hypothetical system comprised of many layers.

This one layer just handles storing secure data in a way that the app itself cannot understand.

The iPhone app needs to be authorized to make privileged requests to the server. This would be another multi-step process of performing a handshake with the server.

The server must not unlock anything for any client request, unless the client-side user agent proves that it's really a member of the secure system. This is the part where "the server is a fortress"

So this exchange of sensitive data would need to occur within the scope of a handshake process, such that the server challenges the app to prove it's authenticity. Something like this might also involve a third party verification from Apple & perhaps even the service provider that the app is not running on a jailbroken iPhone, a reportedly stolen iPhone, or some nefarious evil-doer's laptop.

THEORETICALLY (emphasis mine) once you encrypt data with AES, it is not merely a "token" that could be substituted for something else. It is an otherwise impenetrable object, and you can't just use the "token" itself. The token needs to be transformed into the usable data before it may be used.

For example, the stored data is:

  0x01B926A340F0CCC67238DD00
That data is not a password. But. A valid app that is permitted to interact with the Starbucks server can send that string over to the server, and the server will send the tranformed data back in a secure manner. The server will send to the app:

   "H3ll0_this_1$_a_p@ssw0rd"
The app is responsible for the plaintext version of the data and MUST destroy the data after use, and never save it.

The app has a PUBLIC KEY ONLY. That thing cannot unlock the data. the PUBLIC KEY cannot transform that hexadecimal string data back to the password. The app can create the impenetrable object but not unmake it.

The server, on the other hand, HAS THE SPECIAL PRIVATE KEY. The private key is The Spice. He who controls The Spice controls the universe. The private key is the only thing with the power to transform that hexadecimal string back to the real token. If something has the power to ask the server to perform the transformation, then it gets the information. The server has the responsibility of never letting the private key fall into the wrong hands, and never transforming data without properly challenging the client's authority to dare ask for sensitive data.

Re: Starbucks caught storing mobile passwords in clear text

#43
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…

"... a datum ain't worth much to anyone other than the PI my wife hired to find out if I'm sleeping around or an attractive lab technician in CSI: Miami." 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.

[deleted]

Re: Starbucks caught storing mobile passwords in clear text

#44
post #9

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…

> AES with the public key

I beg pardon, but this part is a nonsense because AES is a symmetric cipher.

And even if you use public-key crypto, the schema's not better than old plain OAuth 2 tokens (or alikes). Actually, it's worse because of unnecessary complexity and because, as opposed to encrypted password, OAuth token has no relation to password at all.

Lose the encrypted key and until you change the password or revoke phone's key (so encrypted key would be unusable) you're not secure. Same with a token except that you don't have to change the password, just revoke a token.

Re: Starbucks caught storing mobile passwords in clear text

#45

Earlier quoted context omitted.

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…

> AES with the public key I beg pardon, but this part is a nonsense because AES is a symmetric cipher. And even if you use public-key crypto, the schema's not better than old plain OAuth 2 tokens (or alikes). Actually, it's worse because of unnecessary complexity and because, as opposed to encrypted password, OAuth token has no relation to password at all. Lose the encrypted key and until you change the password or r…

Whoops! Looks like your right... AES doesn't use public key exchange, and public/private key pair generation at all! I was entirely confusing it with other completely different things.

Ha ha! Sorry...

Re: Starbucks caught storing mobile passwords in clear text

#46
post #41
post #40

Earlier quoted context omitted.

This sounds almost like extortion. I would not suggest doing this with security.

It's not extortion. And it's done quite frequently by home security companies whenever there is a burglary in a particular area. "You're neighbor just had a burlary and you might be vulnerable as well!" And the wording can be altered to suit one's taste or level of comfort. Of course you can blaze a large "this is a solicitation across it" but I would suggest that if you aren't willing to push the envelope with marke…

Yeah, you're right, it's not extortion. That's why I said it's almost extortion. It's certainly pretty tasteless. It is a tactic used by extortioners, and I wouldn't consider doing business with someone who applied that tactic.

Re: Starbucks caught storing mobile passwords in clear text

#47
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…

> 1. Lots of users use the same password on multiple sites

I'd never say this at a job interview but I'll be Devil's advocate: As a business, this isn't my problem, it's yours. If you want the convenience of the same password for multiple sites, in the real world there are going to be weak points on some of those sites and someone who can abuse any point of the chain on any site can obtain your password for all.

For the rest, expecting to change my passwords if my phone is stolen is not an unreasonable thing at all. I should do this anyway, even if businesses ensure me that I don't have to.

And 99% of users who aren't IT or security professionals would just prefer to be done with entering their password after the first time, period.

Re: Starbucks caught storing mobile passwords in clear text

#48
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…

> 1. Lots of users use the same password on multiple sites I'd never say this at a job interview but I'll be Devil's advocate: As a business, this isn't my problem, it's yours. If you want the convenience of the same password for multiple sites, in the real world there are going to be weak points on some of those sites and someone who can abuse any point of the chain on any site can obtain your password for all. For…

> I'd never say this at a job interview but I'll be Devil's advocate: As a business, this isn't my problem, it's yours.

This argument is the same as saying "It's not my fault you're being spied on because you're not using OTR in your IM; it's yours." You're technically right that the user could theoretically avoid this problem, but you're wrong in practice since you're setting impossible expectations that even security-conscious people often don't meet.

It's a service provider's responsibility to not let user credentials be easily accessible because those credentials are used in many places. The latter is a more fundamental issue, yes, but you deserve the flak you get if you just say "not my problem."

Re: Starbucks caught storing mobile passwords in clear text

#49
post #46
post #41

Earlier quoted context omitted.

It's not extortion. And it's done quite frequently by home security companies whenever there is a burglary in a particular area. "You're neighbor just had a burlary and you might be vulnerable as well!" And the wording can be altered to suit one's taste or level of comfort. Of course you can blaze a large "this is a solicitation across it" but I would suggest that if you aren't willing to push the envelope with marke…

Yeah, you're right, it's not extortion. That's why I said it's almost extortion. It's certainly pretty tasteless. It is a tactic used by extortioners, and I wouldn't consider doing business with someone who applied that tactic.

"It's certainly pretty tasteless."

While debatable (depends on execution) whether it is tasteless to make money you sometimes have to get over that.

"I wouldn't consider doing business with someone who applied that tactic."

The person doing the sending isn't looking to close 100% of the people he mails to. Nor does he care what the recipient thinks. If you worry about that you will potentially miss a business opportunity.

Look think of it like using a cheezy line in a bar. Something that I've never done but I recognize that it works for some people and gets them dates. In the end approaching 100 women with a line will work better than staying home and doing nothing (assumes you can take the rejection of course).

Re: Starbucks caught storing mobile passwords in clear text

#50
post #46
post #41

Earlier quoted context omitted.

It's not extortion. And it's done quite frequently by home security companies whenever there is a burglary in a particular area. "You're neighbor just had a burlary and you might be vulnerable as well!" And the wording can be altered to suit one's taste or level of comfort. Of course you can blaze a large "this is a solicitation across it" but I would suggest that if you aren't willing to push the envelope with marke…

Yeah, you're right, it's not extortion. That's why I said it's almost extortion. It's certainly pretty tasteless. It is a tactic used by extortioners, and I wouldn't consider doing business with someone who applied that tactic.

I would not agree that this is extortion. I would consider it to be more self-protection. If you have no intention of misuse or public release of the security flaw to the public; you are offering a no harm approach while offering a valuable service. The unfortunate situation is that the business in question does not value the service even though they should.

Most competent programmers do not have time to just go around and fix every security flaw pro bono either.

Post reply on HN