On 1/18/06, Runesabre <runesabre@xxxxxxxxx> wrote: > > > 3. Aside from server security, there is the > matter of account password > > > security. How can I fathom giving away the full > source code and thus giving > > > anyone the ability to network snoop and easily > grab customer > > > account/password data? > > > Web servers are open source, and so are some > browsers, they're both > > capable of secure data transmissions. Being open > source isn't a > > problem. You've just got to use secure data > transmissions, and that's > > it. > > I appreciate the replies from everyone. You have all > been very helpful! (/wave Markku and Tim) > > I'm not a security expert so I'm learning as I go. > What I can't really understand is how a client-side > application can be completely open source and secure > at the same time without giving away its encryption > techniques. I can't afford for every customer to be > issued a SecureId fob like I used in the workplace and > any secret "key" transmitted over the 'net can simply > be intercepted and used with full knowledge of how the > key works since access to the source code is > available. My customers aren't locked to using their > account from a specific machine. 1. The encryption code is open source. The actual keys are not, or should never be hardcoded in to the application. As an aside the size of the key improves security as each bit added doubles the number of possible keys (with out getting too technical). 2. The key is not transmitted "clear text" as many passwords are. In fact public key encryption works based on never transmitting the private key to anyone. > Do open source web servers include the full source to > their encryption routines? What about SSL? Is the > source to SSL open to the public? > Yes. In fact thee respective web sites can get you started on understanding what actually occurs. -- Leonard Isham, CISSP Ostendo non ostento.
