Sign in to follow this  

Security questions...

This topic is 4200 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
So that you get an answer worthy of the share of money you're going to give me, you could include a bit more information about the nature of the connection. It's a raw socket fair enough but is it over a secure VPN? In which case you don't need to worry _too_ much about intrusion.

Why are you pursuing a solution that took you five minutes to come up with? There are so many charlatans giving software a bad name because they charge money for things when they don't know what they're doing.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites

This topic is 4200 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this