the best secruity system ever?

Your system is a bit unclear. What, specifically, is the security system trying to keep from happening? What is the purpose of the two randomly named files? Why not just check the password against a stored hash?

Ok, so is this what you're doing?

Admin sets up a computer for use by the employee
1) Runs "setupLogin.exe" or something
2) 2 randomly named files [eg "xsdfre", "sfdg"] are created in login.exe directory One of these contains a user ID. [what is the purpose of storing a user ID?]

User tries to log in
1) User opens up your "login.exe"
2) A login screen pops up if it can find the two files created [how does it know _which_ files to look for? Is it based on the username, so that each username creates a given filename which is looked for?]
3) A 128 megabit hash is created from the username/password combination given [a tad big, are you meaning 128-bit, because wouldn't actually generating that much hash would involve so much salt that it wouldn't be worthwhile?]
4) "login.exe" checks that there's no "cmd.exe" , "telnet.exe", "command.com" running [or does it spawn a seperate process that stops these from being run while you're connected?]
5) Said hash is sent to the server, and access is granted [how long does access last?]


Ok, alright system I guess, but what about the following points:

Each computer is locked onto one userid, is that the intention? - Is that to stop users from pretending to be other users or what?

You use a custom login executable to check all of that stuff clientside, but if you're using a standard protocol, someone could just figure out what it is and write their own variation, or alter their login.exe to not check the two files, or to not check that the exes are running. Similarly, the exe thing would be in a stringtable somewhere probably, or in plaintext.

The check possibly wouldn't actually work. What if someone renames their command prompt to cmd2.exe and runs that? Why would you want to prevent people from using any of those tools when on your server? Why can't they run it later?

Also, what's to stop someone just breaking into your server in the good ol' fashioned pwning way? I mean, if the data's there on the hard drive, what's to stop them from grabbing that directly?

Similarly, I would never be confident in your use of the word 'perfect' for a security system. The only way to have a perfectly secured server is to not have it connected and locked in a good safe or something.

Similarly, what kind of data are you trying to protect [and where is your server located, and where are the users located, and is the server connected to an untrusted network]?

Just two cents,

--CJM

ah nice point

but i have safe guards when refreased login.exe checks its source if anything has been changed it sends a warning message of to the server.

these two folders are in diffrent spots each with a encryption because honestly what are the chances of guessing the right folde name there must be billions of combos on every computer.

when loging in login.exe won't let any files run at the same time and acces runs untill the user logs out or opens an unortherised program with out unortherisation eg. telnet.

Quote:

Why not just check the password against a stored hash?

it is on'y inside one of these two folders.

The whole purpose of this system is to stop unortherised computers (not people) onto the system.

Another feature is that the system won't allow active content unless an admin gives permission to it which is the perfect way to stop spam and viruses

Quote:

Original post by gamerking The whole purpose of this system is to stop unortherised computers (not people) onto the system.

Why can't you just filter by MAC address? AFAIK it's unique to every computer and cannot be faked (it's programmed into the hardware IIRC).

Quote:

Original post by desertcube Quote: Original post by gamerking The whole purpose of this system is to stop unortherised computers (not people) onto the system. Why can't you just filter by MAC address? AFAIK it's unique to every computer and cannot be faked (it's programmed into the hardware IIRC).

You can spoof a MAC adress. It is programmed in hardware, but the driver retrieves the MAC adress from the hardware and then uses it.

It isn't difficult to get an ethernet controller that requires software to supply a MAC, and many home-use routers have such functionality built into their admin interface (meant for connections that require a specific MAC for the connection to work).

It's very easy in fact:

(on linux): ifconfig hw ether

/Nico

I think at least 40% of ethernet cards have reconfigurable MAC addys. Also, the addresses arent totaly unique, but it is very rare that you will find two identical mac addresses.

I bet your 128 mbit encryption is really slow. IMHO your method waay unnecessary. Are you defending against key loggers?

Quote:

Original post by Sneftel Your system is a bit unclear. What, specifically, is the security system trying to keep from happening? What is the purpose of the two randomly named files? Why not just check the password against a stored hash?

I'd say just a tiny bit even.

Quote:

Original post by desertcube Quote: Original post by gamerking The whole purpose of this system is to stop unortherised computers (not people) onto the system. Why can't you just filter by MAC address? AFAIK it's unique to every computer and cannot be faked (it's programmed into the hardware IIRC).

MAC addresses can be spoofed very easily.

Im not sure i even understand this security system, and i really cant understand the point of these two random files that have been created. When are these two files created? How exactly will it make sure that authorised users have these files but unauthorised users wont? How does it differentiate them?

im assuming you mean 128 bit encryption and not 128mb. Encryption is always good, so i wont complain there. This extra pop up....how does it make sure that dos/prompt/telnet arent running? What happens if you just rename the executable to something different?

There is no such thing as a perfect security system. Not only do i believe that your system is far from perfect, but i dont even believe you are running it.

Incidentally, there are probably tons of potential security problems with your system, but since i dont know how your network is structured then its very difficult to say.

This popup doesn't let anything run execpt the login process

Quote:

Original post by gamerking This popup doesn't let anything run execpt the login process

. . .
Why not?

Quote:

Original post by gamerking but i have safe guards when refreased login.exe checks its source if anything has been changed it sends a warning message of to the server.

Those safeguards can be removed from the client program, or even simpler and as previously mentioned, one could just write another client program that uses the same protocol to speak to the server.

Quote:

Original post by gamerking these two folders are in diffrent spots each with a encryption because honestly what are the chances of guessing the right folde name there must be billions of combos on every computer.

It doesn't matter - anything that your program does with the file system/registry, etc. can be tracked... easily in fact. See sysinternals.org for simple tools to monitor file system, registry, network, etc. access.

Quote:

Original post by gamerking when loging in login.exe won't let any files run at the same time and acces runs untill the user logs out or opens an unortherised program with out unortherisation eg. telnet.

It won't let *anything* else run? This seems rather hard to enforce for one, and another is that you have to let services run... several are required for the OS to work. Again, I don't see how you could enforce this...

In any case just remember the goal of security: it only needs to be as good as to make it more expensive (in time and/or money) to break than what someone would gain by breaking it. I don't know what you're trying to protect here, but I'd suggest just using an encrypted hashed password system to start with, and work from there. Anything that you try to enforce with the client executable can be bypassed... most of it fairly easily. Even companies that devote their existances to writing such client environment verification software have had limitted success as best.

read some of bruce schneier's stuff, it'll clue you in on how utterly pathetic almost any "perfect" security is.