Myth 6: RSA SecurID provides a secure connection.

Today’s SSL myth tackles the topic of RSA SecurID. The prevailing myth is that RSA SecurID provides a secure connection – but of course, this isn’t so.  The RSA SecurID token authentication system is a two-factor authentication method, which is the most common secure access method in the U.S. with 40 million users. The RSA SecurID token authentication method uses the RSA ACE Server, which is a clock synchronization key scheme. It works on a timing frequency that changes the token keys so that they never seem to be the same. The frequency and the seed key were both found on the RSA ACE Server, which was hacked by perpetrators on March 18, 2011. Here is the way one inventor describes the scheme in his patent granted in 2008: “The pseudorandom token codes are only valid during a short time that they are displayed (e.g. 30 seconds). A hash function that generates the pseudo-random token code takes a current time and a secret key as inputs. The secret key is provided to the token by the manufacturer and then provided to the authentication server. ” This scheme makes the authentication system very time sensitive. If an authentication server and token have clocks that diverge, the system quickly breaks. Also, the security of the leading hash function has been called into question.” The inventor is referring to a detailed cryptanalysis study by Springer-Verlag, 2003. These researchers found that the block cipher at the heart of the RSA SecurID hash function can be broken in a few milliseconds using a 2003-vintage PC.  Once again, myth debunked. Source: EMC...

SSL Myth Busting: A Two-Way Certificate Exchange Between a SOA Web Service and a Client Can Always Be Trusted. [False.]

Today’s SSL myth in our series deals with two-way certificate exchanges between a SOA web service and a client. We’ve already explained why one-way certificate authentication of a SOA web service is not guaranteed to be secure simply because it uses HTTPS. Now onto two-way certificate exchanges. SSL achieves its security by using certificates to authenticate each side of a connection made between two parties—a web server and a client (usually a web browser)—which are based on public key cryptography. The SSL protocol assumes that, if a public key can be used to decrypt a piece of information, then it’s all but certain that the information was originally encrypted with the corresponding private key. When initiating a two-way SSL session, the client will check that the SOA web service certificate is valid and signed by a trusted entity. The server running the web service publishes a certificate—a little chunk of data that includes a company name, a public key and some other bits and pieces— and when the client connects to the server, the client sends the server some information encrypted using the public key from the certificate. The server then decrypts this using its private key. Once the connection is established, all information during that session is encrypted with this information. Since only the server knows the private key—and hence, only the server can decrypt the information encrypted with the public key—this allows the client to prove that it is communicating with the rightful owner of the certificate. Herein lies the flaw. To defeat this setup, the MITM (Man-in-the-middle) only has to do a little bit more work. It...

Myth #5: A Two-Way Certificate Exchange Between a SOA Web Service and a Client Can Always Be Trusted. [False.]

Today’s SSL myth in our series deals with two-way certificate exchanges between a SOA web service and a client. We’ve already explained why one-way certificate authentication of a SOA web service is not guaranteed to be secure simply because it uses HTTPS. Now onto two-way certificate exchanges. SSL achieves its security by using certificates to authenticate each side of a connection made between two parties—a web server and a client (usually a web browser)—which are based on public key cryptography. The SSL protocol assumes that, if a public key can be used to decrypt a piece of information, then it’s all but certain that the information was originally encrypted with the corresponding private key. When initiating a two-way SSL session, the client will check that the SOA web service certificate is valid and signed by a trusted entity. The server running the web service publishes a certificate—a little chunk of data that includes a company name, a public key and some other bits and pieces— and when the client connects to the server, the client sends the server some information encrypted using the public key from the certificate. The server then decrypts this using its private key. Once the connection is established, all information during that session is encrypted with this information. Since only the server knows the private key—and hence, only the server can decrypt the information encrypted with the public key—this allows the client to prove that it is communicating with the rightful owner of the certificate. Herein lies the flaw. To defeat this setup, the MITM (Man-in-the-middle) only has to do a little bit more work. It...

SSL Myth Busting: Java Authentication and Authorization Services (JAAS) Framework Handles All Protocols and Mechanisms Securely [Nope.]

Onto the next post in our series debunking SSL myths. Today’s myth: Java Authentication and Authorization Services (JAAS) framework handles all protocols and mechanisms in a secure manner. The Internet resources and SOA Web pages are Web applications. As such, they make use of the JAAS framework, which is a user-centric authentication and authorization collection of Eclipse plug-ins to manage authentication and authorization within an application built on the Rich Client Platform framework. The plug-ins provide an implementation of the JAAS API and can be extended by developers to support their own security needs. The code snippet below shows how easy it is to disable every authorization check in a system implementing JAAS. public pointcut hackJAAS(); : call( * AccessController.checkPermission(..) ); void around() : hackJAAS() { //Do nothing. No proceed-call. } The reason this is such an easy task is that JAAS is a standardized framework. To perform an authorization check, a user must call AccessController.checkPermission. Yet, everyone knows this—both lawful programmers and hackers. That means that if an application uses JAAS, a hacker automatically know which code they need to disable. The hacker doesn’t need to see the source code, nor do they need to see any kind of documentation. The Norwegian Information Security Laboratory does an excellent job of explaining the technical details of this vulnerability, if you’d like more information. For now – another myth...

SSL Myth Busting: Online banking via SSL session is secure.

Onto the next post in our series debunking SSL myths. Today’s myth: Online banking via SSL session is secure. The answer is  [SPOILER ALERT] — false. Companies often use SSL to secure sensitive information transfer from customers or partners. But vulnerabilities in this approach are frequently exposed. For example, a recent attack targeted CitiGroup’s 21 million customers and resulted in a 1% success rate. This might seem low, but remember that 1% of 21 million translates to 210,000 compromised users. Even worse, the CitiGroup breach wasn’t an isolated case. Swiss researchers recently published a memo describing a way to gather information about the data transmitted over an SSL channel by exploiting a vulnerability in the implementations of block ciphers, such as AES. It’s worth noting that AES was developed by Defense Advanced Research Projects Agency (DARPA) and is widely accepted as the strongest form of encryption. The memo, however, pointed out that in certain circumstances, it’s possible to decrypt some of the data in the messages, including encrypted passwords. This vulnerability is linked to the way error handling is implemented in applications that use the cipher-block chaining mode, such as AES in SSL. One of the best ways to avoid this pitfall is to never use the same key stream to encrypt two different documents. The cipher-block chaining also exhibits well-known weaknesses that can be exploited to break SSL communication. Just how easy it is to crack SSL/TLS was demonstrated recently by two researchers, Thai Duong and Juliano Rizzo. They demoed a straightforward attack against SSL/TLS using a Java Applet to decrypt — or even take over — a...