|
||||||||||
|
|
A time-limit on encryption?5:20 pm on February 2, 2009 | By Dan Maksim | In brute-force attack, key destruction, password policy, rainbow attack, social engineering | No CommentsThe computational power required to brute-force attack most the most widely used encryption algorithms (RSA, PGP, 3DES) is currently beyond anyone’s reach, provided that a sufficiently large key is used for encryption. Such power should continue to be out of anyone’s reach for the foreseeable future, assuming that: 1. Moore’s law holds true- that computing power only doubles every 18 to 24 months 2. a breakthrough in quantum computing is not just over the horizon 3. no striking advances to currently used factoring algorithms These assumptions are generally considered to be reasonable. The real, immediate risk to most security systems continues to be weak password policies and social engineering. However, what if your encrypted data falls into an attacker’s hands, and an exploitable flaw is found in the way your data is encrypted and stored? How likely is this to happen? If we look at cryptographic systems introduced only ~10 years ago, we see that flaws are often found ~5 years after their widespread implementation, which usually lead to full cracks of the system in the following ~2-10 years. Granted, current encryption algorithms are more robust and have already withstood far more scrutiny than older ones, but breaches do still happen. For example, SSL was recently compromised and attackers were able to create a rogue certificate authority. Encryption alone isn’t sufficient to guarantee long-term security. Removal/destruction of secure data in addition to encryption is preferable. If nothing else, destruction of private keys is a great start.
Passwords are exchanged routinely and even when they aren’t …5:10 pm on January 23, 2009 | By Yuri Yuryev | In identity theft, password security, social engineering | No CommentsOne of my relatives once worked for a large federal firm administering their employee database that included all of the employee personal data, salary, and for some the required monthly drug test results. At the time, the firm was building a couple of new modern interfaces to the database, and my relative, being of the older generation of programmers, quite often asked for my help with the newer concepts. Of course, when he was showing me how he built his interfaces, he also told me the password to that database (which happened to be the same as his laptop password). Up until now, I cringe every time I think of how often things like this happen in every large corporation. However, let’s give him the benefit of the doubt, since I was his close relative, and he knew that I wouldn’t do anything bad with the password. And, frankly, that’s not what worries me. What really worries me is that his password was something like “Charles99” where Charles was my relative’s first name, and 99 was the current year. I don’t break into systems, I don’t use my social engineering skills to gain access to user accounts, and I don’t get any pleasure out of doing things like that; in other words — I’m not a hacker. Nevertheless, I’m guessing that it would take me no longer than 10-15 minutes to guess that “Charles99” password, simply because it’s so easy! In fact, I don’t even need to know any personal information about the owner of a laptop with such password, except for his or her name, which is most likely a part of their stored login anyway. So, the question is: being the System Administrator in this corporation, how do you protect a system like this? There are a couple of ways to enhance password security: 1) Educate your users. Conduct a mandatory security workshop with your users a couple of times a year, where you stress the importance of good data security practices. Describe how a data security breach might directly affect the users’ work environment or salary and use that as an incentive for them to follow the company security rules. 2) Create a strong password policy in your domain. Things like nonalphanumeric characters and no relation to user’s account name are present in the Microsoft’s password complexity requirements as a default. Make sure that you don’t require users to rotate passwords very often; otherwise they will get frustrated and write them down, which will defeat the purpose of the whole exercise. 3) Use a security package with remote kill switch. If the computer does get lost or stolen at some point, the IT Administrator should have a way to either secure or destroy the company data remotely. In this case, the encryption is not going to protect your data if we assume that the password was broken by the thief. But the ability to destroy the data will be an effective tool against data leakage.
|
![]()
Powered by WordPress. Theme designed by Web Hosting at Lunarpages. |