simultaneous logins vulnerable to account correlation - each tab needs login control
opened this issue · comments
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.
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?
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!
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.
@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.
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.
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.
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.
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.
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
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.
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).
v3.1.0 has been released, closing as resolved.