Marco Gaiarin schrieb: (...) > 1) [simple, dumb] Client and server agree on a 'server signature', and > client accept package only on match > This is not optimal, because if someone get a client, hack it and get > the key, we are vastly compromised because someone can build another > server that act as the original one. > > 1b) if you use WPKGInstaller you can access to the WPKG server (share) > with a user and password, rather similar to 1) > > 2) [rather simple, less dumb] Client and server agree on a 'client > signature', client accept package only on match > As 1), but with different signature per client. If a client is > compromised, nothing worst can happen. > On the coons, we have to manage signatures of clients server-side, and > in a secure manner. > Can be seen also as 'like 1b) but with different password per client'. > > 3) [complex, strong] use a PKI infrastructure where alla communication > (clearly, usefoul one) are 'signed' with public keys. Before we start we have to assume one thing: the whole "security" can't be handled by wpkg.js itself, it has to be made by the WPKG Client/Installer. Also, before we start to re-invent the wheel - how does the Windows domain client make sure that it's really the original domain server it's connecting to? A workstation in a domain has a domain account/password, but I'm not sure how it prevents from connecting to a false domain server (which just accepts each and every machine account/password). On the other hand, probably there are some people using WPKG without a domain; just in a workgroup, and it would be harder for them to add such security feature. -- Tomasz Chmielewski http://wpkg.org wpkg-users mailing list wpkg-users at lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users |