Here's the idea: If I can get something unique about a puter with JavaScript from an HTML page (probably the MAC address), then can I use this data as another security check? Is that possible?

I am not going to check the puter at client side, i am going to send it to server to check. If nothing sent, user will be blocked. So it is not something that any developer+firebug bination can bypass. I just want to send one more string with username and password which is unique to puter and no one else knows if they don't entered to the system from that puter. Like a password hidden from user itself.

Here's the idea: If I can get something unique about a puter with JavaScript from an HTML page (probably the MAC address), then can I use this data as another security check? Is that possible?

I am not going to check the puter at client side, i am going to send it to server to check. If nothing sent, user will be blocked. So it is not something that any developer+firebug bination can bypass. I just want to send one more string with username and password which is unique to puter and no one else knows if they don't entered to the system from that puter. Like a password hidden from user itself.

• javascript
• html

• 1 Check this out: panopticlick.eff, does a 'browser fingerprint test' to tell you how unique your browser configuration is. – Dunhamzzz Commented May 5, 2011 at 13:20
• @Dunhamzzz: GREAT! :D but still not enough :( – gkaykck Commented May 5, 2011 at 13:21
• 2 You might get better responses if you clarify your question. Specifically that you are looking for an authentication system, can use HTML 5 file-system calls and that the users will be opting in and fully aware of the filesystem access requirement. At first glance, I thought this sounded like you were just trying to hack your way through the browser sandbox into private puters without user knowledge. – peteorpeter Commented May 5, 2011 at 13:32
• no it's not like i am trying to hack into anyones system without their permission. I have doubt's with file sending and checking system because it needs user interaction, and especially users mustn't lose the file i sent, which is very likely. I may ask for permission, they are going to give the permission BUT more than clicking a button is far more plex for average user, especially in this APPLE era – gkaykck Commented May 5, 2011 at 13:38
• 1 @gkaykck: Interesting, but consider these scenarios: I have accidentally deleted the unique file from my puter/I got a new puter/I lost all data/I'm working from two different puters at different locations. Now what? My data wasn't hacked or stolen, I still know my username and password, except I can't login because my login is tied to the one piece of unique data which is not accessible (maybe it doesn't even exist anymore). – Piskvor left the building Commented May 5, 2011 at 14:39

3 Answers 3

• You can try using a tracking cookie; note however that such mechanisms are considered transient (e.g. cookies can be erased). In-browser JavaScript is sandboxed so that it does not have access to ponents outside the page. Note also that any feeling of security you'll gain with JavaScript is illusory - the script runs on the client side, where it can be modified (therefore there's no way to tell whether the "unique" piece of data is genuine or faked) or disabled altogether.

• If you're trying to prevent random people from hacking at your app, you may want to ban them after a certain number of failed attempts. This will not get you any security, it's more of a flytrap - it limits the annoyances somewhat.

• Finally, if you want actual security, go for HTTPS with real (NOT self-signed) server certificates and client-side certificates - see e.g. this for an implementation (that example, however, uses self-signed server certificates, which is not very secure). This is a mechanism that is well-implemented in the browser itself, and provides you with a somewhat secure system (plete with a secure keystore) of identifying your users (as opposed to a fundamentally flawed JS "security", or relying on user-readable files). Oh, and your data is encrypted while on the wire, that's a bonus.

SSL actually does what you're asking for: verifies that the client machine has a certificate issued to that user. This mechanism works inside the browser, not just inside the webpage; thus, it is much harder to subvert this than an in-page JavaScript. It stores a large unique identifier (clientside certificate) in a secure way, and it can prove to the server that it actually has that identifier - which is pretty much your initial requirement.

(Incidentally, using SSL, the data will be protected in transit, and the client can validate the server's identity; those weren't your requirements, but they're more or less necessary to assure that you're actually talking to the real client and real server)

JavaScript within a Web browser executes within a sandbox and has no access to the underlying hardware. Besides, MAC addresses aren't guaranteed to be unique.

No. And you shouldn't implement security with JavaScript only as any petent developer with Firebug will get around it in no time.