with bad password, succesfull login

[pochy-ja]

This is my use case, when you login succesfully for the first time, next time you can put a bad password and the login succesfully again! WTF?, by the way, the checkbox "remember password" not checked.

Pidgin 2.10.9
Ubuntu 14.04
Plugin - last version of ppa (purple-facebook/unknown 0.0+20150720+6bb0e31+565fbae05259 amd64)

[jgeboski]

It only uses session information after after the first login, never the password. This is normal behavior.

[erlis]

For me, it's ridiculous this bug was closed because this is "normal behavior". No is not, it doesn't matter if you use token authentication or username/password to authenticate. We have a checkbox for remember password. When the application opens you can verify if the checkbox is checked if so, then keep doing whatever you are doing, I agree that's normal behavior with the checkbox checked. But when the checkbox is not checked, you see? Two scenarios, should not be same, you should invalidate the authentication token and ask for another one.

There are valid reasons why someone wants to do this, and it doesn't matter if the authentication takes longer, the reasons behind will outweigh this "login takes longer".

Some people might share computers, and this is a huge "no, no".

Please reopen this bug and do something about it. This should not be "normal behavior"

Regards,
Erlis

[dequis]

It's not as simple as "login takes longer". I don't know if there's a way to force password based reauthentication without appearing like a new device to facebook on every login, which resets the rest of the session information, like the message queue.

Referencing #193 #216 #260

[jkufner]

It should not be on every login. Only when password is changed (user changes it in transport settings), then reauthenticate.

[rodneyrod]

@dequis Wouldn't it be possible to implement some sort of local password on the account client side?
e.g. The token is still stored, but the user has to put in a password every time in their client so the token is unlocked.

Is such a setup possible?

[dequis]

@rodneyrod Uh, not really.

This is just a libpurple protocol plugin, we have very little control over what the client (the UI) decides to do with the passwords.

[rodneyrod]

So I guess that one solution would be to change the store of these tokens to some sort of temp file at compile time, or setup a script that automatically deletes those files at a set event e.g. restart, pidgin closing, not the best solution but probably the only one I can think of.

[cipri-tom]

I agree it is unexpected and a major concern. Unfortunately, there's very little to be done on this side.

The way I think about it is that the plugin basically is a reverse engineering of the Messenger protocol. When's the last time you signed out of Messenger out of your phone?
So on one side, Facebook encourages the "session token" (no password) way.
And on another side, Pidgin (or other UI) doesn't take care to protect that token.

This would be better addressed at Pidgin or what client we use, as this plugin has to follow their protocols.

Again, I understand the concern, but let's focus our efforts at the root cause.