Is there a way to protect some cryptographic data from applications other than my own in Windows? I'm not concerned about protecting it from the user - this is obviously impossible - but, rather, from non-elevated applications other than my own.
I'm aware that I could simply run the application's core code as a service, with the data accessible only to system accounts, but I would prefer if I could keep the application running under a token not much more permissive than the user's normal token.
Additionally, I would prefer not to have a dependency on .NET if possible.
CryptProtectData
can do per-user encryption (it is per-user if you do not pass CRYPTPROTECT_LOCAL_MACHINE flag). However if you opt for per-user encryption, other users including elevated admins won't decrypt it.
Related
I apologize for the bad phrasing in the title, but here's a little more context.
I recently bought a Windows 8 laptop and noticed that Norton was pre-installed and running with SYSTEM level privileges. Thus, it occurred to me that there must be some way for third-party applications to run with SYSTEM privileges.
However, after much googling, I could not figure out whether it was an API call or a registry setting or something else entirely that enabled Norton to do this, so I decided to ask the SO community. How can I write an application that runs with SYSTEM privileges?
Services can be configured to run as several different accounts, including LOCAL SERVICE, NETWORK SERVICE, SYSTEM, or any user's account.
Using SYSTEM isn't recommended, because any security problem can lead to complete compromise of the machine, but it is available.
This is configured by the lpServiceStartName parameter of CreateService and/or ChangeServiceConfig. Pass a NULL pointer as this parameter of CreateService, or ".\\LocalSystem" to ChangeServiceConfig, to use the local system account.
It's a bad idea to run a GUI application as local system. The best approach is to have both a GUI application (running as the logged-on user) and a service (running as SYSTEM) and have them communicate as needed using any suitable IPC method. This is probably what Norton is actually doing.
However, it is possible to get a system service to launch an application as SYSTEM in the user's session. To do this, duplicate the processes security token with DuplicateTokenEx and then use SetTokenInformation with the TokenSessionId option. This will give you a token in SYSTEM context but in the user's session which you can use to launch an executable. (There may be additional issues; for example, you might also need to change the permissions on the workstation and desktop.)
I have this nifty PAM module that validates each session (like a desktop session) on authentication and, based on some criteria, either allows or prevents it. I would like to do the same on Windows 7.
Now, this may sound silly or trivial to no extent, but I really don't know my way around Windows systems, and would thus like a few pointers on how to achieve something similar (i.e. a service or a module that is queried when e.g. a user tries to start a session.)
I think what you are looking for is a Subauthentication Package, but you could get some mileage with a Credential Provider.
A Subauthentication Package is a dynamically linked library that the local security authority or the Kerberos Key Distribution center (KDC) will call after authentication has succeeded, but before access is granted to the user.
Windows will authenticate the user locally or through Kerberos, depending on your configuration. You must build a DLL that exports the two functions:
Msv1_0SubAuthenticationRoutine (not called for interactive logons or Kerberos)
Msv1_0SubAuthenticationFilter
You put your code in that DLL, and return STATUS_SUCCESS if the user is allowed to log on, or one of the other error codes. You cannot assume that you will have access to the password.
If you log on through Kerberos, you must register your DLL on the KDC. It makes it hard to authentication against some local information, like a hardware or biometric device.
So maybe a Credential Provider could help you, but it is not the most elegant solutions. It was designed to capture credentials and feed them to an authentication package. But Microsoft made shure a credential provider will not lock a user out, so it might not always be called (in safe mode) and the user could install another CP, etc. So I mention it for the sake of completness.
For what purpose(s) is the SeTcbPrivilege privilege in Windows used? Can it be used, for example, to run a program under the SYSTEM account?
Acting as a part of the operating system allows you to do things like create login tokens. It's unlikely that you would ever need to write a service that uses this privilege unless you're writing an authentication provider.
Since you can create access tokens, you can act as any user. Of course, this means that you can run programs under the SYSTEM account, but there are much easier ways to run something as SYSTEM.
To add to Gabe's answer, here is what MS says,
Allows a process to assume the identity of any user and thus gain
access to the resources that the user is authorized to access.
Typically, only low-level authentication services require this
privilege.
Default setting: Not assigned.
Note that potential access is not limited to what is associated with
the user by default; the calling process might request that arbitrary
additional privileges be added to the access token. The calling
process might also build an access token that does not provide a
primary identity for tracking events in the audit log.
When a service requires this privilege, configure the service to log
on using the Local System account, which has the privilege inherently.
Do not create a separate account and assign the privilege to it.
Source: Microsoft TechNet
SeTcbPrivilege is very useful for debugging purpose. For example, if you are developing Windows service that has to be run under system account and perform impersonate things it is conveniently to run this service as standalone exe. SeTcbPrivilege will allow to do this.
I am looking for the best practice for storing user credentials in a windows 7 phone app. I am writing an app for a web service that requires authentication. Thankfully it is only basic authentication at this point. What is the best way to store those credentials?
The best way to store credentials in your case would be encrypting them and storing in the application-specific isolated storage - basically, it cannot be accessed by any other application, so that gives another protection layer.
In terms of security, the best practice would be to avoid storing user credentials if possible. MSDN states:
Applications often ask users to
provide a username and password that
is used as credentials to authenticate
the user with a web service or
website, yet if they do so each time
the application is run, users can
become annoyed.
It is strongly recommended that your
application prompt for usernames and
passwords each time your application
needs them from the user; if you
attempt to save the credentials on the
phone you risk exposure of those
credentials to a malicious application
if the Windows Phone is lost or
stolen.
Actually, in the data encryption tutorial mentioned in the other answer, Rob Tiffany makes a similar disclaimer:
The OS Does Not include framework
support for storing your passwords and
salt values securely nor does it come
with any kind of built-in key
management. This means the only way
to ensure your encrypted data is
actually secure is to never store
your password, salt value or keys on
the phone.
...
If you see an app in the Windows
Phone Marketplace that allows you to
cache your credentials or keys locally
for convenience, be aware that these
are Not Secure solutions because
everything a hacker needs to get at
your data is right there in the code
or in Isolated Storage.
Encryption is good for raising the bar, but this would not really protect the credentials from a knowledegable hacker. Usability sometimes trumps security, but you should take this decision knowing that encryption will not solve the core issue in this case (and maybe let the user be aware of this risk).
A good explanation by Rob Tiffany of how to encrypt your data in isolated storage can be found here:
Don’t forget to Encrypt your Windows Phone 7 Data
I haven't tried out the code myself, so can't vouch for it's correctness (sorry Rob :-) - should serve as a good starting point though, I would imagine.
I also second Dennis' point about application-specific isolated storage giving you an additional/basic layer of protection in addition to encryption, as theoretically at least, other applications cannot access your applications isolated store.
You should use the ProtectedData class to store securely various bits of confidential information.
Learn more at How to: Encrypt Data in a Windows Phone Application
As we all know,we can use such api as "LockWorkStation()" in "user32.dll" to lock windows.
But how to unlock it?
For example, if i run an app at first, I want the app to unlock windows by itself after 30 second.
How to do it? In another word, if auto-logging in, windows will read the username and password from regedit and then use an api to login by those.
Now i need the api. It must exist, but it seems not to make public.
I can get the app the username and password of the windows.
It seems that there is some Api in WBF.But you know,the resource is too less.
I don't want to send keyboard message to solve the problem,for it is the worst method.
Promoting my comment because it needs more explanation:
You really want to write a GINA (for XP) or a Credential Provider for Windows Vista and beyond.
Fundamentally the Windows authentication model is based on the user providing evidence (identification) that they're authorized to access the computer (either by their credentials or biometric data or smartcard or other information). Once you've been authorized to log onto the computer, Windows allows you access.
When the workstation is locked (for whatever reason - screen saver, user typing in Win-L) the user needs to be re-authenticated.
Typically that's sufficient - the authorization is good for a period of time (determined by the administrator). If (for policy reasons) you need a finer grained control model, you could use your "LockWorkstation" idea to force the user to re-authenticate themselves. You need to be VERY careful about false positives (nothing pisses off users more than being told they're not allowed to use their computer simply because they removed their glasses or combed their hair differently) and how much drain on system resources your app causes.
When the workstation is locked the only way to unlock it is by the user logging in (pressing Alt+Ctrl+Del and entering correct password). This is a security feature that you cannot circumvent using an application API.