Jump to content

2 people logged in with same acc, how to remove 1 of them?


Cosmic

Recommended Posts

one of my users inadvertently revealed his password, and now one of his friends is logged in and is posting as him.

He's tried changing his password, but the password change appears to be getting passed across to his friend's session, as the friend remains logged in. I've just tried replicating that with a dummy account and two different browsers, and yep, if the password is changed in one browser the other browser stays logged in.

Is there some method I can use to log out all instances of that user before I change their password? Or another method I can use to remove the 'friend' from having access to his account?

Link to comment
Share on other sites

3 minutes ago, dancingbear said:

because the 'friend' user would remain logged in, and if their IP changes they'll have access again.

It's not a secure solution.

Should work as once the member is offline then change the real members password in admincp and send real member the password (via email not PM) ... they can then log in and change the password to one of their choice then should be able to unban the IP

Link to comment
Share on other sites

1 minute ago, steve00 said:

Should work as once the member is offline then change the real members password in admincp and send real member the password (via email not PM) ... they can then log in and change the password to one of their choice then should be able to unban the IP

that's only good if the 'friend' user goes offline, and I have some way of knowing that they have. They're deliberately not going offline so they can stay logged in.

You're not saying anything I've not thought of myself, but the problem is it's not a guaranteed solution. I need something that's guaranteed to work.

Link to comment
Share on other sites

4 minutes ago, Daniel F said:

You could log out all users from your ACP ( ACP => System => Login Handlers ; there you'll find a "log out all users" button ) or you could also delete only his session from your core_sessions table.

I'm not going to be logging everyone out. Using nuclear weapons against a bank robbery isn't anything the sane world does. ;)

The sessions table isn't showing any instance of that user logged in, so I've just changed the user password in ACP and hopefully that's locked out the 'friend'. Thanks for that suggestion, and my fingers are firmly crossed.

 

4 minutes ago, Daniel F said:

But this should really not happen.

But it does because....? That's how your company have designed the login system. ;)

Link to comment
Share on other sites

18 minutes ago, dancingbear said:

I'm not going to be logging everyone out. Using nuclear weapons against a bank robbery isn't anything the sane world does. ;)

Honestly I don't think it would bother any of your community to sign back in. 

We are not talking about nucular warheads governor. And after logging everyone out which would call for the session table to be cleaned up and then needs session cookies to be reestablished. 

Why not have the affected end user manually request a pw reset? Unless his friend also has access to his email. So essentially the whole thing is his security fault and he would need to change all his passwords.

Link to comment
Share on other sites

13 minutes ago, MADMAN32395 said:

So essentially the whole thing is his security fault

yep.

But it's become an IPB issue, because IPB shares the password across different sessions.

13 minutes ago, MADMAN32395 said:

Why not have the affected end user manually request a pw reset? Unless his friend also has access to his email.

his 'friend' doesn't now have access to his email (because his mail password isn't shared across sessions), but it's naff-all use for the user to do anything with reseting his own IPB password - because the password is shared across sessions.

Link to comment
Share on other sites

1 minute ago, dancingbear said:

yep.

But it's become an IPB issue, because IPB shares the password across different sessions.

his 'friend' doesn't now have access to his email (because his mail password isn't shared across sessions), but it's naff-all use for the user to do anything with reseting his own IPB password - because the password is shared across sessions.

I think you got confused. I'm signed in both on my phone and 2 computers on my site and IPS. If I change my password eventually one will catch up as well if not immediate. It also works with php garbage collection. That's why he suggested logging all users out to clear out sessions.

Link to comment
Share on other sites

13 minutes ago, MADMAN32395 said:

Just log out all users.

or alternatively, IPB should have a way of logging out just the affected user.

You might as well be saying "turn it off and back on again". I thought the IT world moved on from that about 20 years ago ... it certainly did where I worked. ;)

Link to comment
Share on other sites

1. Submit a bug report

2. Ban the member who acquired the password and is "deliberately not going off-line so they can stay logged in". Enough is enough...

3. Log out all users as suggested (ACP ( ACP => System => Login Handlers ). I agree that nuclear weapons would be overkill but logging all people out to prevent a bank robbery is more than appropriate: your members would thank you once you notified them of a possible security breach.

4. Change the password of the owner of the bank who got robbed.

5. Go have a beer - preferably a rich dark malt to celebrate the stopping of a bank robbery.

Link to comment
Share on other sites

1 hour ago, Daniel F said:

While working on this ticket, i have noticed that we have improved this already for 4.1.9 so that the login_key will be reset once somebody changes his password

yep - as you've told me in the support email you've just sent me.

So it's clearly an identified system issue, even tho the cause of me raising it is a numptie user.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...