Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

simultaneous logins vulnerable to account correlation - each tab needs login control #121

Closed
ghost opened this issue Mar 25, 2019 · 12 comments

Comments

Projects
None yet
2 participants
@ghost
Copy link

commented Mar 25, 2019

Launching ElectronMail causes all accounts to be simultaneously logged in. The login timings would create a pattern that makes it trivially easy to correlate the identities. Issue #113 is only partially solved by stream isolation.

The workaround is quite ugly. Since the settings directory is hard-coded, one must have a separate settings directory for each account and then have a script that links $HOME/.config/electron-mail to the relevant directory before each login of one account, also taking care that only one instance runs at a time.

The fix is to offer a setting whereby all tabs are logged-out when EM is launched, and that they only login when the tab is clicked.

@vladimiry

This comment has been minimized.

Copy link
Owner

commented Mar 25, 2019

Adding two new options to each account makes sense to me (options are hidden in collapsed by default "advanced block"):

  • auto-login on selection (tab is clicked), defaults to false.
  • auto-login dealy in seconds, no delay by default.

Will such improvement be sufficient?

@ghost

This comment has been minimized.

Copy link
Author

commented Mar 25, 2019

yes that's good.

I would one day hope to use fetchmail and an MUA like mutt to unjail content from the GUI so all email can be accessed together and so retrievals can be scripted to be at different times. I suppose that's well outside the scope of the project at this point. But i mention it because one trigger for logging in could involve having an integrated pop3 server that listens and performs an on demand login for whatever account a pop3 client asks for it. Maybe that's crazy talk.

Anyway, for now the options you mention would be great. Thanks!

@ghost

This comment has been minimized.

Copy link
Author

commented Mar 25, 2019

I just realized a fixed delay would be security by obscurity. But if the delay option were a range of time from which the app would randomly select a delay, that would be ideal. Perhaps the app could use a fixed delay if the field is an integer, and if the field contains a hyphen (e.g. 90-1900) then it could make a random selection.

@vladimiry

This comment has been minimized.

Copy link
Owner

commented Mar 28, 2019

@libBletchley can you try the auto-login delay feature enabled with the pre 3.1.0 build uploaded here? I will release a new version if the delay thing works as expected. See feature description below.

Support auto-login delay (#121, a2aba08, 75a7aa0). Two options have been added to the account editing form (hidden inside the collapsed by default advanced block):

  • Login delay range (seconds). Here you can specify the delay time range in seconds, like 15-60. The app will then delay the auto-login process with randomly generated value limited by the specified range.
  • Login on account selection. This option delays the auto-login process until an explicit account selection by a user.

So the auto-login delay scenario is based on either time range or account selection triggers. Whichever kicks in first if both values defined.

delay

@vladimiry

This comment has been minimized.

Copy link
Owner

commented Mar 28, 2019

#113 (comment)

That's why a randomized & delayed connection or something similar would be greatly appreciated as a future feature of Electronmail (@vladimiry)

@nil0x42 you also were interested in this feature, see the link to a build in the previous message.

@ghost

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

thank you!

The two tests I did worked. I did 2 launches with login on account selection off on 2 accounts. All 4 login times triggered at the top of the range. That's not very random but it's a also very small sample size. I'll have to do more tests.

One thought is that although users should expect to be waiting, they don't necessarily know if the app is hung or if it's running a timer. So it might be useful to show a timer in the tab so first-time users don't get anxious. Or even some "zzZZ"s on top of the closed padlock just to indicate that it's sleeping until trigger time would be useful. It's not important.. just trying to give meticulous feedback.

Now I feel comfortable merging my profiles into one.

@ghost

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

At first I thought it was weird that enabling both login on account selection and also using a timer would be based on the first of the two to trigger. But after more thought I think it's a good idea. You can set some really long timers and then use the tab to pre-empt the timer for instant access.

@ghost

This comment has been minimized.

Copy link
Author

commented Mar 28, 2019

One pitfall to consider: what about logout? If accounts are logged out simultaneously, it's the same vulnerability. If I have accounts logged in and I choose to quit the app (without choosing logout), does EM go signal to the server to invalidate the cookie, or does it just close the session silently and the cookies are left to expire?

The latter case is safer. And I further wonder if the server would still detect simultaneously dropped connections. It probably wouldn't log it, but still worth considering.

@nil0x42

This comment has been minimized.

Copy link

commented Mar 29, 2019

One pitfall to consider: what about logout? If accounts are logged out simultaneously, it's the same vulnerability. If I have accounts logged in and I choose to quit the app (without choosing logout), does EM go signal to the server to invalidate the cookie, or does it just close the session silently and the cookies are left to expire?

The latter case is safer. And I further wonder if the server would still detect simultaneously dropped connections. It probably wouldn't log it, but still worth considering.

Indeed, to adress this issue, a workaround would be to have each account have a random connection/disconnection cycle, in order to have feedbacks about all unread messages, while never being simultaneously connected to all accounts (statistically).

Pseudo-Code Example:

def run_thread(acct):
    while True:
        random_sleep(0, 1200)
        async_connect(account)
        random_sleep(240, 1200)
        async_disconnect(account)

for acct in account_list:
    run_thread(acct)

Of course it's a little more tricky in real life, as a good user experience would require a clicked account to
instantly call async_connect() without breaking general behavior

@vladimiry

This comment has been minimized.

Copy link
Owner

commented Mar 29, 2019

That's not very random but it's a also very small sample size. I'll have to do more tests.

Such function is used to pick random value form a range, you can play with it in browser's dev console:

function getRandomInt(min, max) {
    min = Math.ceil(min);
    max = Math.floor(max);
    return min + Math.floor(Math.random() * (max - min));
}

So it might be useful to show a timer in the tab so first-time users don't get anxious.

There are two types of triggers, account selection and timer based. So ideal indication would require introducing two states. One is just a static icon for account selection trigger got setup and another would be counting down timer. This would be more complex to implement than using unified static indication for all the cases. I tend to enable unified static indication for both cases, so just icon or zzZZ-like text.

One pitfall to consider: what about logout? If accounts are logged out simultaneously, it's the same vulnerability. If I have accounts logged in and I choose to quit the app (without choosing logout), does EM go signal to the server to invalidate the cookie, or does it just close the session silently and the cookies are left to expire?

There is no custom code in the app that would be sending any signals to the server to invalidate the cookie.

random connection/disconnection cycle

Network emulation seems to be supported per session https://electronjs.org/docs/api/session#sesenablenetworkemulationoptions including the offline state. Since the app now uses a separate session for the account it would, in theory, be possible to enable random connection/disconnection cycle per account. But it would be outside of this issue, so I suggest opening a new one if further discussion expected.

@vladimiry

This comment has been minimized.

Copy link
Owner

commented Mar 29, 2019

One thought is that although users should expect to be waiting, they don't necessarily know if the app is hung or if it's running a timer. So it might be useful to show a timer in the tab so first-time users don't get anxious.

A release build with enabled indication for both delay options is being prepared (hand icon and countdown timer).

indication

@vladimiry

This comment has been minimized.

Copy link
Owner

commented Mar 29, 2019

v3.1.0 has been released, closing as resolved.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.