-1

As far as I understand if Dropbox wants to automatically run in the background without asking the user for a password it has to store the password somewhere on the harddrive and has currently no way to encrypt that password in a way that other applications can't read it.

As a result some security aware application ask the user every time the run for a password to avoid storing the password.

I could imagine a system where the OS has a safe area that encrypted with the password that the user uses to login to it's user account and that configured in a way that only the dropbox.exe can access. The dropbox.exe can identified via the path where it lies on the disk and a hash. When Dropbox updates itself it would have to give a notice to the OS to calculate a new hash.

This not only goes for Apps like Dropbox but also for Apps like KeePass that store lots of passwords. It seems to me that even a malware that can read the whole disk and capture keys via a keylogger couldn't steal passwords in a setup like this, provided the keylogger isn't active when the user signs into his user account.

Is there an error somewhere in my thinking?

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
Christian
  • 1,876
  • 1
  • 14
  • 23
  • Typo in title: US = OS. – Rob W Aug 16 '14 at 15:04
  • @RobW: You can edit it if incorrect. ;-) – SilverlightFox Aug 16 '14 at 15:14
  • Password vaults work this way, actually. The data is encrypted by the vault, and as soon as sandboxing is mandatory then such an app is guaranteed to be protected from others tinkering with it. – Steve Dodier-Lazaro Aug 16 '14 at 15:15
  • The only question is how can an app be protected against e.g. code injections or other modifications to its runtime environment, and how it can be provided with a private FS space by OS routines. I think at least iOS and Android can do this, and it's on the way in the three major desktop OSes. – Steve Dodier-Lazaro Aug 16 '14 at 15:16
  • The malware could just pretend to be Dropbox. You can only avoid that if the entire system is locked down to start with, e.g. like most mobile OSes (Android/iOS/no idea about Windows Phone) – user253751 Aug 17 '14 at 09:09
  • 1
    Asking for the password every time it's run can actually be a distinct concern from not wanting to store the password. Take a page out of web-session management; after verifying the password, you should give the app a sign-on token. Asking for a password every time is then just a means of expiring a session. If you have malware on your machine, they often try to get included in the boot process, because then they're enabled from the start (and have much better access, too)... – Clockwork-Muse Aug 17 '14 at 12:15

1 Answers1

4

This an artifact with the way windows does permissions: you can't act as a user without knowing the user's password because certain key bits of information are encrypted using the user's password. So this applies to no other operating systems.

But the key here is that users have permissions and ownership rights, programs do not. So each application is just an activity that the user can perform. Dropbox can't own things because it's a program, not a user.

And the other key is that the task scheduler itself runs as the "system" user. So every task it performs it performs as "system". A program can take on another user's identity, but for that it needs the identity's password. Which means that the task scheduler user ("system") needs needs access to that password, which in turn gives that password to ANY program running as "system". Because ownership can only be assigned to users.

It's a bit of a mess, but the TL;DR is that the rules Microsoft created for Windows forced them into this corner. Yes, there are solutions that avoid this problem, and in fact every other OS has solved this. But not Windows. Feel free to complain to Microsoft.

tylerl
  • 82,225
  • 25
  • 148
  • 226
  • 1
    I have the impression you're answering another question than the one I read. Did the OP mean asking for the Windows user account password through some permission granting system call that in turn pops in a dialog, and did the OP somehow believe that an app would be able to feed a password to the syscall to avoid the dialog (it can't do that, right? that'd sound terrifying) as opposed to storing locally the user's Dropbox account password because Windows does not provide a password vault? Any chance you edit the question to make it clearer since you understood it? – Steve Dodier-Lazaro Aug 16 '14 at 20:51