Get the serial number of all visiting devices

Short answer is that you can't.

The server can only use information that the browser sends to it, and there are no serial numbers that are sent by the browser.

There are many different serial numbers on a single computer (one for the motherboard, one per hard drive, etc) but standard web browsers don't send any of them.

Thanks Gonzo. You've always been GREAT. I just hope you are wrong, but I fear not.
Doesn't $_SERVER['REMOTE_ADDR']; fall into the same category? Is it browser dependent too?
Thanks,
Sas

The REMOTE_ADDR is the IP address of the device that is talking to the web server. 

It is there as part of the network communication packets needed to determine where the packets should be sent.

Things like serial numbers and MAC addresses are not part of that information. The end user would need to be running a custom plugin or custom browser in order to send other non-standard information.

However, even if that information were sent, it wouldn't improve security because anyone could forge a duplicate request containing the same information.

Typically session cookies are secure enough for most situations. If you're concerned about session hijacking, you can always try to implement 2-way (client) SSL. It's complicated to implement, though, so it's not something you would use for a regular public website.

Agree with expert. Closest you can get is depending on the cookie for the web traffic footprint from the source. in fact, there will be reliant on the browser since that would be the primary tool to surf the website. To have tighter bounding, token binding or device bound session will be closer to intent as the cookies are bounded to the session and device with specific private key that is stored securely in device. The key is used to sign the cookie so that it is unique to the device. Some provider already has such similar implementation which enforce with authenticated session of the user. 

(MS with token binding using its conditional access policies) 

https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-token-protection

(Cloudflare uses binding cookie with app token authentication)

https://developers.cloudflare.com/cloudflare-one/identity/authorization-cookie/#binding-cookie

(okta protecting the token using DPoP, Proof-of-possession )

https://www.okta.com/blog/2023/06/a-leap-forward-in-token-security-okta-adds-support-for-dpop/

(Seems more on chromium approach though not seen it in action)

https://github.com/WICG/dbsc/blob/main/README.md#high-level-overview

The general flow of a secure session is as follows:

1. The website requests that the browser start a new session, providing an HTTP endpoint to negotiate registration parameters.
2. The browser creates a device-bound key pair, and calls the registration HTTP endpoint to set up the session and register the public key.
3. The server responds with a session identifier, and instructions on how to maintain the session. This is a (possibly empty) list of cookie names that the browser is expected to ensure exist, and their associated scope (origins+path).
4. At a later time the session is closed by either the server requesting to close the session or the user clears the keys by clearing site data.

you can get some quite unreliable information on some devices through client side scripting using mobile apis.

this goal tyically involves distributing tokens the browser needs to keep and use when it connects again. trivial versions would store a simple cookie. 

better versions would handle replay attacks by generating new tokens based on nonces and some shared secret.

Hey Gonzo!
I think you have enough material here for a BLOCKBUSTER movie! Produced and directed by The GreatGonzo.
I can watch this movie a number of times and not get bored.
It's exciting! No kidding. As Joe Biden would say "I'm serious."

I've been using a version of the IP Address approach, which seems to function properly "most" of the time. Occasionally I get a warning that something stinks. So it needs improvement.

Your use of sessions is now something I need to explore in greater depth.
Would you point me in the direction of where I can learn how to use session_start(); to do exactly what you propose?

Looking forward to your Oscar Nomination,
Sas

a basic approach is to store the ip in the session and possibly some kind of fingerprint of the browser based on headers. but that will not restrict to specific devices if that is indeed your idea and you still need some kind of anti replay attacks since we all got stupid enough to use session tokens in the past years rather than challenge responses.

-1 for cloudflare for this specific use case. xperience clearly demonstrates a bot can trivially go through while some of the browsers and devices i use do not. checking you are human is not what cloudflare does. i sometimes end up coding with netcat to bypass their very annoying and stupid reverse turing tests. on the other hand, their dos protection is good.

i do love the script for the movie. on the other hand, the number of possible session tokens is hardly significant beyond some sane minimal length and 1 or 2 way ssl handshakes do not exist.

if uou have low level access to tcp level, forcing http1.1 on a single authenticated session is quite efficient though only practical with builtin browser auth with digest or kerberos.

Don't use IP addresses for any kind of validation UNLESS you can do whitelisting.

It is more and more common for people to be mobile during the workday, so you can have people who are changing their IP addresses throughout the day. For example, a couple weeks ago I started a call on my phone while on my home network. During the call I decided to run a quick errand, so I hopped in my car. As soon as I was far enough from my house, the phone switched over to my mobile provider's data connection (new IP, same device). Once I got back to the house, it switched back to my home IP.

If I was on a VPN, then that would help consolidate these different connections so my IP didn't change across the different connections but that's not always the scenario.

Meanwhile, my normal employer has certain internal functionality that is ONLY accessible via their VPN.

There are also users who have load balancers in front of their connections that can swap their outbound public IP pretty frequently. (Not all balancers do it this way)

You can always try to revalidate a user if their IP changes but it will cause issues for users behind those load balancers.

You had asked about sessions. Here's my own beginner-level tutorial on them:

https://devunit.com/2022/01/05/php-sessions-in-plain-english/

@skull - "1 or 2 way ssl handshakes do not exist" - I'm not sure if I understand what you're saying or if you're just trying to be specific about terminology? One and two way SSL authentication definitely exists...

In fact, the US military uses two-way SSL authentication every day in the form of CAC smart cards that contain a PIN-secured keypair, with the public certificate issued by the DoD CAs.

@gr

i would not debate about changing ips. that depends a lot on the needs are and we have no idea what the author is after. i personally rely quite a lot on dynamic opening of ports or tunnelling through existing public apps. you would send a sequence of udp packets or possibly some otp though a  single udp packet or maybe authenticate and use a hidden url in some app to trigger the temporary opening of some port or redirection of an existing one from your ip for a single connection for a few seconds. those can be viewed as backdoors and are usually stealth. such techniques usually use a 1 time 1 factor auth but 2 factor is totally achievable as well.

regarding ssl, i am unsure what you mean. regular ssl is a 4 way handshake. mtls with preshared keys is 2 way.

i do not know much about CAC but would assume they contain one ore multiple password protected certificates and some biometric user data. the auth mechanism would be similar to mtls. 2 factor would be builtin as the certificates are pin protected and multiple other factors could be added based on either the information contained in the card or in some db or both. hopefully they do just a little better when needed as this would be quite ordinary security rather than military grade :)

Hi,

Sensitive information should not be available in a web application for security reasons (check regulation in your country).

If you want to display private information for example wholesale online store this is different.

In any case you should make test the application for security to cover Owaps top ten to make sure it is secure, you can use Burp Suite Pro or other similar scanning tool or hire a pentester.

Once the application is secure you can improve security using 2FA, not allowing self registration, increase password complexity etc.

If you don't have any backend code yet I would recommend to start with this script, this is is well coded.

I'm using the plain PHP version it for my project, I have improved it over the time but this is a very good script to start.

Plain PHP with Ajax
https://codecanyon.net/item/advanced-security-php-registerlogin-system/5282621

Same author PHP Laravel
https://codecanyon.net/item/vanguard-advanced-php-login-and-user-management/14521866

interesting but they lack challenge response. we are quite far from the original topic ;)

@skull - we're talking about the same thing but different terminologies.

Two-way SSL and one-way SSL refer to the identities authenticated, not to the number of overall steps in the handshake.

So:

One-way SSL = server identity is verified = traditional/regular SSL / TLS.

Two-way SSL = server and client identities are verified = mutual TLS, aka mTLS.

In regards to the part about changing IPs, you mentioned UDP packets and dynamic ports. I didn't quite follow how that relates here. The OP was talking about securing pages on a website, so I'm presuming the client app is a standard web browser. So while there are already dynamic ports opened on the client side for typical browser-server communication, the reference to UDP makes me think you're referring to a custom client and maybe you're talking about a custom way for the server to re-verify the identity of the client...? To be clear, I'm not arguing or anything, just trying to understand what you're saying.

@lena - "Sensitive information should not be available in a web application... If you want to display private information ... this is different."

Can you elaborate here? 

<< @skull - we're talking about the same thing but different terminologies >>

yes. totally. i figured that ;) the word handshake is not commonly used the way you use it but your points are indeed valid imho.

<< you mentioned UDP packets and dynamic ports. I didn't quite follow how that relates here. >>
agreed again. that would just be one option to allow access to a hidden admin ui. but i have no idea what the op is trying to secure so that may not apply at all.

it might help to know more about the actual context and issue at hand. from what i gather mtls could indeed be a way.

This movie has turned into a Netflix series, and worthy of an Oscar.
Although much of this is above my pay-grade I'm going to explore the cookie approach first.
I think it's something I can actually grasp.
I want to offer a special thanks to the excellent cast of characters.

Again, thanks for all the help, and may the best episode win.
Sas

This movie has turned into a Netflix series, and worthy of an Oscar.
Although much of this is above my pay-grade I'm going to explore the cookie approach first.
I think it's something I can actually grasp.
I want to offer a special thanks to the excellent cast of characters.

Again, thanks for all the help, and may the best episode win.
Sas