Hacker News Reader

Comment by benmathes | Hacker News Reader

The short answer is that it is that hard to fully prevent it from happening. For practical purposes, IT security's job is to make it not worth the effort to break in.

And even if you've built a really secure system all it takes is one user with their daughter's name as their password to make it all moot.

View on HN

> one user with their daughter's name as their password to make it all moot.

I see what you did there.

> And even if you've built a really secure system all it takes is one user with their daughter's name as their password to make it all moot.

If your security design allows anyone to SSH in to obtain significant system access using only a user selected password, it isn't "really secure."

likewise, you could prevent your users from creating such passwords.

What if you only have one "user" who only logs in through SSH using port knocking and all of the server's other communication with the rest of the net is through encrypted binary data in UDP packets with fixed-size fields?

Then you're fired because the server doesn't actually work.

Then you're fired because the server doesn't actually work.

If I were interviewing you, your answer would be considered nonsense and would cause you to not get hired in the first place. I actually need to write such a server for a product I'm working on. All it ever does is encrypted communications with other machines.

OK, you're right. You'd only be fired in the other 99.9% of cases, where servers have to support standard protocols and normal users.

99.9% of cases, where servers have to support standard protocols and normal user.

True. True for all small and big companies' IT. But if you are a security or even just a forensics firm, then you ought to be in the other 0.1%

OK, so then forget your "super secure" server. I would instead focus on compromising one of the admin computers that has the "special user" ssh key and the port knock sequence; or maybe I will hit one of the servers communicating with this "secure" computer and see if you remembered to bounds check all the data coming in; maybe even see if you network stack has any exploits in its tcp/udp implementations while I am at it...

OK, so then forget your "super secure" server. I would instead focus on compromising one of the admin computers that has the "special user" ssh key and the port knock sequence

Juicy! [making notes to buy a laptop for the express purpose of logging into the server]

maybe I will hit one of the servers communicating with this "secure" computer and see if you remembered to bounds check all the data coming in

All fields are fixed length.

I have to wonder why you consider port knocking to be a useful security-usability tradeoff. If SSH alone isn't "secure" enough for you, then adding a port knock doesn't actually lift it over that boundary.

I just feel better that most of the time, other parties won't be able to even see the actual port.

That sounds like a bad balance of usability to security.

The entire purpose of the machine is to manage session keys. Yes, this is part of a system that will make money. No, it's not a web app. Warning: answering programming/security questions as if web apps are the whole of computing won't win you points with everyone.

Well, for the highly specialized purpose that I didn't know about before you explained it in this comment, your solution works.

And for seeing if someone has the knowledge and imagination to come up with such a purpose, I think I've found a good filter.

Reply on news.ycombinator.com