generate fingerprint of client using javascript - javascript

How can i generate unique fingerprint of each client?
I know must use navigator object but some properties like navigator.battery cannot use in this method.
// battery included and unique may change.
var uniqueHash = exampleHash(JSON.stringify(navigator));
How can i generate correct unique fingerprint for each user just using JavaScript and without cookie.
Cross platform and older browser also must be included.
I need list of cross browser supported by navigator.X
Note:
I don't want to generate random hash. i want to generate system base hash for each user and i dont wanna save on Cookie or Storage.

How can i generate unique fingerprint of each client?
Short answer is that you can't. It's impossible to do this for every client. You can get close using invasive profiling of the client, but you'll probably only get a unique identifier in around 90-95% of cases.
and i dont wanna save on Cookie or Storage.
Is there a reason you don't want to store data client side? If you told us what you were trying to achieve then maybe we could suggest a better way to solve the problem.

One route that may be worth looking into is using the Mozilla Persona API. It exposes a navigator.id property for consumption. Getting a unique id from a user is as simple as...
navigator.id.get(function(unique_id) {
alert("this is your unique id: " + unique_id);
})
This has the downside of requiring user authorization
Example: http://jsfiddle.net/aJsL9/1/

Simplest way to keep a session without using cookies is appending a unique hash (maybe a UUID or something similar) to the urls in the page as a get parameter:
/my/fancy/url
becomes
/my/fancy/url?HASHCODE
whenever the server receives a request, it capture the HASHCODE if present, otherwise it generates one, and then append it to all links on the served page.
Please bear in mind that the user can manipulate the HASHCODE and you should take that into account when engineering your application.
Anyway, notice that it's quite ugly in the fancy-url era. Also notice that user tracking is a delicate subject and you might incur into legal problems if you do not properly declare it in the TOS.
EDIT: you cannot track a person across multiple web sites without using cookies in any of their variants (flash, session storage, etc.) and a domain shared between sites. No way, you cannot set a variable or cookie from one domain and access it from another one in any decent browser, otherwise it would be a big security hole.
EDIT: Panopticlick cannot be used as a tracking method as you suggested, because it is based on statistical matching and it is also pretty bad at that (try browsing https://panopticlick.eff.org/ from outside the USA or with the just-released Chrome/Firefox update). It's a good proof concept, but nothing that you can use for this purpose. Also, you would need a whole lot of samples to get statistically relevant results.
EDIT: Browser fingerprint identifying power is weak: many browsers are autoupdating (like Chrome or Firefox) and official builts are very few (20? 40? Maybe a bit more if you count Linux distribution-compiled ones), so you will find a consistent portion of users with the same user agent. Add that there is a pletora of consumer PCs with similar configurations.

Related

php/javascript user info collecting

I believe some users on my site are using IP masks to create more than one account. Due to the nature of my site/game it's against the rules and I need to remove players like this.
I currently track their IP, host, browser type and such with PHP, I also use javascript/jquery to get their screen size. I also have a little script set up that tells me if their coming through a forwarding service. It says this certain player is although his IP doesn't match any proxy lists I've come across.
Basically I'm looking for any other info I can collect that I can compare and determine if a suspect player is actually another players second account. Any suggestions?
The only thing i can think of is using telephone number as part of subscription process. And sending some sort of verification code via SMS.
Also you can start setting cookies.
And is it possible to imagine some sort of detection as part of your game/application. Like you add some game elements that would expose suspects to some secret knowledge. Setup honeypots. Like you show some secret 'cheat' codes or specific link/location to one suspected double and not to the other. Then if the other tries to use that info - you got him... Basically build some sneaky intelligence into your app
Combining these with all the other detection techniques, could make it very close to 100% bulletproof and can be a lot of fun.

Device/Browser Registration

I need to develop an application that registers the device/browser that the user is using. Such as banks or better yet FB does. So for example when a person logs in the application checks to see if they have logged in using that device/browser before. If not then have them go through a verification process.
The application will be built in .Net 4, Asp.Net MVC, js, jQuery, etc..
I hoping to get some advice on what others have used to accomplish this task.
EDIT
Thanks for the comments.
Ok, so basically, if am understanding correctly, both suggestions would mean storing a uniqueid in a cookie/localStorage on a Laptop/Device and also in my DB so i can recognize it in the future.
I was hoping, to be able to get a unique ID from the machine/device that is static and specific to machine/device so that I can use to track it. My concept would mean that a user would have several devices/machines that i have logged in from.
I will also be capturing the IP but i don't want to use that Key to identifying a user.
The chances of getting a precisely unique identifier from a browser is slim to none. There are many privacy risks associated with browsers providing a unique identifier string. However, you can always generate a random GUID for a session a user establishes, and store it either as localStorage or as a cookie.

How to Save a file at client side using JavaScript?

I want to save a JSON object to a file at client to persist it for future usage, I have tried following line
window.open("data:text/json;charset=utf-8," + escape(JSON.stringify(obj)));
and it works!! Problem it asks user the location and name of the file for saving. What I want is I want the user completely unaware of the fact that something is being saved for future use or atleast keep it to minimum possible user clicks.
How can I give the file name and location statically in window.open() ?
Thanks in advance,
EDIT
Just to make it clear that " I don't store arbitrary or unwanted data. All the users are registered users of the system." In normal conditions I don't store anything locally. However I want to store some JSON objects if the network was not available at the time of form submission.
One obvious solution will be to use cookies. Since Cookies can be accidentally deleted due to user's browser settings. I need a way to persist the data till the network becomes available. It will be greater to have cross browser support.
If you want to persist data, then use a storage API, you can't play games with the user's filesystem.
You can't do that, it is a question of security on client side.
I want the values for cross-browser support, even if the user changes the browser he/she should be able to proceed from where he left. I am storing information in JSON objects.
I think users don't expect a web application to share information with other browsers on the same machine this way. Also, I doubt many users change their browser too frequently anyway to warrant a privacy-invasive feature like this. You should either consider storing the information on your server (by forcing a user to register or using common accounts like OpenID, Google, Facebook etc.) or on the client side by setting a cookie or using the mentioned storage technologies.
If you really want to restrict stored information to browsers on the same machine, and don't want to permit access by the same user on different machines, you could take a look into LSO ('Flash cookies') which seem to be saved browser independent. You don't need any user confirmation for storing LSOs.
Update: Flash isn't supported by browsers as it used to be and not widely used nowadays, so LSOs aren't a good option any more.
FileSystem APIs is part of HTML5 spec and it is possible to access file system in a sandbox for a certain website in modern browsers, here is a good tutorial:
http://www.html5rocks.com/en/tutorials/file/filesystem/
However I would go with LocalStorage API for that matter which has better browser support:
http://www.w3schools.com/html5/html5_webstorage.asp
FSO.js wraps the temporary/persistent FileSystem API and will allow you to easily read/write files... only supported by Chrome right now, but the spec is coming along fast. :)
As has already been mentioned in the comments, this is not possible without express user consent for obvious security reasons. however, as also mentioned in comments, you shoudl/could store the information in a cookie which will then be retrievable when the user returns.
something like this would do it
document.cookie="cookie_name="+required_value+"; expires=Monday, 04-Dec-2011 05:00:00 GMT";
obviously the expires time will be as long as you need the information to persist.
hope that helps

Can session storage be safe?

I would like to use session storage to query user data in the database only once and then simply use JS to retrieve it, so I'm thinking about using session storage. My question is next, is that safe?
Please note:
1. JS can't be inserted to pages with forms (forms only accept alphanumeric values) so it can only come from URL
1.1 Query strings like www.website.com/?q=blablabla are not used in php (php doesn't retrieve any data from url)
1.2 Calling js in url with javascript:script... isn't a big concern since the user can only asccess his own data, not to mention that he can already access it - that's the point of user data
1.3 Is there a third way of a user being redirected to the site via a link that contains JS that will than be able to access session storage? i.e.: somthing like - www.website.com/script...
My guess is that only something like 1.3 would be a threat (in addition to that, am I missing something?) but does that even exist? And if so is there a way to prevent it?
Thanks for your time and replys.
You're essentially relying on two things for session storage security:
The browser limiting access only to the javascript on the page from this domain
javascript that is running on the page to be secure
Now there's not a whole lot you can do about No. 1 because that's the vendor's issue and, not pointing at anyone in particular but, most of them are usually pretty good at this kind of thing.
So you can be fairly sure no other code on any other tab, domain, browser or process is going to be able to see your storage object.
However, No. 2 is more difficult, You'll have to evaluate by yourself how secure your page is to script attacks, there's plenty of documentation out there on best practices but you could go on for days. You really need to judge how sensitive the data is versus how much work and possible loss of features it would be to secure against it.
If it's really sensitive data I'd question why you'd risk storing it client side at all and have access only through HTTPS. But you're site should be secured for most scripting attacks because if 3rd party javascript is running session cookies are up for grabs and therefore your server security is compromised too.
Since the session storage can only be read by JavaScript that is running on your page, I think your question boils down to "How can JavaScript be excuted/inserted into my page?" There are two attack methods: XSS, meaning some way to inject JavaScript into your page through posting data to your site. If this data is not filtered, it may insert script tags or JavaScript events into your HTML. There are many ways to do this and to protect against it, so I can't be more specific.
A lesser threat would be to trick the site into displaying or changing information through specially crafted links that call specific actions on your page. This technique is called CSRF. Example: Someone crafts a link to the "change email" page and tricks a user who is logged into clicking this link, this changing the email info in the session storage.
If your application is public, anyone can open the session storage in his browser and look up the names of the keys. So unless they are randomized obscurity offers no protection here.

SAAS per seat authentication

Our company makes the web based application which is priced per workstation.
That means that user/pass credentials should only be used from one particular machine.
Currently what is happening that several users are sharing credentials and we do not have any way to prevent this if they are not doing it concurrently.
The nature on the application is such that user needs to use it once in a while so the inability to work concurrently does not bother the users much and the company loses it's possible revenues.
The application currently is purely AJAX without flash/activeX/Java applets.
The ideal solution would be to read the computer name or IP address of the client with javascript using "Shell.Network" scripting interface.
But this is impossible because of the strict security settings in Internet Explorer. I have to mention that cross browser functionality does not matter and the only browser supported is IE.
Searching google I came across this solution here http://www.reglos.de/myaddress/MyAddress.html but it requires JAVA applet so will not be very convenient.
Are there any other solutions for this?
Your licensing model is not consistent with the delivery model. Change one of them.
Set a cookie on the machine with an id. Retrieve the cookie each time the user logs in. If you see several different cookies alternating for a single user you know you've got something odd going on.
(Of course a single switch may just mean they've moved to a new PC as one off. )
Alternatively, price per usage, 'query' or some other item.
This kind of abuse can probably be detected moderately effectively using the Cookie technique that RichH suggested. At least blatant abuse can be detected quite easily (say 10 licenced users, 100 real users).
But of course, don't lock the user out, just monitor the situation and get your Sales people to call up suggesting that they buy more licences.
We do exactly the same (in terms of licensing and delivery), and I'm sure that you have good business reasons for not changing your model.
Track through sessions per user. Do not allow multiple sessions to a single user. To achieve this you will have to save the session ID into the database and check everytime a user logs in.
To help users who at times have a browser crash and relogin with new session, allow them to sign out their previous session... so you can kill the old session and instead register the new one.
Hope this is useful.
There's no easy answer as your clients (the software) are effectively anonymous and the users are self-identifying.
For IE "locking you out" (I'm hardly an IE expert), but can't the IE settings be set for particular domains? You could simply make it a requirement that the users configure their browsers to give your app superior access.
I don't see any reason why you can't have certain requirements for the users browser (i.e. only IE 6/7/8, these security settings, etc.).

Categories

Resources