The password for the account is in the file “C:\Users% USER%\ AppData\Roaming\eM Client\accounts.dat” in pure text ! The same also in backup “C:\Users%user%\Documents\eM Client\backup*.zip”. It is a big security flaw
I agree.
Confirmed here. That’s very grim. Considering the bazillion articles about this problem having been discovered repeatedly in the last “x” years on various web sites or in various programs, in my opinion there’s no excuse for it.
I filed a support ticket about this and have also written email to the company about it.
Interestingly, I have 5 accounts (all gmail) and I only see password information for one of the accounts. I also would have assumed that with gmail’s 0Auth, there would be no need to store passwords as that info is entered directly into a gmail window.
Same here !
This issue has been reported long time ago already. I wonder why such an critical bug wasn’t fixed by now …
Messy, but I fixed this issue by encrypting the folder containing eM Client databases.
I used the free VeraCrypt and just used folder level encryption. My eM Client database is now on Z: drive. I just have to ensure that the drive is “mounted” by VeraCrypt before I start eM Client.
You can set the volume as a favorite and get it to automatically mount on login.
You have to turn backups off in eM Client as well, unless you also encrypt that folder. I create my own backup using password protected zip file (7-zip)
Support usually responds quickly to tickets filed by paid users. This time, no response (yet). I don’t mind turning backups off — I haven’t found them working anyway. Invariably I’ll have eM Client running at a time when it wants to do a backup. It tells me it cannot make the backup because the program is running. I close the program…and no backup occurs. I can run a manual backup while the program is running, though. If it can’t run a scheduled backup when the program is running, why can it run a non-scheduled/manually launched backup when the program is running? At any rate, the scheduled-backup system seems hit and miss at best (and mostly “miss” — it hasn’t successfully run a scheduled backup since September 19).
That’s a good point about using 7-zip. I wrote a script that unpacks the .zip file created by the backup and then re-archives it in .7z format (compression level “-mx7”). The resulting .7z file is a whole lot smaller.
How about using Windows EFS? (only available on the “pro”-Versions of Windows…)
(https://en.wikipedia.org/wiki/Encrypting_File_System)
Sure, its not bulletproof and relies on the Windows-Account-Password… but perhaps as a first step.
Since en- and de-cryption is done by the file-system it should be transparent to any application…
perhaps just encrypt the file with the passwords? to avoid performance-issues?
who dares to try?
Fritz
there is more:
the Mail-Database is also plain-Text.
(perhaps all Data-Files of eM-Client are)
I used a (portable) Tool called “DB Browser for SQLite”:
zoom of the bottom-right corner:
well… perhaps it is a good idea to either put the eM-Client Data-Files
into an encrypted container or use something like EFS to encrypt
the whole eM-Client-Data-Folder…
Fritz
I use Windows 10 Home on one computer so no EFS is available. I prefer the container method anyway because:
- I can control when the eM Client data are available (eg if a technician was accessing the computer)
- I can access the data from different Windows accounts, different computers
- Once my container is “mounted”, I can easily create encrypted backup files on my USB disk using 7-zip
My eM Client Storage location is set to z: All I have to do is at Windows Logon, enter a password at a prompt from VeraCrypt, prior to starting eM Client. Then my “eMClient (Z:)” drive appears and I can start eM Client.
If eM Client is started before drive z: is available, it complains that it can’t find the database location and starts with no accounts, no data. Also, since the decrypted data are only held in RAM as required, if there is a power failure any decrypted data disappear.
Of course the container has to be large enough for future expansion of the eM Client database. I set mine to 4 times the current size.
Hi John,
In case you replied to my post:
There is nothing wrong about the Container-Solution…
I just pointed out, that - since all Data-Files of eM-Client seem to be plain-Text - it might be a good idea to find a solution not just for that one File which contains the passwords.
Your solution is the Container-Approach… good thing, if it works for you 
Fritz
Hi Fritz
Yes all my emClient files are in the container. Hopefully this discussion will help others concerned about security.
John
Hello,
encrypting your windows profile has been a suggested solution for now.
The passwords will be separately encrypted in version 7.1.
Regards,
Olivia
That’s good to know.
Hello Olivia,
when is version 7.1 scheduled?
Clear text password information is a huge security flaw and since three months nothing has happend so far.
Kind regards,
Alexander
Hello Alexander,
as I mentioned, it is currently advised to encrypt your user profile.
Version 7.1 is in alpha testing and the release date is not set yet.
This version will include new features so it needs to be properly tested before its release.
Thank you for understanding.