3 Reasons Your SSH isn’t Keeping Your Data Transfer Secure


The SSH protocol is a data communication protocol that allows for secure data transfer. SSH follows the lightweight and nimble Telnet platform, which uses simple text and small graphic data. Telnet does not contain any encryption, whereas the SSH protocol is a security protocol. It is a preferred form of secure data transfer in many commercial environments because it is easy to install, easy to maintain, easy to use, and is extremely reliable.

The SSH Protocol started off as an open-source protocol, and quickly became available in many forms – open source as well as commercialized, feature-rich SSH solutions. Any environment using SSH as their data transfer solution is using it for the security aspect. Users need to protect their sensitive data.

However, in some cases, companies claim to have SSH, or put SSH on their software label, but the software doesn’t actually provide the user true security. This is dangerous, because it gives users a false sense of security when their data isn’t actually secure.

Use this guide to ensure that the SSH product you are using is actually giving you the security you need. These are 3 areas to verify before using any SSH – whether it from an open-source origin or purchased from a 3rd party.

Three Reasons Your SSH Server May Not Be Keeping Your Data Secure:

1) The SSH uses Proprietary Encryption Protocols Some vendors use proprietary encryption protocols for their SSH. This is a major red flag and should alert you that your data might be vulnerable. Your application should be designed in a way that standard cryptographic protocols are used. Don’t be fooled by companies intermixing words like “proprietary encryption” or “customer encryption” with terms such as AES, 3DES, Blowfish, etc. “Proprietary Encryption” means that the vendor is using their own proprietary cryptographic algorithm. Encryption algorithms are just a small part of a cryptographic protocol. You can bet the weak ink is in the proprietary component. Why is Proprietary Encryption a red flag? Encryption protocols are extremely difficult to design and are not for the faint of heart. Good cryptography algorithms require complicated mathematics in addition to expensive technologies for development. Standard Algorithm acceptance requires major testing and scrutiny of many brilliant people, as well as peer review and time testing in the field before being accepted as “Standard Cryptography”. Standard cryptography is extremely secure. Vendors that venture to create their own proprietary cryptography are trying to either save time or money. The protocols that their engineers develop are not remotely comparable to established cryptographic algorithms standardized by dedicated agencies. At best, it is arrogant when software vendors believe they can do a better job than the professional cryptographers, and more importantly, it leaves their customers with a “security solution” that is not secure.

2) The SSH is not End to End Some companies claim to have SSH, but when you examine their claim, SSH may only be used within the server, but then use proprietary encryption protocols from the server to the devices. Data is most vulnerable between the server to the devices, so it is vital that the SSH encryption is from the server to the devices. In these cases where it isn’t end-to-end, the weakest link is the transmission of data from the server to the device, making the entire solution unsecure. It is imperative to verify that your security solution is End-to-End, leaving no room for vulnerabilities. If the entire solution isn’t secure, then its not a secure solution.

3) The SSH is using outdated algorithms. In 1995 when SSH was first developed, it used state-of-the art security algorithms. Since then, hackers have gotten more cunning. Advancements in mathematics and computer power continually forces the deprecation of existing security algorithms and ciphers. There have been significant advances in decryption techniques. The majority of the original SSH algorithms are no longer secure. SSH2 came out in 2006, and was adopted as the new standard. For this reason, not all SSH products and implementations are equally secure. Some still use the initial algorithms, which are old, outdated, and dangerous to use. Make sure your SSH software uses up to date, current, and safe SSH algorithms. Companies like Georgia SoftWorks constantly test and research to ensure that their SSH products are only using the strongest, most current SSH algorithms.

Posted in How To's and Helpful Information on Sep 09, 2021



LinkedIn Facebook Twitter