Identifying a particular machine from client side?

Status
This thread has been Locked and is not open to further replies. Please start a New Thread if you're having a similar issue. View our Welcome Guide to learn how to use this site.

allnodcoms

Thread Starter
Joined
Jun 30, 2007
Messages
613
Hi Guys,

Hope someone can help me out. I'm writing a web app for a client, and they're pretty keen about security. I'm using PHP for the server side stuff and a bit of JS on the client. They want to limit access to the site / app to a set number of boxes (I know, it's a bit Anal but heh, customer is always right... seriously deluded maybe, and often hideously mis-informed, but always right!).

What I need then is a way of identifying those boxes which are to be allowed access, then send this data (with some form of encryption) with the log-in data. I'm thinking the NIC's MAC address, anyone know if this can be done?

Thanks in advance

Danny
 

allnodcoms

Thread Starter
Joined
Jun 30, 2007
Messages
613
Unless all the boxed have fixed IPs, the only ways, *i think*, are:
With an applet on the client machine (http://www.experts-exchange.com/Programming/Misc/Q_23071697.html)
Or to use cookies with a unique value in. Though cookies can be easily faked etc..

Alternatively, you could have a login box, and the people who are allowed access have usernames & passwords
Cheers Andy,

I use cookies, and user login - it's the unique machine ID thing I'm after. They'd like to know, not only who is accessing the system, but also from which machine. The client side applet sounds the route to go down, but I'm using JS for this and that doesn't have access to the sort of hardware ID stuff I need. I'm thinking of writing a wrapper app in REALbasic or something which can pull the hardware ID's and POST these, along with user authentication data, to the remote PHP page, which gets displayed in a built in Browser interface... It's got bother written all over it, but seems the easiest solution to a picky Client's problem...:rolleyes:

Cheers anyway!

Danny
 
Joined
Aug 12, 2007
Messages
696
Perhaps it would be easier to educate your client on how easy it is to spoof and/or change MAC addresses, etc., then they could see that their "security" measure is pretty meaningless. It's MUCH easier to change the MAC address than to spoof cookies. Using a combination of username/password, cookies, and logging IP addresses is a reasonable start. If they really really really want something that secure, you could move to something like what Windows Product Activation (WPA) uses (see http://www.aumha.org/win5/a/wpa.php), but this will require a client-side executable that has access to hardware information... costly stuff in terms of development.
 

jiml8

Guest
Joined
Jul 2, 2005
Messages
2,634
I think you are displaying a bad attitude with how you describe your opinion of your client's requirements. Personally, I can envision any number of circumstances where a client has a vested interest in ensuring that only specific machines are allowed to access his server.

In fact, I sell an app that has EXACTLY that type of functionality, though I bypass HTTP altogether and do everything UDP over encrypted connections.

The safest way I can think of is a dedicated application on the client, that opens a socket on the client and can therefore be accessed by an appropriate piece of javascript in your client side browser.

That application has within it several different algorithms, and the capability to encrypt/decrypt a key in a specific fashion.

Your server generates a key. This key contains hidden within it a code specifying which algorithm to use to process the key. The server then processes the key using the algorithm and has an answer. It then passes the key to the client machine.

The javascript on the client machine passes the key to the dedicated app, which processes it using the algorithm command that is buried in the key, and therefore gets the same answer as what the server got. Your client browser gets this answer from the dedicated app, and sends it back to the server, which is now satisfied that it is talking to the right machine.

You can send these keys on a per-session or on a per-transaction basis, depending on how paranoid you are.

The dedicated app on the client can be tied to the hardware by, for instance, using the serial number of the hard drive as the identifier for that app that it is on the proper machine. This requires you to compile the app individually for each machine, and to change it if the hard drive is changed. Thus, if the app is stolen, there is a layer of protection to keep it from being used to spoof from another machine.

My app does it differently, using an encrypted config file that is specific to the machine (and won't work if moved). Also, my protocol is proprietary and encrypted from end to end, even using encrypted executables on the client machines to prevent disassembling. Sorry, I won't be specific about how I do it; security through obscurity is a valid technique.
 

allnodcoms

Thread Starter
Joined
Jun 30, 2007
Messages
613
Cheers,

I've been looking at a client side app to handle machine validation, I was basically looking at writing my own browser (which is not as complicated as all that if you use something like REALbasic) and responding to events on the HTML control object to generate the client side, machine specific ID's and add this additional data the outgoing URL. Essentially, the web app would only function if accessed from the dedicated 'pseudo browser', and then only if the machine's / browser's ID's are held in the server side MySQL.

I've got some way to go on this theory, but thanks for your suggestions - they have given me something else to consider.

Danny
 

jiml8

Guest
Joined
Jul 2, 2005
Messages
2,634
In fact, my app does store machine IDs on the server. But it also employs a number of mechanisms (including something like the mechanism I described) to defeat man-in-the-middle and spoofing. Some of those algorithms for validation, you might recognize, COULD incorporate machine-specific information that is known only to the specific machine, and the server.

If you have the option to not use a standard browser with javascript, then this is definitely the way to go. No browser is secure. Period. Even SSL has been cracked and there is hardware available on the market that will facilitate a man in the middle attack against SSL encrypted connections.

If you have the option (translation: budget) then for security UDP is better than TCP because UDP is connectionless and you can configure your client and server to simply not respond - at all - to any improperly formatted packets. Just drop 'em on the floor, use uncommon ports, and no one will figure out what your app is by how it responds when queried. Encrypt the connection. You handle the need to ensure that data has been received by implementing some sort of "ACK" at the application level and, if you send data and don't get an "ACK" in a reasonable time, you resend the data.

It works very well.
 

allnodcoms

Thread Starter
Joined
Jun 30, 2007
Messages
613
Just checked your homepage, think I'll just pass on the link ;)

Yup, I'm writing a cloud based PMS for a small hotel chain. The basic requirements are that various authenticated users can access the entire chain of properties from any of the locations (this is a very localised chain - five properties within a 30 mile radius), at various levels (dependant on access privileges set in an admin panel by global admin), and they want to know which property originated the 'booking' (for example) but would like this to be narrowed down to a specific box within that property. The box would also be part of the access level, so the box in the office would have more clout than the box on front of house for example... You remember my initial post about picky clients?

Global security is obviously a primary concern, the app handles on-line bookings, although credit card handling is performed by a third party, and if a box is not authorised to access the system it should be immediately rejected. They don't want anybody to be able to book themselves in for a month as fully inclusive, pre-paid...

Back to the plot. I'm writing the pseudo browser shell using REALbasic. This has a UDPSocket class that I can (hopefully) use to open a pipe to the remote server, or local if no remote is available (I''m putting a NIX box on the LAN for backups and emergencies). Do I need to do anything server side to accept the UDP connection?

I already use ACK timeouts for 'sending page' validation in the 'user browser' set up I currently have, along with NIX timestamp checks against a predefined date sent with the login data... Nice idea though.

Thanks again for your help, and if you want to drop out due to conflict of interests I fully understand... ;)

Danny
 

jiml8

Guest
Joined
Jul 2, 2005
Messages
2,634
If that is your purpose, then in all honesty your client would save a lot of money by just coming to me. There would still be a requirement for installation and configuration so you wouldn't cut yourself out, but that is what my package does.

And, I must tell you, I've been writing it since 1992. Presently I'm rewriting the whole thing in a completely new and modern framework.

Also, with UDP, there is no connection, so you don't "accept" it. You merely need a server running that watches that port, receives the incoming packet, and does something appropriate.
 
Status
This thread has been Locked and is not open to further replies. Please start a New Thread if you're having a similar issue. View our Welcome Guide to learn how to use this site.

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

As Seen On
As Seen On...

Welcome to Tech Support Guy!

Are you looking for the solution to your computer problem? Join our site today to ask your question. This site is completely free -- paid for by advertisers and donations.

If you're not already familiar with forums, watch our Welcome Guide to get started.

Join over 807,865 other people just like you!

Latest posts

Members online

Top