ATIH's mapped network drive handling (including security leak)
The other day, I chose to change my Windows password to a longer and safer one, as 8-character password hashes can be broken in ~1min by tools like Hashcat.
Boy, did I regret that.
First off, my Acronis automated backup to mapped network drive on an SMB share ceased working. This was because ATIH stores credentials for network shares. The stored passwort was wrong because of the foregone password change.
When I tried to initiate the backup manually to my mapped network drive, ATIH asked for the credentials. No matter what I entered for a password, it would not be accepted. As it turned out after a few hours of searching, even Windows itself cannot create multiple connections to the same server with different credentials, thus any ATIH attempt to verify the connection would fail as long as another drive maps to a share from the same server (which is the case).
Only after I disconnected ALL mapped network drives to the server would ATIH accept the credentials and be able to correctly store them.
What can we learn from this?
1. ATIH unnecessarily asks for and stores credentials for drives that are already mapped. It should not care for that in the first place, since it has a perfectly good working path with a drive letter that "just works (tm)".
2. ATIH does not take into account that it cannot verify these credentials if a mapping exists to that server, thus causing problems in case of a password change or even when the backup is first created. Most users would not be able to identify nor solve that problem by themselves.
3. Apart from storing the credentials needlessly and causing problems underway, ATIH also creates a security leak while doing so: It MUST store the password somewhere on disk in a form in which it can be retrieved, otherwise it would be impossible to use it for making the network connection (thus it would be useless anyway). Windows itself stores only a password hash on disk, which cannot be used to find out the clear-text password.
The implication is that with physical access to the Windows system disk, an attacker can gain access to any non-encrypted file, including the file with the stored credentials by ATIH. He only has to retrieve the users credentials (which are by default and most likely the same as the Windows ones) and thus has access to any file on that disk - including EFS-encrypted ones which are normally safe from such attacks. Another possibility is a trojan or virus that can access the username and password in the clear.
The solution? Simple, just take a path with a drive letter for what it is: a path with a drive letter. Don't ask for credentials when you don't need them.
