Look, I know that Internet security is complicated. But let's not make it worse by committing silly human errors that poke enormous holes into that security. And I'm not talking here about ordinary end users who don't always know any better. I'm talking about IT professionals who should know better -- at least by instinct if not by explicit knowledge.
What set me off on this rant? Secure shell (SSH) -- one of the most basic and commonly used IT tools around. I swear, if somebody emails me another private SSH key I'm going to scream.
Here's an example of how a the "secure" part of SSH gets ripped to shreds through sheer carelessness.
Suppose I work for Company A, and I need to gain access to the secured FTP (SFTP) server at Company B. I generate an SSH key and give it to the appropriate admin at Company B who configures its SFTP to accept the key. That runs counter to our real-world intuition, where it's the owner of the building who has to give out the keys, not the people seeking to gain access to that building.
But it's even more complicated than that, because on the Internet, keys are asymmetric -- that is, one key is used by the sender and a different key by the receiver. In the FTP example above, Company A generated something called the private key, and using that key they then created a matching public key, which is what they sent to Company B. That way, when Company A tries to log into Company B's SFTP, the server knows that only one private key could match the public key. That guarantees the sender (Company A) is who they claim to be.
However this all assumes that Company A has guarded its private key properly. I cannot count the number of times somebody from another company has emailed me their private key instead of just the public half. That means anybody snooping on our Internet traffic could have gotten the private key and the whole security model is broken. The bad guy simply uses the private key to break into Company B's SFTP server, and nobody is the wiser.
All I'm asking is that people use a little common sense. If you have just been told to use some tool to generate a "private" key, think a minute before you email that thing out to anybody, much less everybody on your project team. There's a reason it's called a private key, and even if you don't fully understand the protocols involved, it should tickle your common-sense bone when you hear it called a private key.
Don't be embarrassed to ask the other members of the project team what to do next. Somebody should be able to tell you what to do next, so that you don't accidentally compromise the security of your brand new key.
And if you manage a project team -- or even an entire enterprise IT department -- don't hesitate to ask whether your team members are following basic, common-sense security policies. You might be surprised, and disappointed, at the answers you get.
What set me off on this rant? Secure shell (SSH) -- one of the most basic and commonly used IT tools around. I swear, if somebody emails me another private SSH key I'm going to scream.
Here's an example of how a the "secure" part of SSH gets ripped to shreds through sheer carelessness.
Suppose I work for Company A, and I need to gain access to the secured FTP (SFTP) server at Company B. I generate an SSH key and give it to the appropriate admin at Company B who configures its SFTP to accept the key. That runs counter to our real-world intuition, where it's the owner of the building who has to give out the keys, not the people seeking to gain access to that building.
But it's even more complicated than that, because on the Internet, keys are asymmetric -- that is, one key is used by the sender and a different key by the receiver. In the FTP example above, Company A generated something called the private key, and using that key they then created a matching public key, which is what they sent to Company B. That way, when Company A tries to log into Company B's SFTP, the server knows that only one private key could match the public key. That guarantees the sender (Company A) is who they claim to be.
However this all assumes that Company A has guarded its private key properly. I cannot count the number of times somebody from another company has emailed me their private key instead of just the public half. That means anybody snooping on our Internet traffic could have gotten the private key and the whole security model is broken. The bad guy simply uses the private key to break into Company B's SFTP server, and nobody is the wiser.
All I'm asking is that people use a little common sense. If you have just been told to use some tool to generate a "private" key, think a minute before you email that thing out to anybody, much less everybody on your project team. There's a reason it's called a private key, and even if you don't fully understand the protocols involved, it should tickle your common-sense bone when you hear it called a private key.
Don't be embarrassed to ask the other members of the project team what to do next. Somebody should be able to tell you what to do next, so that you don't accidentally compromise the security of your brand new key.
And if you manage a project team -- or even an entire enterprise IT department -- don't hesitate to ask whether your team members are following basic, common-sense security policies. You might be surprised, and disappointed, at the answers you get.
