Microsoft Abandons Lesser Crypto Algorithm MD5

Microsoft is in the process of strengthening their security by retiring its use of an increasing dated cryptographic hashing algorithm known as MD5.  You may recall from a previous post of ours that the purpose of hashing algorithms such as MD5 is to employ heavy mathematical principles to obscure and conceal data for use in sending and storing it securely, and also that not all those algorithms are alike.  The 160 bit Sha1 algorithm for example, is considered to be more secure than the 128 bit MD5, and the Sha256 even more so, continuing to Sha512 and beyond.  The number of bits used by the algorithm has a direct correlation with the ease in cracking it, though as the computers used to crack them grow more and more powerful, previously effective algorithms progressively begin to lose their effectiveness, until their security is trivial altogether.

Microsoft is well aware that this has happened to the MD5, and so they appear to be making hunting down and eliminating these lesser algorithms in their services.  Back in June, Microsoft set their new minimum key length of RSA keys to 1024 bits, and now by striking out the use of MD5 in digital certificates, they’re seeking not only enhance their cryptographic techniques, but to leave behind the now unsecure ones as well.  The move comes in the form of a few security advisories released this week that state the following:

Security Advisory (2661254)

Microsoft is announcing the availability of an update to Windows that restricts the use of certificates with RSA keys less than 1024 bits in length. The private keys used in these certificates can be derived and could allow an attacker to duplicate the certificates and use them fraudulently to spoof content, perform phishing attacks, or perform man-in-the-middle attacks.

Security Advisory (2862973)

Microsoft is announcing the availability of an update for supported editions of Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, and Windows RT that restricts the use of certificates with MD5 hashes. This restriction is limited to certificates issued under roots in the Microsoft root certificate program. Usage of MD5 hash algorithm in certificates could allow an attacker to spoof content, perform phishing attacks, or perform man-in-the-middle attacks.

The patches described, which appear to be optional, are available only for testing now, and are slated for deployment in February of 2014.

 

What is malware and should I be concerned about it?

Malware is short for “Malicious Software”.  It is software that without your knowing, gets on to your computer and runs to perform “malicious actions” to your data, software and surrounding environment (other computers on the network).  Malware comes in a variety of shapes and sizes including code, scripts, active content and much more.  More specifically, these instances can take the shape of viruses, ransomware, worms, trojan horses, rootkits, etc.  Worms and trojans makeup most of the malware out there today.  Viruses are not that prevalent, although you may think so, given how many times a day you hear about them.

Why I should protect against malware?

This may be an obvious question, but let’s look at some details of what might result from a malware attack anyway.  The damage caused by malware can increase outgoing traffic that affects the response time of your computer to tasks you are trying to accomplish and/or submitting your sensitive data to the computer of a hacker for later use, such as on a shopping spree with your credit card.  I’m sure you don’t want to wait any longer than you have to for your favorite app to load or download to complete.  On the nastier end of the scale, the right malware on your system can cause loss of very important data as well as a complete shutdown of the network.  Would you want to be the poor soul that allowed a virus to intrude on your company network, shut down operations for hours or even possibly days at an expense of millions lost in revenue for the business?  IT departments do have the technology to determine where malicious software entered their environment.

How to protect against Malware:

The foremost and easiest means of protecting against malware is to never run anything you are not sure where it came from or what it does.  The most common means of malware introduction is through the internet in the form of an email or web-site link.  You may receive an email from what appears to be the name of a trusted friend with a link in the email that they recommend you see.  The problem with that email is that the actual email address itself (not the alias “from” text) is not your friends and in fact is probably not even a real email address (the attacker wouldn’t want you to be able to attack back).  Clicking on the link will start off whatever kind of intrusion the “bad person” has planned.

While surfing the web one Sunday morning in your favorite robe and hot steaming cup of Joe, you may see a link to something that promises to provide something you have been hoping to achieve for quite some time.  Something so appealing you cannot help but click the link to find out what it is all about.  You may be brought to a site that discusses your next “ultimate” vacation, but you soon realize that there isn’t much to it and it doesn’t give any means of getting there.  That’s because it’s not real.  The intention of the creator of the site is to install/run malicious software on your computer when you click the link.  The actual attack will probably also be delayed so you won’t be able to associate it with the link you just clicked.

Of course you can also be pro-active and purchase software that detects when malware is being installed or has already been installed.  The bigger players in this arena are Norton and McAfee.  This link discusses even more software to help protect against malware intrusion:

References:

  1. http://www.securelist.com/en/threats/detect?chapter=76
  2. http://en.wikipedia.org/wiki/Malware#Proliferation

Inside Twitter's Two-Factor Solution

Back in April, we’d reported that Twitter was the latest to be hopping onto the Two-Factor bandwagon, and have, since then, fully implemented the technology.  Only recently however, have they provided insight on the future of their security enhancement agenda in a blog post last week.  It states that, in addition to the SMS-based two-factor login they’d released in May, they will be rolling out a new two-factor authentication method that eliminates the need for text messages.

The blog states that “now you can enroll in login verification and approve login requests directly from your iOS or Android app”, and goes on to tout the following new features:

    • No phone number required: By using push messaging and in-application approvals, you no longer need to provide your phone number to use login verification. If you manage multiple Twitter accounts, but only have one phone number, you can now opt all of them into login verification.
    • Broader international support: Now, all you need is an Internet connection and one of our supported apps to enroll in login verification. Login verification via SMS has been available through supported mobile carriers across the world, but that didn’t cover everybody.
    • “My phone fell in the ocean!”: Backup codes generated in the application can be written down, stored in a safe place, and used to access your account on twitter.com even if you lose your phone.
    • More context: When a login request is made, you will see browser details and approximate location in the app. If you receive an approval request from halfway across the world, you may be getting phished. Review this page for more information on keeping your account secure.

Twitter’s security engineer Alex Smolen had the following to say regarding the new system: “When we decided to implement two-factor, we wanted something that was easy to use and didn’t follow the same formula everyone else was using… Other two-factor systems rely on a shared secret… We wanted to come up with a design where it is only stored on the client side; the secret’s only stored on the phone.”

Twitter’s approach to enhanced security through two-factor authentication is surely an interesting one, albeit not entirely new, and has some interesting fail-safes in the event that you’re without a network connection.  “We involved support very early on in the process, we want to make sure people don’t lose access to their Twitter accounts even though the nature of this feature is to deny service.”  says Smolen.

The new two-factor service debuted on August 6th, and is still in active development, with more features planned to be added in the coming months.

Security Awareness vs. Security Know How

Most people are aware that threats exist but they are not aware of how the actions they perform make them susceptible to these threats.

“As many as one in five do not understand the potential impact of some of the more dangerous attacks like zero day threats, while 41% of respondents use only one or two passwords across all the sites they visit online and 8% use only one password for all sites, suggesting respondents are not so security savvy!” 1

Most users do know that they must have security software installed and continue to keep it up to date.

These users also know to respond to a security alert from the software and take the recommended action.  However, not so many people will actually verify a link before navigating to it.

Security “awareness” is knowing that security risks exist and that there are security tools that can help prevent and combat the risks.  Security “know how” is realizing that the everyday actions that you perform on your computer can also leave you susceptible to cyber crime despite having security checks in place.  A good example is how people use Facebook.

Unfortunately, the massive increase in social networking has provided a plethora of data for “bad guys” to gather and use to access your valuables.  The information for example that you would daily add to Facebook can easily be obtained and then used to possibly guess one or more of your passwords to other sites.  Detailed information like your phone number, address and date of birth should definitely not be supplied to Facebook.  I know, your Facebook friends won’t be reminded that it is your birthday, but wouldn’t you rather get birthday greetings from real friends that actually know when your birthday is.  But I digress… It is also a good idea not to follow any links posted from unfamiliar people.  You even have to pay close attention to the spelling of your “friends” name.  Someone could be trying to pass off as someone you know by using their name with one letter slightly changed.  For instance, your most trusted Facebook friend is Danielle and you are always very eager to see what she has to say.  Someone could easily create a new Facebook account and use the name Daniele or even Daniel1e to try and fool you into becoming involved in their scam or virus.

Another self-defense mechanism is to make sure you have a different password for each online account you have.  You don’t want to make it too easy for a thief to get into all of your protected accounts by only guessing your one password.  With different passwords, at most one account can be compromised at a time.

“Trust no one” even though a link comes from a trusted friend, they may have received it from an untrusted site, fell for the scam or invasion and are now unknowingly trying to pass it on to you.  Some “bad guy” users will even go so far as to use your friend’s account unknowingly to propagate something to you.  You may need to ask your friend in person if they sent something that may look suspicious to you.

Facebook as well as other reputable sites do have security measures in place that you can configure for your own account.  Take a look at this link if you are interested in learning more about Facebook’s security controls, tips and policies.  Facebook is just one example and you can see how these vulnerabilities and more can affect any web site.

Resource:

  1. http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CEMQFjAB&url=http%3A%2F%2Fgtbpcug.org%2Fbaybytes%2Fbbyt0613.pdf&ei=gzEJUqj_GbXe4AOcpoGoBA&usg=AFQjCNHBVb87aEXxpsNxz7K-sXg5nMWK5Q&sig2=6rMgKv-dGbGYtMxzyeuZbw&bvm=bv.50500085,d.dmg

Google's Controversial Chrome Security

A lot of people are recently up in arms over a security policy that Google Chrome has already had in place since its inception.  Why so suddenly are they expressing their dismay? In a blog post by U.K software developer Elliot Kember picked up by Hacker News yesterday, he illuminates why he believes Chrome’s password security strategy is “insane”, and it seems to have garnered much attention.

The issue lies in the way the browser stores web passwords, and how it essentially allows anyone accessing your computer to see those passwords very easily.  It’s not a hack or bug, it’s the intended design.  As described in Kember’s blog post, there is no master password, security or any kind preventing the plain-text revealing of stored passwords within the browser.  His closing point, is not so much that the lack of security is so outrageous, provided ‘Password Management’ is a complicated issue that one can imagine Google has thought through thoroughly, so much as it’s the lack of awareness among less technical users that this sort of easy-access exists at all.

Google Chrome’s security chief, Justin Schuh, was quick to respond, by explaining the company’s side of things in the comments of the same Hacker News article, where an argument between he and Kembler continued for a few replies.  The thick of Schuh’s response is quoted below:

I’m the Chrome browser security tech lead, so it might help if I explain our reasoning here. The only strong permission boundary for your password storage is the OS user account. So, Chrome uses whatever encrypted storage the system provides to keep your passwords safe for a locked account. Beyond that, however, we’ve found that boundaries within the OS user account just aren’t reliable, and are mostly just theater.

Consider the case of someone malicious getting access to your account. Said bad guy can dump all your session cookies, grab your history, install malicious extension to intercept all your browsing activity, or install OS user account level monitoring software. My point is that once the bad guy got access to your account the game was lost, because there are just too many vectors for him to get what he wants.

We’ve also been repeatedly asked why we don’t just support a master password or something similar, even if we don’t believe it works. We’ve debated it over and over again, but the conclusion we always come to is that we don’t want to provide users with a false sense of security, and encourage risky behavior. We want to be very clear that when you grant someone access to your OS user account, that they can get at everything. Because in effect, that’s really what they get.

The two appear to be coming from very different perspectives, each containing valid points in regards to how the password management system should work and what it’s users should know about it.  Is this something that concerns you as a user? Or do you believe Google has done what’s best, have researched the topic for literally years?

Hashing vs. Encryption

The hashing and encrypting of sensitive data protects the data from unwanted access by people with ill intentions.  Even though the two algorithms serve the same purpose, they are very different and each are suited for specific forms of protecting your valuable resources.  Knowing these differences will make it easier to verify that you have the correct option in place for the right scenario.

 

 

What is Hashing?

Hashing has been used to organize strings of variant lengths into a value that is always the same length – usually smaller.  The important part about hashing is that it is a one way mapping. i.e.you cannot get the original value from the hashed value.  It is, however, possible for multiple input values to hash to the same output value, but the best hash algorithms will eliminate these collisions as much as possible.  This link explains minimizing collisions in more detail.

 

Proper hashing algorithms will also make it very hard (virtually impossible) to reverse the hash by processing the input multiple times.  MD5 does it 64 times for each 512 bit chunk of data.  The results from each of the 64 iterations are then combined together to create the hash.

If you were to decode the hash, the first item of business would be to separate the hash back into the 64 individual hashings.  Then of course reverse each of the 64 individual units.

“Now, to explain why this is VERY hard, imagine trying to deduce a and b from the following formula: 10 = a + b. There are 10 positive combinations of a and b that can work. Now loop over that a bunch of times: tmp = a + b; a = b; b = tmp. For 64 iterations, you’d have over 10^64 possibilities to try. And that’s just a simple addition where some state is preserved from iteration to iteration. Real hash functions do a lot more than 1 operation (MD5 does about 15 operations on 4 state variables). And since the next iteration depends on the state of the previous and the previous is destroyed in creating the current state, it’s all but impossible to determine the input state that led to a given output state (for each iteration no less). Combine that, with the large number of possibilities involved, and decoding even an MD5 will take a near infinite (but not infinite) amount of resources. So many resources that it’s actually significantly cheaper to brute-force the hash if you have an idea of the size of the input (for smaller inputs) than it is to even try to decode the hash.” 1

One of the ways hackers use to get around the effort required to compute all possible hashes is to use pre-computed rainbow tables (link).  This is where salting the hash comes in handy for the good guys.  There is already an article on our blog about salted hashes here

 

What is Encrypting?

Encrypting sensitive data hides the true value so it can’t be seen while being stored or transported, but allows for decryption later in time so the value can be viewed and used again by the proper person.  The important piece about an encryption algorithm is that there is always a one to one mapping between the input and the output values.  It is possible for more than one input to generate the same encrypted output, but a proper encryption algorithm won’t let this happen.  The input and output lengths can always vary as opposed to the fixed length hashing output.  There is always a specific way to reverse the encryption by using a well-defined method.  Properly encrypted data cannot be identified as different than noise while hashing is always a consistent format.

 

USAGE SCENARIOS:

Hashing

Storing the hash of a password works well because the plain text of the password cannot be retrieved from the storage area.  Any password entered by a user is put through the hash function and the resulting hash is compared against the stored one to authenticate the user.

 

You can also validate input data using a hash function; instead of doing a lengthy compare of two large files, hash both files and if the hashes match, the files are the same.

 

“The probability of a collision is astronomical for small input sizes (assuming a good hash function). That’s why it’s recommended for passwords. For passwords up to 32 characters, md5 has 4 times the output space. Sha1 has 6 times the output space (about). Sha512 has about 16 times the output space. You don’t really care what the password was, you care if it’s the same as the one that was stored. That’s why you should use hashes for passwords”.1

 

Encrypting

Encryption of a value is necessary when the plain text of the value will be needed when the item is looked up in storage – if you are storing your bank account numbers, you will need to see the plain text version of them to use them.  The same applies to data that is sent securely from one location to the other and needs to be viewed by the receiving party.

 

Resources:

  1. http://stackoverflow.com/questions/4948322/fundamental-difference-between-hashing-and-encryption-algorithms
  2. http://en.wikipedia.org/wiki/Hash_function#Uniformity
  3. http://en.wikipedia.org/wiki/Rainbow_tables