Hacker News Reader

Comment by NathanKP | Hacker News Reader

I'm trying to imagine what line of thought led to this "authentication" scheme. Surely someone along the way must have realized that this was a terrible idea?

View on HN

Right? I'm also curious about the fix. The vulnerability he describes is most obviously that they fail to associate the token you get after login with an actual account, so you can re-use that token to bind an arbitrary account, but binding to a device ID is also problematic, because that information isn't inherently private. Another app could harvest it and be compromised which then leaks the info, or it could be exposed in some other way because it's not unique to their application.

One possible fix would be to only allow an account to bind to a device ID if that device ID wasn't already linked to another account. This would prevent you from just fishing through their info by linking your account to random device ID's.

You'd have to know the email address associated with the account, but that of course means you are using the device ID as the username and the email address as the "password", which is still pretty bad in my opinion.

If they're going to insist on binding ID to account, it seems like the simplest way to do it would be just to submit the ID as an additional parameter in the login POST request and associate it as a single transaction, but again, using the ID at all is problematic.

I think the best solution is to not trust the client in assigning the perfectFitId. The login POST should be able to determine the perfectFitId for the user after login and maintain a session through oauth or other session management process.

Reply on news.ycombinator.com