Starbucks caught storing mobile passwords in clear text • Hacker News Board

Re: Starbucks caught storing mobile passwords in clear text

#51

Post by rwl4 » Thu, Jan 16, 2014, 7:17 PM UTC

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…

This is the direction I steer all my customers these days. Then in the user's account screen I let the user see a list of their device authorizations and they can individually delete those... I really think tokens are the way to go in nearly every case.

Re: Starbucks caught storing mobile passwords in clear text

#52

Post by wdewind » Thu, Jan 16, 2014, 7:37 PM UTC

bigtunacan wrote: post #50

wdewind wrote: post #46

Earlier quoted context omitted.

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

I understand it's not extortion. You'll note I never said it was extortion.

I also understand how it protects the reporter.

I'm not asking the reporter to take responsibility or do anything that would harm them, I'm asking them not to essentially make the sales pitch of "look at how your neighbor had something bad happen to them, you wouldn't want something similar to happen to you now would you?"

Re: Starbucks caught storing mobile passwords in clear text

#53

Post by eli » Thu, Jan 16, 2014, 8:44 PM UTC

curmudgeoned wrote: post #42

eli wrote: post #39

Earlier quoted context omitted.

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

You appear to be punting on the process where the app proves to the server that it is authorized to make a request. That's.... kinda the whole point.

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

Come again?

Re: Starbucks caught storing mobile passwords in clear text

#54

Post by ZoFreX » Fri, Jan 17, 2014, 2:27 PM UTC

Almaviva wrote: post #47

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…

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

Morally yes you are correct (imo). But which product are users going to go for - the one that goes the extra mile to keep them safe and help them out, or the one that doesn't give a damn about them? We have to deal with reality, not ideals, and the reality is that most people do not practice good password management.

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

Which is just as possible with tokens as it is with passwords. There is no reason not to use tokens.