Web App Get Mac Address

You can't.

If the client system is on a local network segment, you could in theory get its MAC address by inspecting your system's ARP cache, or making your own ARP request. That's not trivial.

If the client system is not on a local network segment - that is, if there are any routers between your system and the client system - then the MAC address is not available to you. A MAC address is only meaningful on a network segment; when an IP packet is forwarded by a router, the MAC address of the originating system is not included. (In fact, the MAC address isn't in the IP packet at all, except under certain unusual circumstances that don't apply to normal traffic.)

With IPv6, IP addresses typically include the MAC address, but they aren't guaranteed to. And most people are still using IPv4.

Hi Michael,

Thanks for that, do you know of any info I could pick up from a visual cobol website app that would identify a particular PC?

Thanks

Neil.

This is one of the great unresolved security problems of our era - which is why shopping, banking, and similar web sites still use a clumsy and flawed collection of authentication mechanisms (mostly passwords).

Ultimately, all you have is a bit of metadata about the client connection (the IP address, etc), and the information the client sends. The metadata generally isn't useful for this purpose: with IPv4, many clients will have IP addresses that change from time to time and are shared by multiple clients, thanks to DHCP and NAT, and even with IPv6 one client can impersonate another.

In theory a properly-administered IPSec setup would let you identify client systems with some probability of security, but few people use IPSec, and having it administered properly is considerably less likely.

So you're left with using some information in the client request to identify the client. Obviously the client can send anything it wants to send, which makes it inherently untrustworthy. So if you want to identify the client with any degree of security, you need at least a few things:

• The client (either the client system, or the user who's using it) must know some secret that other clients don't know.
• The server must know how to verify that the client knows that secret.
• The client needs a way to show the server that it knows the secret, without letting other clients find out what the secret is.
• The server needs a way to associate requests with clients, or the client will have to prove its identity with every request.

The most common approach to solving these problems use on the web is a mish-mash of technologies with at best very limited guarantees of security - but it's better than nothing (at least in theory). It works like this:

• The client and server use SSL (or TLS), with server-side authentication. This provides a few things:
  • The client can (in theory) verify that the server is the real server, and not some attacker claiming to be the server. That prevents an attacker from learning the client's secret. (In practice this has failed a number of times because the industry has done an abysmal job of managing SSL "root" certificates. But no one has a good solution to that problem.)
  • The conversation as a whole can be encrypted, which prevents other clients from learning the client's secret, and also means the server can tell that subsequent requests really do come from this client.
• The server sets a session cookie, which the client will send back with every request. That lets the server know which client sent a given request.
• The client authenticates to the server by sending a username (or email address, or whatever) and a password. That's the secret that identifies the client and proves it is who it claims to be.

Even this approach - which most people use because it's less work than any of the various better alternatives - requires significant effort. And if you don't control the clients, it also means you'll have to purchase one or more server certificates from a known Certificate Authority such as Verisign, so there's capital outlay too.

Pretty much any approach that's technically simpler will be much less secure, or run into other issues, such as export controls on cryptographic technology. Many organizations end up going with what's sometimes called "kid sister security": a little ad hoc code to make it not quite trivial for one client to impersonate another, in the hope that no attacker will go to any significant effort to break the system. So, as with any security question, it really comes down to your threat model: what are you protecting, how much is it worth to you, how much is it worth to an attacker, and what kinds of attacks are you likely to face?