I’m looking for recommendations of how to authenticate user/password combination and verify group association across a number of differing operating systems. Basically I have a C# application that is working in both MS Visual Studio C# and Mono C# and I need to add an authentication mechanism to it to support Windows, Linux, and MacOSX.
For Windows I wrote a quick C# interop to use the Windows only LogonUser APIs. This is working well, but won’t work for systems other than Windows. My ultimate goals is to have the same set of code run on all platforms (Windows, Linux, and MacOSX) with as little OS dependent #ifdefing as possible.
One note – I am trying desperately to use the inherent OS user accounts. I prefer not to maintain my own user account store.
Any thoughts or recommendations on approaches, user authentication techniques, etc are welcome.
I'm not sure how authentication works on linux and mac but the first thing that comes to my mind is to implement an IAuthenticator interface and have OS specific authenticator classes. You can then switch over to the appropriate class manually via Dependecy Injection or perhaps dynamically on runtime...but somehow your app should be able to identify what OS it is currently running on.
Each system handles local authentication differently. As #Darnell mentioned, you probably would need to write an interface for your authentication, and hide the system specific backend.
If you need to have the same user accounts across multiple systems, ldap for user info, and kerberos for authentication is the only fully supported cross platform way to handle it.
Short of "kerberizing" you application, and insisting that it only run in an equivalent environment, there's no universal method of authentication. Also, LDAP is really the only portable way to query for group information.
A simpler (more portable) option might be to use a pre-shared key of some sort. This way the user would authorize only your program, by giving it a key with which to sign the messages. Checking the message against the user's corresponding key would let you know that a) the user exists locally, and b) the message is coming from a source which the user authorized. You still have the problem of no universal group lookup, but you probably need to do that on your own if you can't rely on ldap.
Note: I still have to stress the following
I would strongly recommend not using someone's password in your messaging, ever, even if this requires you to maintain your own user/password database. You would be circumventing the local security paradigm, and opening up the system to more security risks. This is even more important if the system is using kerberos/ActiveDirectory, where great lengths have been taken to make sure the user's password is never being transmitted over the wire. Using DBMS's as an example - most of them do not tie into the local user database (at least by default), and implement their own user authentication mechanisms. Look at how security works in MySQL, or PostgreSQL.
Related
I am trying to build one intranet application. What I am trying to do is to authenticate the user using the biometric system, fingerprints to be precise. Like in some laptops or notebooks I have seen there is
a fingerprint authentication system. The same thing I am trying to build but not for a particular person. The only difference is that the person's biometric information would be stored on LDAP server. So
that anyone who has the right access to use that particular machine can use after getting authenticated. I am trying to get the user's biometric information using an external biometric device. I have gone through few documentations on Windows Biometric Framework. And using sensor adapter and engine adapter as plug-ins I can get the user's biometric information and also get processed and can send to the server.
The only query I am having here is:
First thing first am I breaking any Microsoft's policy here by achieving this?
If not then how can I get windows system lock and unlock after
getting the response from the server whether the user is valid or not?
Has anyone ever tried this ?
Can anyone help me to get this ?
Thank you in advance.
If you're saying that you want to actually notify the built in windows login / authentication system (known as a system credential provider) that the user is authenticated then this is not supported by the official windows API. If this was supported anyone could create malware that simply notified the API that a user is authenticated / authorized, thereby essentially rendering all of windows security meaningless. So we should be grateful this is not officially supported.
Trying to implement something like that without official API support would definitely be against the terms of use. Since its not officially supported, you would have to resort to some awful hacks to get it to work, the implementation of which would almost certainly be considered either reverse engineering the kernel or hacking the kernel (or both) by Microsoft's legal team. Even if you believed they were wrong... would you really want to fight them (and their deep pockets)?
Let's also consider that if no official unlock API exists, then you would be required to use some kind of backdoor to achieve it. If such a thing even exists, then it would certainly be subject to being rendered useless by an MS update (which would nuke your app's login implementation).
Now that the fire and fury is out of the way, let me state that all is not lost, provided you are targeting a more recent version of windows.
You can implement your own biometric security system as you described. This is now known as a third party credential provider This would be a separate system, and Microsoft recommends that you require users setup a system credential provider as a fallback in case your third party credential system fails for any reason. If not, the user account would be impossible to recover. Again, they key difference from the first example is that your system is separate and distinct from the system credential provider (windows native lock screen).
I would like to stress though, that implementing a third party credential system is still far from trivial. You will want to read up extensively on the proper interfaces you will have to implement. I'd recommend starting here:
https://msdn.microsoft.com/en-us/library/windows/desktop/mt158211%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
There is also apparently a sample located in the Windows SDK installation directory under \Samples\Security\CredentialProvider. Also, there is a nice technical reference of credential providers located here:
https://msdn.microsoft.com/en-us/library/windows/desktop/bb648647%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396
Click the link that says "Credential Provider driven Windows Logon Experience" to download the tech document.
My organization has a Win32 application that is written in the "fat client" style. I am writing a C# Client / Server solution that will replace this Win32 application. I am using ASP.NET MVC for the server and the client is a WPF application. I did my own custom implementation of the OAuth 2 spec. I am planning on creating a Restful API, and I want for not only my client to use it, but also allow 3rd parties to use it as well.
Every app will have an api key issued to it including the official client, but the official client's api key should be allowed additional api scopes (permissions) that 3rd party users aren't allowed to use. It is pretty obvious how to solve this but if you consider not everyone plays nicely, you have to ask "What would stop someone from just pretending like they are the official client and using it's api key?" Communication will be encrypted, but the server is not in the cloud or anything like that where we could control it. Our customers install the servers on their own machines and they will more than likely have access to the server application's SSL cert. Once you have that you can easily write an app that would run on our customer's machine that could glean the API key and secret from the official client app and use that info to request tokens from the server as if you were the official client.
I am planning on self signing the default key that the server uses and I could try and hide it in the application, but that really is just obfuscation. Besides, I wanted to allow users to provide their own SSL certs so browser based 3rd party applications wouldn't have issues with the browsers complaining that they are trying to communicate with on a self-signed SSL channel.
Is there anything I can do? Here are my choices as I see it:
1) I can set it up so that only SSL certs provided by us can be used and we hide them on disk encrypted using a secret that is obfuscated in the application code. We then just hope no one bothers to take the time to dig through our .net assemblies to find the secret used to encrypt/decrypt the certs on disk.
2) We allow them to provide certs so that we don't need to be involved with that process at all when they want to use a signed cert (we don't want to be in the cert business). Now we can't even hide behind obfuscation so if someone wants it, then the official client's API key and secret is easily obtainable.
Neither seems very desirable to me. Option 1 makes us have to request addition funds from them and manage SSL certs when self-signed doesn't work for them and in the end if someone really wants them they can still take the time to get them. Option 2 just makes it super easy to steal the official client's secret.
Reasons to want to limit unofficial Apps:
1. Discourage clones
A. Tell people not do it. Have a lawyer send cease and desist letters to authors of popular apps (and to anyone helping distribute them). Intermittently download them and alter the client/server code so that the popular apps will break. For added discouragement, temporarily ban any users who used the popular app. Authors will mostly give up on cloning your app; temporarily banning users will kill their install base. This is not great for your reputation.
2. Prevent unauthorized behavior.
A. Any behavior allowed by the official app should be allowed by the custom app. Whatever scenario you are worried about, block it server-side so that neither app can do it.
You can try to hide credentials (code obfuscation, hidden credentials, etc.), but this is only raises the cost/difficulty. This is often enough to discourage code theft (no need to make code theft impossible; it is sufficient to make it more difficult than copying it by hand). However, users who want to use your api in unsupported ways can work around this.
The answer is simple. each instance of you app should have its own unique key effectively a user sign up. You then ban users who infringe your rules. in this case signing in with a non authorised client. should be pretty easy to detect by pushing updates more frequently than it would be cost effective to reverse engineer them. Much like punk buster or other anti cheating tech
I'm developing a c#-webservice which will provide some methods for the client to interact with the mongodb.
My question is: should I use the
--> admin-user to read/write from/to the database and take care of the authorization my self
or
-->should I create a connection with the current logged-in user and let the mongodb take care of the user-authorization?
I'm asking because for some user-actions I need to query the user-database (where only the admin has right to read/write) before I can execute the method where user-rights are enough.
Tobias
The short answer is: Take care of the authentication yourself inside your application.
The medium length answer is: That's mostly based on your opinion, and it's a question you need to answer regardless of you database solution.
The long answer is: There are 4 different authentication mechanisms supported by MongoDB:
MONGODB-CR - An internal challenge-response MongoDB mechanism.
x.509 Certificate (new in v2.6).
Kerberos (only on MongoDB Enterprise).
LDAP Proxy Authority (only on MongoDB Enterprise for Linux).
I assume you run windows, which uses Kerberos for authentication. I also assume that you don't have the MongoDB Enterprise subscription because it costs 3X the basic subscription. If those assumptions are correct, you can't really use the windows authentication of the logged-on user to access the DB. That means that you must handle authentication yourself.
I recommend using certificates. It's quite easy if your environment supports it, it ins't specific to MongoDB, and it's very secure.
I am developing a windows application for my client, in .NET Framework 3.5, using C#.
There is no need of any database in my application.
I want to secure my application by making a registration process at the time of installation, where the user will be asked to enter a registration key, which should be machine dependent, otherwise the user can copy the installation folder and distribute to others, which i don't want to happen.
Please suggest me, how to achieve this.
Thanks,
Bibhu
I believe you will need a registration service.
When the user registers (they'll need to be online), their registration 'code' is sent to your registration service along with their machine details / other identification (username?).
Your service verifies this & returns a key which can be decrypted by your app using their machine details / identification. Your service also marks that registration code as 'used' so that no one else can get a valid key by using it.
The application stores the valid key in registry, or even config. It won't work on another machine because it is specific to the machine details.
my suggestion is this ways:
1)you can create a registery key after registration and in start up of your app check this registery key.
2)you can create a web service (over local network or internet) and on startup check if this version is registerd or not
3)create a custom file and store a hashed value based on machine and in startup of you app check this file
in every 3 way do not forget OBFUSCATION
There is no way to guarantee software is secure. Even registering over a network can be faked with the use of packet analyzers. In securing software, all you can do is make it slightly inconvenient for professionals, difficult for dabblers, and impossible for people with no knowledge. Generally, it's accepted that obfuscation is not a good protection, because someone will eventually figure it out and publish it anyway.
Also keep in mind that the more secure you make your program, the less usable legitimate users are likely to find it. It's a hard balance to strike between usability, security, and the value of what you lose if security is broken. There is no hard and fast 'right' way to secure something.
For machine dependent information, you can gather information about the hardware on that system, hash it somehow, and store the value somewhere, and then check it at the launch of the program each time. It's not fool-proof, but it allows some security fairly easily.
I'm trying to write a central reporting tool that will allow time tracking based on Windows users logging into a domain. Initially I was going to create a small executable that would run on 'all users' start-up on each computer, track the logged in username and update a central database.
The main problems with this would be having to manage the versions on a machine by machine basis and deal with rare but possible instances of the tool failing on specific machines and not being immediately obvious.
Instead I would prefer to create a centralised version but I'm finding the MSDN and Windows SBS 2003 docs very hard to dig through for the answer.
Basically I would like to hook into the 'login' and 'logout' functions on the server and track all information from there. Are there natural extension points here?
Obviously an alternative may be to parse the event logs for the information (but to this point I can't find any windows logs that say 'who' is logging in or out).
Any guidance on the direction or documentation to look at would be really appreciated.
Are there natural extension points here?
No. Or rather, you don't plug into login/logout unless you want to replace the login module (e.g. for a different authentication mechanism): not something trivial to do—too easy to open up security holes (and I expect not a good idea, if not impossible, in .NET).
But as Windows (all NT derived versions) includes the ability to log all logins and logouts, the information you need can be recorded in the Security event log. There are then a number of options for getting at the information.
First: enable audit of login/logout.
This is best done with group policy. For the local machine enable the options in SecPol.msc (local security policy MMC snapin): Local Policies | Audit Policy
Second: read the event log
In the Security Event Log look for logon events (id 4624), there is some documentation of these events here.
Automation of this (e.g. via a scheduled read of the event log) or forwarding events should be easy enough.
Not all logins will go to the dc. For example a laptop may use cached credentials to allow access when not on the domain.
You may also see multiple logins for the same user if they are accessing network resources. I think the most reliable approach would be to have the code running on each machine getting called from one of the login hooks.
You should look into the namespace called Microsoft.Win32.SystemEvents. There are many handlers there, but i believe what you want is the SessionSwitch event, which will tell you if the current user is logging on/off of the box or locks the screen. This is possible because windows switches to a different desktop when the screen is locked/unlocked, so you will be able to catch these.
Then, to get the user information, you could use the UserPrincipal from System.DirectoryServices.AccountManagement namespace using the machine's principal context.