I'm currently working on a project using visual studio 2010. I will like to know how to use a thumb drive to authenticate security in asp.net.
For example, when you insert a thumb drive from the user computer(example D: drive). The system is able to track that this is the correct drive plus the thumb drive and then the user will be able to view the page. If the thumb drive is removed or not insert, it will redirect you to a lock.aspx screen till the thumb drive is inserted back again to the correct drive.
I am thinking using the serial number as the key to know which is the thumb drive.
It is something like the (USB predator) but I am trying to do it on a web application instead on Windows.
Anyone can give me a guide on how to start or tools that I can use for this?
The problem consists of two parts.
First, you need to have something on the client which will check the USB device. Browsers themselves won't do this for you unless you have a power to build some custom version of the browser (Chromium- or Mozilla-based, for example) and have your users install and use this browser. Alternatively you can create a plugin for the browser, which will do the job. One more option is to have some applet on each page of your service. In case of plugin you need to have the client install it and the plugin host itself (browser) should let the applet connect to USB device in some way. In case of applet see below.
Second aspect is the use of the USB drive. Such drives can be easily copied or stolen, so their security is low. There exist USB cryptotokens, designed as part of their functionality for client-side authentication, the task similar to yours. USB cryptotokens contain certificates with private keys and/or they can contain symmetric keys or other information which (A) requires the user to enter PIN to access this information and (B) is not extractable from the device (keys can be used but not copied). Both A and B significantly increase security.
USB cryptotokens require that the user installs the driver for such token, also the tokens are more expensive than regular flash memory. On the other hand, they can be accessed from Java applets relatively easily (and maybe from browser plugins too - this depends on the browser) AND they can be used for authentication in a safe way by performing cryptographic operations instead of pure transfer of the serial number or alike.
To sum up, you can build a login scheme but you will need to make the user install something (plugin and/or USB token driver or custom browser).
Related
I have a bit of a difficult situation in that I need a way for a client connected to an ASP.NET MVC site to sign and decrypt blobs with their private key, such that the server never sees the private key material. In the decryption case, these are encrypted session keys. It is acceptable that the server see the session key, just not the users private key.
That is, I need to present the user some content in a browser, have some javascript (or java applets, or silverlight, etc.) execute client side that communicates with a hardware token on the client, and returns the result to the server.
This is NOT client side authentication. I don't need to simply authenticate via IIS with a certificate. The hardware tokens are HID OmniKey USB readers.
My understanding of the options available are:
1. Mozilla Javascript Crypto - This seems to be the optimal route. It appears that Firefox exposes various smart card events and functionality to remote sites. I see how to sign text, but nothing about decrypting blobs (the largest goal). There seems to be methods for loading a PKCS#11 module, but the documentation seems to stop after that.
2. Silverlight with Elevated Trust - This is my second preferable route, because of familiarity with Silverlight and .NET. Silverlight 5 has the ability to P/Invoke, so I could always call the PC/SC modules, but this requires running Out of Browser, which I can't do. There seems to be some posts about running a Silverlight app In Browser with elevated trust, but this is a global setting, and so I don't want to diminish security for other applications.
3. ActiveX - An ActiveX component can interact with the PC/SC module, but this would be an Internet Explorer only solution. If forced to pick a required browser, I'd prefer Firefox or Chrome.
3. Firefox/Chrome Extension - My understanding is Firefox XPCOM is C++, and I can just directly call the PC/SC libraries, and the extension can interact with scripts/DOM on the remote site. I'm not sure how the remote site though can trigger a Firefox extension. In other words, how does the remote site tell the extension "ok, it's time to sign"? One such example of this route is XSign (though it doesn't use hardware tokens).
4. Java Applet - This might ultimately be the only way to do it. I've found a couple examples/guides, but I'm not familiar with Java. Java Applet for Signing with a Smart Card. In this case, it's just a simple applet that can communicate with the token, and post the results to the site.
Are there other options available? I believe option (1), Mozilla Javascript Crypto is the best approach, but the documentation is beyond sparse. Thanks for any guidance.
I have virtually examined all options. The last option (Java Applet) is the most appropriate for your case and easiest to implement. The downside is that JRE (Java Runtime Environment) should already be installed at client side and plays nice with the browser. User also has to grant permission to the applet to connect to his smart card at first run.
BTW if you want to use PKCS#7, you can use Bouncy Castle. It has no standard API in JDK.
PS: Don't use JavaScript for cryptography. Javascript Cryptography Considered Harmful.
Maybe you could consider just having the clients download a native application and install it (once). You can have them use that app to do the authentication and negotiate a session key with your server - the app could then launch a browser with the session key in the launch url. "Native" apps could probably be not that native - use java or .net (if you're windows only) or python etc.
I am developing a flex 4.5 web based application and I need to make sure if the client chooses a certain level of security, each user can log only from an authorized computer.
So the question is how can I get some unique computer information? Anything like HDD serial number, CPU specifications, motherboard information, even the user that is logged into the Operating System can do.
So far the information on the web isn't giving me much hope that this can be achieved, but I had to ask.
Thanks in advance.
I suppose the only option available for web application is to create unique id from fields of flash.system.Capabilities class.
Other strategy which can be used is to generate unique UID in process of computer's authorization and then store it in local storage using SharedObject. Then web app tries to read authorization data from SharedObject on web app start. If there is no such data computer isn't authorized.
Richard is right. For security, unique identifying information is not available for applications running through Flash Player. You could write an Active X control (for IE) or a plugin (for Mozilla based browsers) to obtain additional information for your app if users (and their IT administrators) allow it. Information available will vary depending on the browser and operating system the user is running.
Adobe Air, on the other hand, allows access to additional network information including MAC address in the NetworkInfo class. Maybe it's worth considering an installed client app for users who require the additional security. Take a look at: http://www.adobe.com/devnet/air/flex/articles/retrieving_network_interfaces.html
This is not easy using a browser based Flex application, but there are some workarounds.
The browser based Flash Player can communicate with an AIR app on the desktop using localconnection. So, you could create an AIR app that utilizes NativeProcess to retrieve your machine specific information.
You could also use NativeProcess from a AIR app without using the browser at all.
A third option would be to install an application server on the client machine and have the browser based app communicate with the server to retrieve the client information.
I consider most of these options too difficult to be practical, but it depends on how important this feature is to you.
The Flash Player security sandbox will not let you read anything unique about the system on which the SWF is running, so I'm afraid this is not possible. The closest you will get is likely Capabilities.serverString along with maybe IP address, but the serverString property just lists all the capabilities of the client, which is obviously not a unique thing, and also might change from time to time for the same computer.
Warning: my knowledge of server-side scripting is limited to say the least.
This isn't a technical solution, but rather a different approach to your problem.
An alternative solution to would be to inspect the raw packet at the server in order to obtain data such as the IP and MAC address. Based on this the server can then deny or allow the login attempt.
I am used to working on embedded web servers running on micro controllers where C-based black magic is rather common, so I am not sure if this is possible or practical in a more traditional environment.
I am new to flex but my first app is a little bit more pro than you would expect form a rookie. I would like to record sound that is currently played on the local computer (i.e. form winamp or youtube). I saw some codes that use the microphone, but this is undesired. The client machine may not have a microphone hardware or may play the sound on headphones. I think this must be possible but may be not a common task so that's why I can't find the solution? Can any one help?
I believe the user of your app has to select their "input device" and allow access for the Flash web baesd app to access that input device. But, once they do the choosing, you should be able to access that Audio feed using the same microphone APIs.
bring up the Flash Player context menu and select settings. then click the microphone tab. You should see a list of all possibly options. at this moment, one option I have is "Stereo Mix" which I'm pretty sure will send out all the info from the computer.
Is it possible to embed an external application inside the browser (IE, Chrome, Safari, Firefox) so it will look like a native web application but actually having access to the USB ports of the client machine? I have heard that I need to make an ActiveX control. I would like to use the .Net framework, but if that is not possible, maybe using Java or C++ will be fine.
I have to make an application that will allow to the users to connect an external device to an USB port, this device will take a backup of the information contained in a SIM card and send it to the user's account online agenda. So the user can restore it later using the same application. This should be a web application or at least look like one.
If the first is not possible. Is there any way to launch an external application from all the browsers, and then pass information to the browser window to allow it to refresh after the backup has been made?
Thanks for your help in advance.
First off this seems to be a big security issue and hence this is the reason why you might be finding it tricky.
What I would do is look at it from a different angle; what am I trying to achieve? How is the user going to use the data? Where is the user going to use the data?
From you question I have answered those questions with the following; I hope I've not miss interpretted anything.
I want to copy the data from an external sim card to a central location
I want the user to see this data from the central location; preferablly from a web application.
The user is going to see and use the data from the web app
Assuming all of these things are true; one design option is the following:
1 - Have a client based application which can read stuff from the usb device
2 - Have a secure webservice which the client based application can upload the data too
3 - Have a web application which can view this data and see refreshes
Let me go into bit more detail for each step.
1 - If you write a small client application it is installed or at least runs on the client computer. Due to this it can access the local client resources such as usb and interface with them. This will mean they can read the sim data throuogh this app, buut also potentially save it locally as well as upload the data. To access the web service they would enter their username/password so you could authenticate them for the upload.
2 - This web service would do the authentication from the client application, but also receive the data submitted from the client app. Acessing web services from .net now a days is really straight forward. Using this web service the client application could also do some checking to make sure the data has been updated and it could handle re-tries if the network dropped etc.
3 - The web front end of the system would interface to the same data source. This site would take the username / password to authenticate them on the site, but also let them see the uploaded data. As for the refreshes; if the user is logged in and looking at the data you could have a javascript timer polling an action/service to see when new records have been added etc. This could then display a message through jQuery or similar to notifiy the user. This could be similar to the notifications which StackOverflow gives when you visit for the first time or get a new badge etc.
Hope this helps :-)
We are in the process of writing a native windows app (MFC) that will be uploading some data to our web app. Windows app will allow user to login and after that it will periodically upload some data to our web app. Upload will be done via simple HTTP POST to our web app. The concern I'm having is how can we ensure that the upload actually came from our app, and not from curl or something like that. I guess we're looking at some kind of public/private key encryption here. But I'm not sure if we can somehow just embed a public key in our win app executable and be done with it. Or would that public key be too easy to extract and use outside of our app?
Anyway, we're building both sides (client and server) so pretty much anything is an option, but it has to work through HTTP(S). However, we do not control the execution environment of win (client) app, plus the user that is running the app on his/her system is the only one that stands to gain something by gaming the system.
Ultimately, it's not possible to prove the identity of an application this way when it's running on a machine you don't own. You could embed keys, play with hashes and checksums, but at the end of the day, anything that relies on code running on somebody else's machine can be faked. Keys can be extracted, code can be reverse-engineered- it's all security through obscurity.
Spend your time working on validation and data cleanup, and if you really want to secure something, secure the end-user with a client certificate. Anything else is just a waste of time and a false sense of security.
About the best you could do would be to use HTTPS with client certificates. Presumably with WinHTTP's interface.
But I'm not sure if we can somehow just embed a public key in our win app executable and be done with it.
If the client is to be identifying itself to the server, it would have to be the private key embedded.
Or would that be too easy to extract and use outside of our app?
If you don't control the client app's execution environment, anything your app can do can be analysed, automated and reproduced by an attacker that does control that environment.
You can put obfuscatory layers around the communications procedure if you must, but you'll never fix the problem. Multiplayer games have been trying to do this for years to combat cheating, but in the end it's just an obfuscation arms race that can never be won. Blizzard have way more resources than you, and they can't manage it either.
You have no control over the binaries once your app is distributed. If all the signing and encryption logic reside in your executable it can be extracted. Clever coders will figure out the code and build interoperable systems when there's enough motivation to do so. That's why DRM doesn't work.
A complex system tying a key to the MAC address of a PC for instance is sure to fail.
Don't trust a particular executable or system but trust your users. Entrust each of them with a private key file protected by a passphrase and explain to them how that key identify them as submitters of contents on your service.
Since you're controlling the client, you might as well embed the key in the application, and make sure the users don't have read access to the application image - you'll need to separate the logic to 2 tiers - 1 that the user runs, the other that connects to the service over HTTP(S) - since the user will always have read access to an application he's running.
If I understand correctly, the data is sent automatically after the user logs on - this sounds like only the service part is needed.