Hacker News new | past | comments | ask | show | jobs | submit login

> You're thinking in an extremely binary and absolutist fashion. Systems have lots of failure modes.

You seem to be thinking of applications as if they were web sites.

> After compromise, the first thing is the "smash and grab" where you loot as many credentials as possible off the machine with a bunch of scripts. If there's stuff in a browser's built-in password manager, win. If your app stores a password, win.

So they smash and grab the keychain, which holds the master passwords to the services granting OAuth tokens.

You might have me vaguely convinced if you were advocating for XAuth+OAuth, in which case it would provide a bare modicum of additional security without negatively impacting user-experience at all.




Thanks!

I hadn't run into xAuth before. It looks like a reasonable way to make the grant process not such a Desktop UI cluster$%$^ - which I totally agree that it is.

Re: the keychain thing, again, it depends on the level of compromise, whether the machine is unlocked, what platform you're on and whether the creds are in there.

And yes, with enough access you can keylog, man-in-the-browser or "desktop phish", but it's higher risk for the attacker and requires maintaining longer-term access.

But if your app stores passwords the user instantly loses.

Failure modes matter. A kind of parody version of how I see your argument is: "Sites shouldn't bother hashing passwords, because an attacker with a shell could just modify the site's login process to capture passwords".




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: