🔒 Locked

Security questions...

Started by slyterence Jun 14, 2006 at 2:08 AM 1 replies 1.2k views

Original Post

Jun 14, 2006 at 2:08 AM

Hi, Political forces are at work in my company and I'm being forced to implement a custom I-just-thought-this-up-in-5-minutes-but-it'll-be-good-enough security solution for our application. I'm very demoralized at this point, and only this blog entry http://www.butunclebob.com/ArticleS.MichaelFeathers.LameDuck is keeping me going. What I'd like to know is, if I have a pure socket connection


m_ServerSocket = new Socket(ipe.AddressFamily, SocketType.Stream, ProtocolType.Tcp);
m_ServerSocket.Bind(ipe);
m_ServerSocket.Listen(100);
m_ServerSocket.BeginAccept(new AsyncCallback(OnClientConnect), m_ServerSocket);

so there's no authentication to ActiveDirectory, no SSL, no encryption, no nothing, what are the potential security holes I face here? Is is possible for someone to authenticate to our system, using our hair-brained scheme, and then have someone else inject messages into the socket stream so that we (the server) can't tell the difference between who's putting in valid data, and who's impersonating? Our hair-brained scheme involves generating a daily key, which is sent to the client as a challenge every time they connect. They then use this to encrypt a couple of pieces of known information, which they then pass back to us. We encrypt the same information out of our database and compare the two, and, if they're the same, then we retrieve their ActiveDirectory password out of our database, which is stored in plaintext. We pass their username, which they supply in the login packet, with their password out of our database, to a .NET AD call which determines simply if their username and password are in AD. If this process succeeds, then we assume they're a valid user, and we trust every further piece of information received on this socket for the rest of the day. So, in order that I don't go out of my mind, and so that our client gets a system worthy of the money they're paying us for, can you guys please highlight all the flaws and holes in the system so that I can pass these along. The first hole I can see is that the daily key is the same every time you connect today. So presumably someone can sniff your login packet, and that packet will then be valid for login for the rest of the day, which would allow unauthorised access for the rest of the day.

hplus0603

Mod

3,014

hplus0603

Jun 14, 2006 at 11:52 AM

Storing secrets in plaintext in a database means that anyone involved with management or backup of that data has a LOT of potential power. How bad for your company would it be if a copy of that database ended up in someone else's hands? Is that a risk you want to mitigate?

TCP stream insertion CAN be done, and HAS been done, but it has to be a pretty determined attacker that does it. It would probably be simpler to insert a man-in-the-middle between the remote node and your application if you wanted to insert data in the stream. Is this a risk you need to mitigate?

If the data being sent is sensitive, then know that, because you send the key up-front, anyone with a network sniffer can re-construct the entire session, including the "known bits" because the key is sent over the network. Is this a risk you need to mitigate?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.