1

Introduction:

I am in the process of building a web-based game that requires user authentication. The vast majority of other gaming sites utilize the typical username/password method for authentication of users, however, knowing that gamers are typically lazy folks, I have thought about using a new kind of authentication that would instead profile each users computer using parameters such as local IP address, network hardware address (MAC), installed system font names, OS type and version, among other hardware and software properties in order to attempt to create an adequately unique and difficult to impersonate fingerprint that will be tied via hashes stored in a database to a given user account.

Question:

Are there any obvious pitfalls to authenticating users in this manner?

Would this, plus a basic pin number, be enough to protect user accounts from being hijacked by other computer-dextrous users?

This idea originated from this project: https://panopticlick.eff.org/index.php?action=log&js=yes

adv
  • 113
  • 3
  • Just an FYI, MAC addresses are not transmitted over the internet. You would not have access to the client MAC unless they are on the same subnet as you, you lose it at the first router unless using layer 2 tunneling. – David Houde Apr 20 '14 at 06:11
  • You shoud definitely read this answer: http://security.stackexchange.com/a/2210/9604 , it's about crypto-systems but applies as well to your situation. – ack__ Apr 20 '14 at 08:01
  • @David: It (the MAC address) is when I have the users download a Java applet that collects local system/LAN specs, wraps it up into a SHA-512 hash, and POSTs it to my webserver. – adv Apr 21 '14 at 14:51

1 Answers1

4

The browser fingerprint is public information for any site the user visits, so this information should be treated simply as a 'username' and nothing more.

The problem here is if the user changes computers, browsers, or settings they may be locked out of their account. There may be ways around this, but then you veer from your path of simplicity.

The other problem is with a PIN for a password. When using a PIN for a password, the entropy is significantly reduced and would be easily brute forced. Unless you are requiring your users to have a 20+ character PIN, this is highly insecure.

These are major flaws with your idea, though it is novel to say the least. Whether or not you implement this would really depend on the nature of your game, the users, and the required security. It is not a system that I would put ANY trust in, but whether or not trust is required is up to you.

David Houde
  • 5,464
  • 1
  • 27
  • 22
  • 2
    Heck, the user may not even be in any control over some of this - ie, a Windows update will change the OS version, the browser version, fonts may be removed (or renamed) for licensing reasons, ip addresses are usually dynamically assigned by the ISP.... MAC addresses are known to have duplicates, too. And of course, the client can just flat-out **lie** about any of this anyways. – Clockwork-Muse Apr 20 '14 at 03:33
  • @Clockwork-Muse Yea, I am aware of the fluid nature of all of the properties that I would be collecting. So long as these properties do not change frequently, I would be able to avoid forcing them to revalidate their computer fingerprint hash with a username/password (or perhaps a time-limited email or SMS code). Based on the responses so far, it looks like I will have to include some kind of traditional authentication, but I might be able to avoid it some of the time in cases where the computer fingerprint hash does not change... something like a "cookie". – adv Apr 21 '14 at 14:57
  • Then why not just _give_ them a cookie? – Clockwork-Muse Apr 22 '14 at 00:33
  • Because they can manipulate it. But more because I've never really liked cookies, and I want to find another way around it. Ultimately, if people hack each other's game accounts, it will not be the end of the world, so this is a "safe"-ish experimental environment. If I were storing credit card numbers/SSN/etc., I would not experiment. – adv Apr 23 '14 at 23:34