OSDev.org

Hey,
I've gotten to the stage where I can easily modify/create HTML pages for my OS to dish out upon request (entering either the hostname or ip into a web-browser). Now, I need to start looking into authentication so that only the intended admin is allowed in.

A few options have come to mind:
1: Only allow the webserver (DiNS) to acknowledge one computer (the server or any other machine on 'that end' of the network).
2: Use some sort of login screen to weed out the people that dont have the right credentials.
3: Use a third ethernet jack as the administration link (webserver only acknowledges request from the console port)... cisco style .

I would really like to stick with a login screen, but are there any easily implemented public domain encryption schemes that would be suitable for the job?

Any other ideas/methods of accomplishing this?

I actually like the third ethernet port option. It means an admin must have physical access to make changes. Although, it also means anyone with physical access to the box can make changes too...

Maybe mix a login screen with the third ethernet port option?

The way I'd do it is to use a login page, or get the browser to display an authentication dialogue box (like you can with most other web servers), and have the user log in with their username and password for their user account on your OS.

Do you want Authentication or Encryption?

http://en.wikipedia.org/wiki/Basic_acce ... entication
http://en.wikipedia.org/wiki/Digest_acc ... entication
http://en.wikipedia.org/wiki/Form_based_authentication

See HTTPS for Encryption.

The problem is not that encryption methods are unavailable - I know how to do RSA by hard - the problem in the US is that many of them are covered by patents.

I did some background research and it seems you can use Blowfish (public domain) and RSA (for which the patent expired)

Combuster wrote:The problem is not that encryption methods are unavailable - I know how to do RSA by hard - the problem in the US is that many of them are covered by patents.

Move away from US -> problem solved. Might be a good idea anyway.

Oh and forget Blowfish (which has some problems) for symmetric.. there's AES (Rjindael) now, which does the trick just fine, with publicly available (PD too) source code (it's often said that you should never attempt to write your own encryption methods unless you're a cryptoanalysist, 'cos a single typo can make it vulnerable, and you really really don't want that). http://www.efgh.com/software/rijndael.htm for example.

Seriously though, for a webserver, I'd use HTTPS, login with a pretty box, and use cookies for session management. The nice thing is that you can develop the pretty login box and the cookie stuff separately from the HTTPS handlers. If you don't want unencrypted admin logins, then just disable access to the login page when using HTTP.

I think the https will help the transport encryption issue alot.

I've been doing alot of thinking over using OTP (one time pad) encryption for the actual password transmit/recieve (within ssl of course).

I read up alot on blowfish and it does have a few core weaknesses due to variable signedness and such. I was unaware that AES was PD, I'll look into that later.

Cookie management will probably be a no go on the browser as I can handle login/state/logout sessions from within the OS, and it also cuts down on the potential cookie stealing or cache usage to re-activate a session. My OS just makes it so that when all the active TCP/http sessions have been FIN'd it waits for about 10 seconds and then closes the login state. So the only time it logs out automatically is when all the browser windows have been closed, or inactive (longer timeout).

I really do like the third port idea though. I'd like to create a mixture. But if I find it is too difficult/sketchy to implement WWW-based encryption, I will just use the 3rd port as the console login.

Browsers very optimistically (In as little as 5 seconds) close sockets to webservers. Cookies exist for a reason, and when done right can be very secure

(Attach a session ID to a cookie; on the web server, attach the client's IP address to the session ID. If the session IP isn't the client's IP, the session is invalid. Also add timeouts, of course)

Out of band management is generally perceived favourably by serious players. If you do implement encryption, it makes sense to go with something fairly industry standard if you have any long term aspirations to integrate with anything else. HTTPS or SSH tunnelling over a dedicated management interface would generally be the way to go. Certificates as opposed to passwords also makes sense. Passwords lead to bits of paper with things written on, people using their kids name etc., or even worse, hardcoded strings in admin scripts

Eddy