Client/Server

[Slavi]

Hey guys,
Just got a quick question ... I am implementing a client GUI, and part of the requirements are that the client is able to start, stop and restart the server. This got me a bit confused since the client connects after the server is running. What I am thinking now is do the mean disconect the client himself if he presses Stop? and make new one if he presses start after? Here is the definition I've got given

start(); // starts the print server
stop(); // stops the print server
restart(); // stops the print server, clears the print queue and starts the print server again

If it actually interacts with the server itself, how would that happen? :o For my communication I am using Java RMI

[JamesCherrill]

There's no way the client should be starting or stopping the server that is handling the communications with the client! Maybe your problem comes from confusing the server that talks to clients with the server that talks to the printer? In my mind they are two different things.

[~s.o.s~]

Since you need to start and stop the server, you might actually need two servers -- an admin server and a print server. The admin-server manages the print server and the client only sees the "admin" server which acts on the admin commands and passes on the rest of the commands to the actual print server.

It seems like a weird design to have normal clients have access to "admin" functions on the server. A more logical design will be to have two GUIs -- an admin UI and a usual client UI. The client can queue/un-queue/restart jobs etc. but when it comes to adminnistering the actual server, you use the admin-console/UI which would require admin credentials. The admin UI will be directly hooked to the admin-server (which in turn still controls the print server as mentioned in my previous suggestion). The client UI will directly interact with the print server but will have access to limited actions.

[Tarek_2]

I agree with JamesCherill, it can be a design problem, and the solution you propose is probably false : restarting a server aims to clear the cache or to erase temporary data; disconnecting and reconnecting the client can't guarantee that.

[Slavi]

Hey guys,
thank you for answering

Yeah, I found it weird as well that's why i wanted to input from you :), I don't understand what is the logic behind client being able to do that. I am considering to just skip those methods and maybe ask the teacher what exactly he means by that and I guess it will be as you guys proposed, having a second server ...

Also maybe you could give me some ideas on my next thing ...

When clients connect to the print server, they need to be authenticated as well or they won't be able to print otherwise. My idea is to have a method that returns a boolean but I need to consider how to store the passwords on the server side. I could use a database, file with hashed passwords etc ..
I am thinking of having a file with hashed passwords but I don't want to have the passwords just MD5'd for example. It's been proven to be broken so I want a bit more secure system. I was thinking about salting the password but I have no clue at the moment how to store the salt, would it be in different file maybe and assign it to the username?

Also, are there any cryptographic hashes that are already defined and we could just use?

[JamesCherrill]

I wasn't suggesting a "second server" as a separate program necessarily. I was just making the logical distinction between the two types of "serving" that are going on. I see no problem having one "server" program that is always runing and communicting with clients, and has a print queue that can be stopped, started etc.

[Slavi]

Oh, yea that sounds pretty nice actually.
By the way James, could you suggest anything on the authentication problem as well?

[JamesCherrill]

This web site has an excellent article on how to store passwords (and how not to, and why). There's nothing I can add to what it says.

[Slavi]

Oh great, yeah I remember reading that article 1-2 years ago, will relook it, Thank you James and everyone!

[~s.o.s~]

When it comes to security, the more your rely on advanced libraries, the better for you. I don't like the site linked by James because there is too much to do. Ideally, for a "real" thing, you would just pick up a library like bcrypt in Java and let the library specialized for password management take care of the salt generation and comparison.

Take a look at this SO question for how simple it is to check passwords using a library/algorithm recommended by security experts (just search around for bcrypt).

Also, are you using a secure connection (SSL instead of just plan sockets)? If not, the entire point of hashing is moot because no matter the strength of the password generation/checking algorithm, if you are sending across passwords in plain text, you are doomed anyways...

[JamesCherrill]

I wasn't familar with bcrypt (until now), so, yes, I agree with ~s.o.s~ - don't write code if you can use properly designed and tested pre-existing code.

[Slavi]

Hey guys,
Yeah I wouldn't try to write my own crypto functions. The link that James linked earlier contains a full implementation of PBKDF2, which is another key scretching algorithm, just like bcrypt. I was thinking I would use that? Looked at the code seems pretty decent. Or, should I go for bcrypt?

Also @sos,
implementing secure connection was one of the advanced stuff that is part of the project, which I am definitely going for as I want to get highest grades only, and I was thinking I'd try to implement SSL after the password is sorted, would that be okay?

[~s.o.s~]

Just use bcrypt, much easier. Also, I'm not really aware of what the project really demands so can't comment on what is OK and what's not. Just for the record, implementing secure sockets is much more involved than doing authentication which might not be what your projet demands. As always, speak with your instructor on what is more important and proceed accordingly.

[Slavi]

It is what it demands, the project is aimed at security :P