I've been trying to use the Windows Authentication low level credential API functions to backup/restore credentials.
http://msdn.microsoft.com/en-us/library/aa374731%28VS.85%29.aspx#low_level_credentials_management_functions
However, I've found that while I can use CredEnumerate to obtain every credential on the system, all the passwords are missing for domain type credentials (which is documented). Is there any way to backup/restore these credentials in the same way as the windows GUI tool can?
Hmm, it looks like I've found the answer although I don't like it. The only way to do this seems to be to CreateRemoteThread() to create a thread in lsass.exe (The windows security subsystem) and then to enumerate the credentials from within that thread using undocumented function LsaICryptUnprotectData exported from Lsasrv.dll to decrypt the credentials buffer.
It works but I'm not sure I have the stomache to put this into my software...
Related
I am developing a credential provider for windows. I would like to know if it’s possible to attach and debug while running. As this is part of a logon process I am not sure if/how to do it.
Also, if a credential provider crashes, does windows dump a core like Linux does?
Thank you
You can invoke your credential provider using simple call to credentials API CredUIPromptForWindowsCredentialsW. See MS docs for detailed description.
I have been creating my own simple application to do this call.
It is tuned to call Windows Security Dialog with my own suggestions and options (CREDUIWIN_IN_CRED_ONLY flag in my case).
You can modify invocation flags to approximate your scenario.
The easiest way debug credential provider is to setup it on some other machine and use remote debug tools to attach to LogonUI.exe.
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.
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
My desktop application asks a user for proxy-server credentials to use it later. But what is the best way to store this secure information for further usage?
In Windows you can use CryptProtectData function to encrypt your data using account password, then store the encrypted data in registry or in config file. This way you won't need to ask for any password at all.
Ask user for master password and encrypt all credentials and other info related to that user with that password. Ask for this password once when this data is first requested (just like FireFox does with your site login/passes).
If you want to construct the system without master-password from user, you will have insecure one, because you will need to encrypt user data with some key, that will be stored inside your application, that is in turn can be reverse-engineered and the key can be extracted.
Further to Eugene's comment, on Gnome-based systems like Ubuntu you can use GNOME Keyring to hold the information encrypted. On KDE you can use KWallet, the equivalent, and on Mac OS X you can use Keychain.
I would definitely look hard at using these OS facilities rather than writing my own. Unfortunately they each have different interfaces, but the API you have to use is not very complicated.
We have developed a ASP.NET 3.5 web application with Web Server 2008 and has implemented a custom authentication solution using active directory as the credentials store. Our front end application uses a normal login form to capture the user name and password and leverages the Win32 LogonUser method to authenticate the user’s credentials. When we are calling the LogonUser method, we are using the LOGON32_LOGON_NETWORK as the logon type.
The issue we have found is that user profile folders are being created under the C:\Users folder of the web server. The folder seems to be created when a new user who has never logged on before is logging in for the first time. As the number of new users logging into the application grows, disk space is shrinking due to the large number of new user folders getting created.
I need to get the token back after the authentication (authenticated \ password locked \ wrong password ) its futher use and based on logic showing different web pages
Has anyone seen this behavior with the Win32 LogonUser method?
Please answer the following issue:
Is it possible to disable this behavior to create the folder as taking 2.78 MB of space for every new user and it eating my disck space?
I have tried LOGON32_LOGON_BATCH but it was giving an error 1385 in authentication user.
For any solution related to LOGON32_LOGON_BATCH, can you please confirm if that will stop creating the folders at location C:\users.
Also for any possible solution I need either
I am able to disable the folder to be created at C:\user or
Any other option to authenticated user which will not creat folders.
Pass LOGON32_LOGON_BATCH and grant the users permission to log on as a batch job on that machine using Group Policy.
The MSDN documentation for LogonUser recommends LOGON32_LOGON_BATCH as the logon type for web services:
This logon type is intended for batch
servers, where processes may be
executing on behalf of a user without
their direct intervention. This type
is also for higher performance servers
that process many plaintext
authentication attempts at a time,
such as mail or Web servers. The
LogonUser function does not cache
credentials for this logon type.
Have you tried that?
You don't write any information about the version of products (.NET, Windows Server which you use) and the best answer on your question can depend on this. Moreover the best way for your solution depend on what you want to do with the users token after logon. Do you really want to use this token or you want only verify the user? So I try to answer most general on your question.
In general, error 1385 (ERROR_LOGON_TYPE_NOT_GRANTED) means following (see http://support.microsoft.com/kb/155012/en):
A user has requested a type of logon,
such as interactive or network, that
was not granted. An administrator has
control over who may logon
interactively and through the network.
There are SE_BATCH_LOGON_NAME and SE_DENY_BATCH_LOGON_NAME (NTSecAPI.h) privileges which can be disabled/enabled in your case (see http://msdn.microsoft.com/en-us/library/bb545671%28VS.85%29.aspx for description). Use Process Explorer started with administrator rights (see http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx) to see which privileges has a process and which from there are enabled (see "Security" tab of a process). If your account used for the application pool don't have SE_BATCH_LOGON_NAME granted or this privilege is not enabled before call of LogonUser, you should add the corresponding code in your program.
By the way sometimes you don't really want to do much with an user account and want only verify a password. To do this you can use an old way with SSPI (see http://support.microsoft.com/kb/180548/en) which are used inside of LogonUser implementation. This way is the most smart and quick way to verify an user account which I know.
You can look at "The SSPI Workaround" (see http://alt.pluralsight.com/wiki/default.aspx/Keith.GuideBook/HowToGetATokenForAUser.html) for more information of usage SSPI in .NET 2.0.