Unique web browser identification ID for web contr

2020-02-10 02:45发布

Do web browsers have a unique ID that can be passed on to Perl scripts? (Like a unique serial - like products that you buy in the shop have for example)

For instance: If I install a web browser, can this web browser provide a unique identifying ID to a PHP or Perl script?

The reason I'm looking for something unique is to do the following:

  1. I have a user database with user names and passwords.

  2. The user names / passwords are encrypted and set as cookies to the web browsers of users so that users can log in and out into my web application. (Each web page loaded when logged-in looks at the cookies and grants access if the cookie user/pass is correct)

  3. If a hacker manages to steal the encrypted user name and password cookie from a user he will be able to log in with that stolen encrypted details.

If the browsers of users all had unique IDs to pass on then I could record those IDs and match them each time a user uses his encrypted user/pass cookie. This way if the unique ID does not match (what has been recorded previously) then the user is logged out and asked to manually log in again.

In the event where the encrypted user/pass is stolen the hacker won't be able to get in with it because unique browser ID's won't match. The user/pass cookie is encrypted and the hacker cannot see the user name or password. When the unique browser recorded ID's don't match the web application will ask the user to login manually and the hacker won't be able to login manually because the user/pass he stole is encrypted.


Using IP addresses is a possible solution but a poor solution because many if not most ISP's assign dynamic IPs to the internet connections of their clients.

Using time is also not a good solution because I would like the users to stay logged in on the same computer for weeks at a time (if they chose so) to make it convenient.


Anybody have any solutions to the above scenario?

I've been searching for a way to get something unique from browsers but this does not seem possible. Is it possible or not?

4条回答
▲ chillily
2楼-- · 2020-02-10 03:29

You can store some unique values (e.g.: user id) in the user browser using "Html Local Storage" permanently with no expiration date, and store the same values with info about the user agent in the db.

Then you pass the user agent info with the data in the local storage and match it with the ones in the database...

// store
localStorage.setItem("myValue", "123-abcd");

// retrieve
var myValue = localStorage.getItem("myValue");

I'm not sure how much secure is this approach to identify users, but the Html Local Storage supposed to be accessible for only pages from one origin (same domain and protocol).

There is also "HTML Session Storage" to store data in the users browser for only one session.

查看更多
够拽才男人
3楼-- · 2020-02-10 03:36

Even we can use localstorage, sessionstorage and also cookies as well to implement this.. but wen these data s visble to user, so better to keep this encrypted

查看更多
孤傲高冷的网名
4楼-- · 2020-02-10 03:46

No, browsers don't have a unique ID. There is no such thing. If there were such a thing, it would be an online advertising company's dream!

That said, if you're serving up your site via HTTPS, you can issue your clients with client-side X.509 certificates. These would be cryptographically signed by your organization, so fairly unforgeable. (Though obviously if somebody had access to your client's computer they could make a copy of it - the same would be true of any browser ID number though!) Once the certificate is installed, every time the browser makes an HTTPS request to your website, your website can ask for its certificate, and this can be used to verify the user's identify.

查看更多
干净又极端
5楼-- · 2020-02-10 03:50

Browsers do not have a unique ID, but a good level of fingerprinting is possible. The EFF has measured that, in the best case, information sent by browsers (including the user agent string and other HTTP headers) represent 18.1 bits of entropy, which means if you take two browsers at random, you have 1 chance in 218.1 (≈280,000) that they will have the same "fingerprints". They have set up a website where you can estimate the degree entropy of the information sent by your browser.

Some websites use this. My bank, for instance, stores information about the three browsers I use most often to connect to their website, and ask me additional verification questions whenever I'm not using one of those.

On the other hand, all this information is entirely spoofable: if someone is able to carry a man-in-the-middle attack and steal a cookie, they are able to steal also all the headers sent by the browser, and can reuse them to authenticate themselves on your website. The same would be true if browsers actually had unique IDs.

Your alternative, besides using a connection encrypted with SSL (https) which requires you to either pay for a signed certificate or create a self-signed one that will display a security warning to your visitors, is to adopt better practice against session highjacking.

For one thing, it is not standard to keep the username and password, even if encrypted, in the cookie. What you should do is, once a user has logged into your website, assign them a random, single use session ID which you will store in your database along with an expiration time (which you may extend every time the user interacts with your website), and this to them in a cookie.

If you want an even higher degree of protection, one option is to change the session ID every time the user sends an HTTP request. You could also store a list of IP addresses each user uses to connect to your website, or IP address masks (e.g. X.Y.*.*) if it changes too often, and have them authenticate themselves if they are connecting from an unusual place. If you do this, it is a good practice to ask them "Will you be connecting again from this place?"

查看更多
登录 后发表回答