Posts Tagged ‘encoding

Web Browser Spoofing Vulnerabilities

Over the past two years, several vulnerabilities in web browsers have provided phishers with the ability to obfuscate URLs and/or install malware on victim machines.

1. International Domain Names (IDN) Abuse

International Domain Names in Applications (IDNA) is a mechanism by which domain names with Unicode characters can be supported in the ASCII format used by the existing DNS infrastructure. IDNA uses an encoding syntax called puny code to represent Unicode characters in ASCII format. A web browser that supports IDNA would interpret this syntax to display the Unicode characters when appropriate. Users of web browsers that support IDNA could be susceptible to phishing via homograph attacks, where an attacker could register a domain that contains a Unicode character that appears identical to an ASCII character in a legitimate site (for example, a site containing the word “bank”that uses the Cyrillic character “a” instead of the ASCII “a”).

2. Web Browser Cross-Zone Vulnerabilities

Most web browsers implement the concept of security zones, where the security settings of a web browser can vary based on the location of the web page being viewed. We have observed phishing emails that attempt to lure users to a web site attempting to install spyware and/or malware onto the victim’s computer. These web sites usually rely on vulnerabilities in web browsers to install and execute programs on a victim’s computer, even when these sites are located in a security zone that is not trusted and normally would not allow those actions.

Tags : , , , , , , , , , , , ,

Eavesdropping Detection

The quantum cryptography protocols described above provide two parties with nearly identical secret keys along with an estimate of the discrepancy between the shared key. In quantum cryptographic systems, the discrepancy between the shared secret key can be due to either a third party eavesdropping or imperfections in the transmission line and/or equipment. For security purposes, the discrepancy is always assumed to be from third party eavesdropping, since there is no way to distinguish the true cause of the discrepancy.

Using the BB84 encoding scheme, Alice and Bob check for eavesdropping by comparing a portion of their remaining bits that they would use for a shared secret key. If a third party were eavesdropping, errors would be introduced into Bob’s photon measurements. If a number of bits beyond a threshold differ, the derived key is discarded and the process QKD (Quantum Key Distribution) process is repeated. Using the B92 encoding scheme, Bob can determine if a third party was eavesdropping directly from the measurements of the photon. As stated in the previous section, if the measurement of the photon is greater than 1 then the receiver can be certain that no one was eavesdropping otherwise the photon is discarded.

Using the Ekert encoding scheme, Bob and Alice check for eavesdropping by comparing their rejected bits, called the rejected key. If their comparison satisfies Bell’s inequality, then a third party has been detected and the entire process is repeated. Otherwise the raw key is retained. Bell’s inequality is essentially a method for determining the probability that two bits do not match given the measurement basis used.

Given an error rate between the shared key, two processes can be used to reduce the erroneous bits and reduce a third party’s knowledge of the key to a negligibly small value. The two processes are privacy amplification and information reconciliation, which are used together.

Tags : , , , ,

Desirable Quantum Key Distribution Attributes

Broadly stated, QKD(Quantum Key Distribution) offers a technique for coming to agreement upon a shared random sequence of bits within two distinct devices, with a very low probability that other devices(eavesdroppers) will be able to make successful inferences as to those bits’ values. In specific practice, such sequences are then used as secret keys for encoding and decoding messages between the two devices. Viewed in this light, QKD is quite clearly a key distribution technique, and one can rate QKD’s strengths against a number of important goals for key distribution, as summarized in the following paragraphs.

Confidentiality of Keys : Confidentiality is the main reason for interest in QKD. Public key systems suffer from an ongoing uncertainty that decryption is mathematically intractable. Thus key agreement primitives widely used in today’s Internet security architecture, e.g., Diffie-Hellman, may perhaps be broken at some point in the future. This would not only hinder future ability to communicate but could reveal past traffic.Classic secret key systems have suffered from different problems, namely, insider threats and the logistical burden of distributing keying material. Assuming that QKD techniques are properly embedded into an overall secure system, they can provide automatic distribution of keys that may offer security superior to that of its competitors.

Authentication : QKD does not in itself provide authentication.Current strategies for authentication in QKD systems include prepositioning of secret keys at pairs of devices, to be used in hash-based authentication schemes, or hybrid QKD-public key techniques. Neither approach is entirely appealing. Prepositioned secret keys require some means of distributing these keys before QKD itself begins, e.g., by human courier,which may be costly and logistically challenging. Furthermore, this approach appears open to denial of service attacks in which an adversary forces a QKD system to exhaust its stockpile of key material, at which point it can no longer perform authentication. On the other hand, hybrid QKD-public key schemes inherit the possible vulnerabilities of public key systems to cracking via quantum computers or unexpectedadvances in mathematics.

Sufficiently Rapid Key Delivery : Key distribution systems must deliver keys fast enough so that encryption devices do not exhaust their supply of key bits. This is a race between the rate at which keying material is put into place and the rate at which it is consumed for encryption or decryption activities. Today’s QKD systems achieve on the order of 1,000 bits/second throughput for keying material, in realistic settings, and often run at much lower rates. This is unacceptably low if one uses these keys in certain ways, e.g., as one-time pads for high speed traffic flows. However it may well be acceptable if the keying material is used as input for less secure (but often secure enough) algorithms such as the Advanced Encryption Standard. Nonetheless, it is both desirable and possible togreatly improve upon the rates provided by today’s QKD technology.

Robustness : This has not traditionally been taken into account by the QKD community. However, since keying material is essential for secure communications, it is extremely important that the flow of keying material not be disrupted, whether by accident or by the deliberate acts of an adversary (i.e. by denial of service). Here QKD has provided a highly fragile service to date since QKD techniques have implicitly been employed along a single point-to-point link. If that link were disrupted,whether by active eavesdropping or indeed by fiber cut, all flow of keying material would cease. In our view a meshed QKD network is inherently far more robust than any single point-to-point link since it offers multiple paths for key distribution.

Distance- and Location-Independence : In the ideal world,any entity can agree upon keying material with any other(authorized) entity in the world. Rather remarkably, the Internet’s security architecture does offer this feature – any computer on the Internet can form a security association with any other, agreeing upon keys through the Internet IPsec protocols. This feature is notably lacking in QKD, which requires the two entities to have a direct and unencumbered path for photons between them, and which can only operate fora few tens of kilometers through fiber.

Resistance to Traffic Analysis : Adversaries may be able to perform useful traffic analysis on a key distribution system,e.g., a heavy flow of keying material between two points might reveal that a large volume of confidential information flows, or will flow, between them. It may thus be desirable to impede such analysis. Here QKD in general has had a rather weak approach since most setups have assumed dedicated, point-to-point QKD links between communicating entities which thus clearly lays out the underlying key distribution relationships.

 

Tags : , , , , , , , , , , , , , , , , , , , , , , , ,

Authentication in ColdFusion

ColdFusion features built-in server-side file search, Adobe Flash and Adobe Flex application connectivity, web services publishing, and charting capabilities. ColdFusion is implemented on the Java platform and uses a Java 2 Enterprise Edition (J2EE) application server for many of  its runtime services. ColdFusion can be configured to use an embedded J2EE server (Adobe JRun), or it can be deployed as a J2EE application on a third party J2EE application server such as Apache Tomcat, IBM WebSphere, and BEA WebLogic.

Authentication

Web and application server authentication can be thought of as two different controls (see Figure 1). Web server authentication is controlled by the web server administration console or configuration files. These controls do not need to interact with the application code to function. For example, using Apache, you modify the http.conf or .htaccess files; or for IIS, use the IIS Microsoft Management Console. Basic authentication works by sending a challenge request back to a user’s browser consisting of the protected URI. The user must then respond with the user ID and password, separated by a single colon, and encoded using base64 encoding. Application-level authentication occurs at a layer after the web server access controls have been processed. This section examines how to use ColdFusion to authenticate and authorize users to resources at the application level.

Figure 1: Web server and application server authentication occur in sequence before accessis granted to protected resources.

ColdFusion enables you to authenticate against multiple system types. These types include LDAP, text files, Databases, NTLM, Client-Side certificates via LDAP, and others via custom modules. The section below describes using these credential stores according to best practices.

Best practices

  1. applicationTimeout = #CreateTimeSpan(0,8,0,0)#
  2. loginStorage = session
  3. sessionTimeout = #CreateTimeSpan(0,0,20,0)#
  4. sessionManagement = True
  5. scriptProtect = All
  6. setClientCookies = False (Use JSESSIONID)
  7. setDomainCookies = False
  8. name (This value is application-dependent; however, it should be set)

Tags : , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,