The objective of a firewall is to inspect packets and to either allow or dismiss the packets. The fun part of writing that software would be the packets inspection, and the rules engine (the thing that decides what goes through). The boring part would be the interface where you would edit the rules and perhaps a dashboard that will display the current status on ports etc.

You will undoubtedly find that the developers at some point had to test the different parts of the application. This either means they create the simplest way to test it, or go through the effort of making the end user dashboard all be it in battleship gray and big ugly buttons. Me, option 1 is always the answer. Even big ugly gray buttons is not only boring, it is wasted time that i could be spending on Facebook or Twitter.

It turns out, that a lot of the time others also code in a very similar pattern to me. Firstly, that makes me feel a lot better about myself and secondly it saves me from having to use a GUI. What i am trying to get at is the ability to use the command line or even better, write a batch script. The advantage of these is that they are  simple to change and allow you to make changes without the ability to know a coding language and more prevalent of late, a coding environment or framework.

Have a look at the following

   1: netsh advfirewall firewall add rule name="SQL Server (TCP 1432)" dir=in action=allow protocol=TCP localport=1433 profile=domain

What we have before us is a command line utility that allows us to add rules to the firewall on Windows 2008. Talk about the easiest way to repeat a test a few times, add this to a batch file and you can test over and over an over. The difference here is that in Linux, almost everyone believes that this is the only way to change items and the exact opposite would be said for Windows. I can only believe that this is what caused Microsoft to release PowerShell. An almost official way of saying, look we are hardcore too, we have the shell. I earnestly believe that they have always had a shell and this is shell v2.0 and i like it.

In the following weeks and future posts i will be trying to introduce new concepts and scripts in PowerShell along with other technologies.

I first off need to say that there is nothing like the power of a desktop PC. Laptops will always try and catch up, but the physical limitations that a laptop design has rules it out of the power race. I however work in a dual location (work and home) and lugging a big box around, although technically i have been doing it for two years is not practical anymore. Also, the power supply that comes with the beast weighs in just under 2Kg’s and it is a pain in the rectum to carry around! Battery life is ok, but the need for a power source is there because no-one works for less than 3 hours at a stint and my battery lasts just under 2.

So i decided to draw up a quick list of things that i need as a result of lessons i have learnt with my previous hardware.

• at least 500Gb 7200RPM Drive preferably a solid state and another drive
• at least 4 gigs of RAM or more (large disks means virtualization so probably 8 gigs)
• Intel 2.6ghz or more with 6mb cache
• 15.4 screen with (1600×1200) display
• VGA out and or HDMI
• A battery or combination of batteries that give more than 3 hours work time
• Decent weight

I also have had to face facts that the type of work i have to do is changing. I used to sit and code, design and partially document for a good 9, 10 hours a day and this machine was good for that. Of late i am having to give more presentation, do a lot of planning and project management (the latter of which is like eating wet popcorn) and so i need a versatile device rather than a single purpose built one. I would really like to try and move towards a goal based approach in my work rather than single incident type style that i am currently working on at the moment. This style of work has me in the office all day and when i am away from my desk in meetings etc i need to come back and start from where i left off, which i admit is a dumb way of working.

So for the next short while it is going to be drawing up processes etc to almost get my team i manage in a self managed mode so i can start to expand into new area’s again. Oh and a Mac is not out of the equation….

• You can only boot a Windows 7 or Windows Server 2008 R2 VHD
• You must configure the boot editor from a Windows 7 or Server 2008 R2 install
• You cannot use a Virtual PC VHD, I suggest a Hyper-V VHD
• You need to start with a clean slate, don’t try and reuse an old VHD

I am sure this will change as Windows 7 goes through the beta and RC stages on its way to RTM and we’ll update this as necessary but here goes…

Start by launching a Command Prompt and be sure to run as Administrator, once that is done run the following commands…

bcdedit /copy {current} /d “Boot_From_VHD”

Copy the CSLID that is displayed and then run…

bcdedit /set {CLSID} device vhd=[C:]\vhdname.vhd

bcdedit /set {CLSID} osdevice vhd=[C:]\vhdname.vhd

bcdedit /set {CLSID} detecthal on

You can replace [C:]\vhdname.vhd with the path and name of your VHD.

Once that is complete reboot and you will have the option to “Boot_From_VHD”!  You can verify the bootloader is configured correctly with the bcdedit command which will list all the boot options.  If you want to delete the entry make note of the GUID listed in bcdedit and use the following command…

bcdedit /delete {GUID} /cleanup

However, complying with PCI DSS should not be considered a silver bullet for protecting information and battling fraud. Consider that many of the companies victimized by data breaches in the past several years were, in fact, found to be PCI-compliant prior to the breach.

As fraudsters become more sophisticated and develop tactics for identifying and exploiting a given system’s vulnerabilities, it is important that organizations across all industries realize that comprehensive data protection requires technologies and processes that extend beyond the basic requirements outlined by PCI DSS.

Specific reference to the use of encryption is increasingly found in privacy mandates and industry best practices that attempt to go beyond the traditional focus on “people and processes.” Furthermore, encryption is often favored by regulators and policy makers because of the black-and-white nature of the technology. Data is either encrypted or it is not, which in theory means it is either secure or not — a very measurable parameter that is well received by auditors and regulators.

While PCI DSS mandates data encryption at various points in the payments cycle, it does not explicitly prescribe end-to-end encryption — the most sophisticated and successful approach for protecting sensitive cardholder data and other information. Only by implementing end-to-end data protection throughout the entire payment ecosystem can the industry actually achieve the needed security for sensitive data. An example of this is how PIN data is protected in today’s environment — from the point of entry all the way to the Issuer.

Substantiating this approach, Visa (NYSE: V) recently issued its global industry best practices for data field encryption, also known as “end-to-end encryption.” Included in Visa’s best practices is guidance to use robust key management  solutions and encryption consistent with international and regional standards. This includes the management of encryption/decryption keys within Secure Cryptographic Devices such as PIN Entry Devices (PEDs) or Hardware Security Modules (HSMs).

However, despite the growing recognition of the benefits of encryption, there remains a general lack of understanding about deploying and, more importantly, managing the process.

The Key to Simplified Encryption

IT and security administrators often consider encryption to be a costly, time-consuming endeavor that requires a great deal of day-to-day management and slows down other processes. However, these concerns have been addressed as enhanced encryption technologies have come to market.

The true challenge that companies face when it comes to deploying and managing the encryption process is controlling they keys — the secret codes that have the power to unlock data.

As more and more organizations consider implementing end-to-end encryption, they must be able to manage an increasing number of encryption keys. This is crucial not only to prevent keys from being lost or stolen, but also for important operational reasons like on-demand recovery of encrypted data, automated updates and compliance reporting.

Once encrypted, information only becomes readable if the encryption key is available to unlock it. Consequently, the key becomes as valuable as the data it is protecting. This situation can be likened to the security of a home: Locking the house significantly increases the security of its contents, but if the key is left under the doormat, then the level of security is compromised.

In the same way, while end-to-end encryption is an effective approach to safeguarding sensitive data, encryption keys need to be stored and managed effectively in order to ensure that information remains secure.

An additional component of effective encryption key management is implementing a mechanism for securing the keys themselves. Usurping an encryption key is far easier than cracking the encryption, so this is where much criminal activity is focused. With encryption effectively impossible to break, the key management system becomes a natural target for attack. Consequently, deploying end-to-end encryption also requires that security officers establish a method for keeping the keys protected at all times.

While it may appear that key management creates a tremendous burden for organizations considering end-to-end encryption, there are technology solutions and best practices that companies can implement to simplify the key management process.

Good Key Management

To simplify and secure the key management process, techniques to provide enhanced physical and logical security in hardware have become well established. It is worth noting that keys stored using software are subject to attack by Trojans, other forms of spyware, or even malicious use of debugging and system-maintenance tools.

To that end, many companies that deploy end-to-end encryption use hardware security modules (HSMs) to properly store, manage and secure keys. This fundamental approach is reinforced in Visa’s best practices for data field encryption. What’s more, security certifications such as the Federal Information Processing Standard (FIPS) and Common Criteria have helped organizations evaluate the design of these devices to ensure that they are implementing the most robust protection technologies available.

One of the issues when dealing with key management is that in many cases the different security solutions implemented in an organization have their own system and methodology for managing keys. As a result, security administrators are faced with the challenge of having to manage keys in different systems without a common process or framework.

However, several initiatives under way aim to provide standards that can help in the development of common methods for exchanging and managing keys between systems. These include key management standards such as IEEE 1619.3 and the OASIS Key Management Interoperability Protocol (KMIP). As these standards find their way into general adoption, the situation for centralized and uniform key management will improve, allowing security administrators the ability to bring all key management under a unified umbrella.

Measures such as these will help enable organizations to implement cohesive key management strategies moving forward. Once a well thought-out approach to key management is established, effective security policies, reporting practices and, ultimately, a stronger sense of control over data will be achieved.

Bottom Line

Encrypting sensitive data throughout the payment cycle is among the most robust strategies for ensuring the continuous protection of systems, but organizations must understand their own specific security risks and proactively deploy appropriate security measures, such as end-to-end encryption.

Maintaining a security infrastructure that incorporates ongoing compliance with PCI DSS at its foundation remains a baseline of defense against potential data breaches, but organizations often face challenges when trying to properly implement and maintain encryption and the keys that unlock the information.

By thoroughly analyzing available key management technologies and standards, IT managers can identify the most appropriate solutions for their environments that will cost-effectively simplify the end-to-end encryption process.

These approaches will not only help all parties in the payments ecosystem meet and surpass PCI DSS requirements, but also ensure the long-term protection of sensitive information, and help eliminate the lasting negative consequences of a security breach.

Google has long offered the option to access its Web-based Gmail service by using HTTPS–a secure version of the Hypertext Transfer Protocol that Web browsers use to retrieve information from Web sites. Now it will become the norm.

“Using HTTPS helps protect data from being snooped by third parties, such as in public Wi-Fi hotspots,” Gmail Engineering Director Sam Schillace, said in a Gmail blog post on Tuesday. “We initially left the choice of using it up to you because there’s a downside: HTTPS can make your mail slower since encrypted data doesn’t travel across the Web as quickly as unencrypted data. Over the last few months, we’ve been researching the security/latency tradeoff and decided that turning HTTPS on for everyone was the right thing to do.”

However, not all is smooth sailing.

“If you use offline Gmail over http currently, the switch to HTTPS is likely to cause some problems,” Schillace said. He directed affected people to a secure offline Gmail fix that walks users through an installation process to get things working.

At one time or another, a software developer is faced with a potential troublesome issue. When all the programming is done, and it’s time to distribute the actual program, the question arises: How do I protect my intellectual property from being misused, changed and sold by a potential user of my program? Of course there are Copyrights, but not all users might be aware or care about it.

unencrypted code

Usually this is not a problem when using ordinary executable files. The customer would have a hard time opening up the file in Notepad, figuring out and modifying the code. This process is called reverse engineering, and for some people this is an art.

encrypted code

The problem is a bit trickier when programming in an open format such as ASP, PHP or any type of scripting. The program is easily readable and sometimes ingenious and potential lucrative algorithms could fall into the wrong hands. But there is a solution. This article is focused on how to protect your PHP scripts using obfuscation techniques that makes the program unreadable for humans – but still fully functional for a computer.

There are several commercial tools that solves this problem for you. A selection of these tools are:

SourceGuardian PRO for PHP : PHP Encoder

SourceGuardian PRO for PHP is best known as the “PHP Encoder”. It is an advanced package with a long list of features for making the resulting code as hard to read as possible. At the time of writing this software lands at $250 for a full license. Some of the main features are: Requires no additions to the running server, Lock to multiple domain names, Full bytecode Encryption and it is PHP5 compatible. In order to test this software you need to register for a single user trial license on their home page.

ionCube PHP Encoder

ionCube PHP Encoder is only one of ionCube’s web based software. At the time of writing it is a little bit easier on the wallet compared to SourceGuardian at $199 for the entry level license. Key features: Bytecode encryption, ASCII or binary format and Digital signature encryption. An evaluation version is available after registering on their home page.

Zend encoder

Zend are actually the ones responsible and involved in creating PHP from scratch. Their encryption package is at a glance the most advanced software of these three. One drawback is that the running server must run Zend Optimizer in order to parse the encoded scripts, although Zend Optimizer is free for download by anyone.

Let’s go Open Source, shall we?

These are all well established commercial programs. This means that in order to protect your product, you need to buy third party software. Luckily there is an option. Say hello to Open Source software!

Open Source means that anyone can view modify and contribute to a program in development. The main benefit for a lone programmer is that it’s completely free of charge and can be used to solve this PHP encryption issue.

There is one thing that separates all of these programs. Type One is the programs that needs to have additional software installed on the hosting server in order for it to run. This means that the administrator (most often not you) will have to modify something on the server where the encrypted files will be executed. In turn, this means an additional layer of time consuming stuff when distributing your software. Sometimes this is okay, but most often not.

Type Two is the programs that doesn’t need to have additional software installed on the server. PHP Obfuscator falls into this category. Theoretically it is possible to have a higher level of security (and sometimes performance) when using Type One encrypters. In practice, noone will ever put that much effort into trying to reverse engineer your scripts. This is why we chose PHP Obfuscator for this How-To part.

Here are two of the main Open Source PHP encryption tools:

Turck MMCache for PHP

Turck MMCache is an open source software package with many included features, such as PHP accelerator, optimizer, encoder and dynamic content cache. One drawback is that in order to use all these functions you need to have additional software installed on the running server. It is fully compatible with Zend Optimizer, but not recommended.

PHP Obfuscator (POBS)

This is the software package focused on in this arcicle. It does not need additional server PHP modules installed in order to run. It’s easy to install and easy to use. The main feature is the actual PHP encryption, with many configuration options. The PHP Obfuscator is available for download from their home page.

How To install POBS

First you need to download it. This is easily done from the home page (see link above). The software is distributed in a .zip file. Just save it to your desktop and open it up. Qouting the INSTALL instructions for POBS:

“Installing POBS is as easy as I could think of. Just unzip the downloaded file and put it a directory that is located under your webserver. POBS is a collection of files in just 1 directory.”

Easy as pie! Now, since POBS is itself written using PHP, you need a web server to run the script. A tutorial for installing a web server is easy to find using a favourite web search engine of your choice. Now, let’s assume the .zip file is unpacked and the POBS files are residing on your web server, for example in this directory: “c:\wwwroot\pobs”.

How To use POBS

Using a favourite web browser of your choice, navigate to your new POBS directory. E.g: “http://www.mysite.com/pobs”. When using your local computer, use “localhost” instead of “www.mysite.com”. You will be presented with a nice POBS interface screen. Blue and purple/gray seems to be the chosen theme for this program. There are several options consisting of both textboxes and checkboxes. The default values are fine but can be changed as the user (YOU) sees fit. Feel free to experiment with the options. No harm can be done since the program will not run unless source and target directories are different.

How To configure POBS

Let’s have a look at the options:

• TimeOut (sec) – This option is not editable. It is read from your PHP configuration and is meant as a safety measure in order to let the web server encrypt the files until it is done. If this value is too small, the encryption will be stopped half way. This might happen if the PHP configuration is set to safe mode, but is often easy to remedy. The default of 5000 secs is fine.
• Source Directory – is the local directory where the PHP files to be encrypted are stored. Note that this is not a “http://” address, but rather a “c:/wwwroot/php” address. One thing to be careful of is the use of “/” instead of “\”. An ordinary local address “c:\wwwroot” is written “c:/wwwroot”.
• Target Directory – is, of course, the directory where you want the encrypted files to end up. The same rules as source directory apply here.
• Replacements – Here is the good stuff. Checking or unchecking these boxes means that a type of conversion is to be made or not to be made. For example, the “variables” option means that the PHP variables will be substituted with garbage characters, to obfuscate the code and ruin the readability. The more you choose, the better is the encryption. Note that some options might make the code invalid! If any problems occur, try unchecking the boxes one by one until usable code is produced. Avoid that checkbox and everything should work fine.
• Removals – The same principle works here. Mark the boxes in order to further obfuscate the code.
• File System – Here are some vital options.
• Replace edited files only – means that only the encrypted PHP files will be transferred to the target directory.
• Recursive scan – The whole directory tree, including subdirectories of your source directory will be processed. Very useful for encrypting entire web sites.
• Copy all files – Marking this checkbox will make POBS copy all the files in the source directory. Pictures, stylesheets, animations, movies. Everything will end up in the new directory. This is perfect for making the new encrypted PHP site easily integrated into the live environment.
• Copyright Text – Well, since you are making the code closed source, you might as well include a copyright notice. This notice will be readable to the naked eye and hopefully deter any reverse engineering attempts.

How To start the machine

You’re ready to go! Click the “Start Processing” button in the bottom of the page. POBS will commence encryption according to your options. This might take a while. Take a break, read the magazine, drink a cup of hot coco and it will be finished when you return.

The final page that POBS shows it the status report. This is a very detailed page displaying everything that has happened and what files that has been processed. Take a few minutes going though this page and check if it looks alright.

You’re done

Yep, that was it. You have encrypted the PHP files and can distribute and/or sell your software without any concerns about copyright violations. Well done!

OpenID is an open, decentralized standard for authenticating users which can be used for access control, allowing users to log on to different services with the same digital identity where these services trust the authentication body. OpenID replaces the common login process that uses a login-name and a password, by allowing a user to log in once and gain access to the resources of multiple software systems. The term OpenID can also refer to an ID used in the standard.

An OpenID is in the form of a unique URL, and is authenticated by the user’s ‘OpenID provider’ (that is, the entity hosting their OpenID URL). The OpenID protocol does not rely on a central authority to authenticate a user’s identity. Since neither the OpenID protocol nor Web sites requiring identification may mandate a specific type of authentication, non-standard forms of authentication can be used, such as smart cards, biometrics, or ordinary passwords.

OpenID authentication is now used and provided by several large websites. Providers include AOL, BBC, Google, IBM, Microsoft, MySpace, Orange, PayPal, VeriSign, LiveJournal, Yandex, Ustream and Yahoo!.

Using OpenID

A basic glossary of the terms used with OpenID:

End-user

The person who wants to assert his or her identity to a site.

Identifier

The URL or XRI chosen by the end-user as their OpenID identifier.

Identity provider or OpenID provider

A service provider offering the service of registering OpenID URLs or XRIs and providing OpenID authentication (and possibly other identity services). Note that the OpenID specifications use the term “OpenID provider” or “OP”.

Relying party

The site that wants to verify the end-user’s identifier. Sometimes also called a “service provider”.

Server or server-agent

The server that verifies the end-user’s identifier. This may be the end-user’s own server (such as their blog), or a server operated by an identity provider.

User-agent

The program (such as a browser) that the end-user is using to access an identity provider or a relying party.

Consumer

An obsolete term for the relying party.

Logging in

The user visits a relying party web site (e.g. website.relying.com) which displays an OpenID login form somewhere on their page. Unlike a typical login form with fields for the user name and password, the OpenID login form has only one field—for the OpenID identifier, typically along with a small OpenID logo. This form is connected to an implementation of an OpenID client library.

A user typically will have previously registered an OpenID identifier (e.g. alice.openid.provider.org) with an OpenID identity provider (e.g. openid.provider.org). The user types his OpenID identifier into the aforementioned OpenID login form.

The relying party web site typically transforms the OpenID identifier into a canonical URL form (e.g. http://alice.openid.provider.org/). With OpenID 1.0, the relying party then requests the web page located at that URL and reads an HTML link tag to discover the identity provider service URL (e.g. http://openid.provider.org/openid-auth.php). The relying party also discovers whether to use a delegated identity (see below). With OpenID 2.0, the client discovers the identity provider service URL by requesting the XRDS document (also called the Yadis document) with the content type application/xrds+xml that may be available at the target URL and is always available for a target XRI.

There are two modes in which the relying party can communicate with the identity provider:

• checkid_immediate, in which the relying party requests that the provider not interact with the user. All communication is relayed through the user’s browser without explicitly notifying the user;
• checkid_setup, in which the user communicates with the provider server directly using the same web browser used to access the relying party site.

The second option is more popular on the Web; also, checkid_immediate can fall back to checkid_setup if the operation cannot be automated.

First, the relying party and the identity provider (optionally) establish a shared secret, referenced by an associate handle, which the relying party then stores. If using checkid_setup, the relying party redirects the user’s web browser to the identity provider so the user can authenticate with the provider.

The method of authentication may vary, but typically, an OpenID identity provider prompts the user for a password or an InfoCard, then asks whether the user trusts the relying party web site to receive his credentials and identity details.

If the user declines the identity provider’s request to trust the relying party web site, the browser is redirected to the relying party with a message indicating that authentication was rejected. The relying site in turn refuses to authenticate the user.

If the user accepts the identity provider’s request to trust the relying party web site, the browser is redirected to the designated return page on the relying party web site along with the user’s credentials. That relying party must then confirm that the credentials really came from the identity provider. If they had previously established a shared secret (see above), the relying party can validate the shared secret received with the credentials against the one previously stored. Such a relying party is called stateful because it stores the shared secret between sessions. In comparison, a stateless or dumb relying party must make one more background request (check_authentication) to ensure that the data indeed came from the identity provider.

After the OpenID identifier has been verified, OpenID authentication is considered successful and the user is considered logged in to the relying party web site with the given identifier (e.g. alice.openid.provider.org). The web site typically then stores the OpenID identifier in the user’s session.

OpenID does not provide its own form of authentication, but if an identity provider uses strong authentication, OpenID can be used for secure transactions such as banking and e-commerce.

Identifiers

Starting with OpenID Authentication 2.0 (and some 1.1 implementations), there are two types of identifiers that can be used with OpenID: URLs and XRIs.

There are two ways to obtain an OpenID-enabled URL that can be used to log into all OpenID-enabled websites.

1. To use an existing URL under one’s own control (such as one’s blog or home page). One can insert the appropriate OpenID tags in the HTML or serve a Yadis document.
2. The second option is to register an OpenID identifier with an identity provider. They offer the ability to register a URL (typically a third-level domain, e.g. example.example.com) that will automatically be configured with OpenID authentication service.

XRIs are a new form of Internet identifier designed specifically for cross-domain digital identity. For example, XRIs come in two forms—i-names and i-numbers—that are usually registered simultaneously as synonyms. I-names are reassignable (like domain names), while i-numbers are never reassigned. When an XRI i-name is used as an OpenID identifier, it is immediately resolved to the synonymous i-number (the CanonicalID element of the XRDS document). This i-number is the OpenID identifier stored by the relying party. In this way, both the user and the relying party are protected from the user’s OpenID identity ever being taken over by another party as can happen with a URL based on a reassignable DNS name.

Adoption

As of December 2009, there are over 1 billion OpenIDs on the Internet (see below) and approximately 9 million sites have integrated OpenID consumer support.

• AOL provides OpenIDs in the form “openid.aol.com/screenname“.
• Orange offers OpenIDs to their 40 million broadband subscribers, and accepts OpenID to allow non subscriber users to access a subset of services.
• VeriSign is offering a secure OpenID service, with two-factor authentication, which they call “Personal Identity Provider”.
• Six Apart blogging hosts TypePad and Vox. Vox supports OpenID as a provider.
• LiveJournal, owned and operated by SUP, supports OpenID as both a provider and a relying party.
• WordPress.com also provides OpenID.
• Dreamwidth supports OpenID as both a provider and a relying party. OpenID is also used on Dreamwidth to allow offsite users to maintain control over imported comments.
• Other services accepting OpenID as an alternative to registration include Wikitravel, photo sharing host Zooomr, linkmarking host Ma.gnolia, identity aggregator ClaimID, calendar booking Bookwhen, icon provider IconBuffet, user stylesheet repository UserStyles.org, and Basecamp and Highrise by 37signals.
• Yahoo! allows users to use their Yahoo! IDs as OpenIDs starting January 31, 2008.
• SourceForge
• Google
• Luxsci is both an OpenID consumer and provider.
• Facebook supports OpenID 2.0, allowing an existing account to have an OpenID associated as an alternative login method.
• In 2.0 RC1.1, Simple Machines Forum allows the administrator to allow registration using an OpenID.

Some of the companies (especially the biggest ones) which did enable OpenID have been criticized for being a provider of OpenID identities to third-party websites, without being an OpenID consumer and allowing credentials of another website to work with their own websites. (For example, logging into Yahoo! through Windows Live credentials).

OpenID Foundation

The OpenID Foundation is a 501(c)(3) non-profit organization incorporated in the United States. The OpenID Foundation was formed to help manage copyright, trademarks, marketing efforts and other activities related to the success of the OpenID community. The single goal of the OpenID Foundation is to protect OpenID.

People

The OpenID Foundation’s board of directors has eight community members and seven corporate members:

Community Members:

• Brian Kissel (JanRain)
• Chris Messina (independent)
• David Recordon (Formerly of Six Apart, now works at Facebook)
• Joseph Smarr (Formerly of Plaxo, now works at Google)
• Nat Sakimura (Nomura Research Institute)
• Scott Kveton
• Snorri Giorgetti (OpenID Europe)
• Allen Tom (Yahoo)

Corporate Members:

• Facebook – Luke Shepard
• Google – Eric Sachs
• IBM – Nataraj (Raj) Nagaratnam
• Microsoft – Michael B. Jones
• PayPal – Andrew Nash
• VeriSign – Gary Krall
• Yahoo! – Raj Mata

A European counterpart, the OpenID Europe Foundation headquartered in Paris, was founded in June 2007. It is a non-profit organization to help promote and deploy the OpenID software framework in Europe. OpenID Europe is independent of the OpenID Foundation. Snorri Giorgetti of OpenID Europe also serves as the OpenID Foundation’s representative in Europe.

Legal issues

The OpenID trademark in the United States was assigned to the OpenID Foundation in March 2008.It had been registered by NetMesh Inc. before the OpenID Foundation was operational. In Europe, as of August 31, 2007, the OpenID trademark is registered to the OpenID Europe Foundation.

The OpenID logo was designed by Randy “ydnar” Reddig, who in 2005 had expressed plans to transfer the rights to an OpenID organization.

Since the original announcement of OpenID, the official site has stated:

Nobody should own this. Nobody’s planning on making any money from this. The goal is to release every part of this under the most liberal licenses possible, so there’s no money or licensing or registering required to play. It benefits the community as a whole if something like this exists, and we’re all a part of the community.

Sun Microsystems, VeriSign and a number of smaller companies involved in OpenID have issued patent non-assertion covenants covering OpenID 1.1 specifications. The covenants state that the companies will not assert any of their patents against OpenID implementations and will revoke their promises from anyone who threatens, or asserts, patents against OpenID implementors.

Security and phishing

Some observers have suggested that OpenID has security weaknesses and may prove vulnerable to phishing attacks. For example, a malicious relying party may forward the end-user to a bogus identity provider authentication page asking that end-user to input their credentials. On completion of this, the malicious party (who in this case also control the bogus authentication page) could then have access to the end-user’s account with the identity provider, and as such then use that end-user’s OpenID to log into other services.

In an attempt to combat possible phishing attacks some OpenID providers mandate that the end-user needs to be authenticated with them prior to an attempt to authenticate with the relying party. This relies on the end-user knowing the policy of the identity provider. In December 2008, the OpenID Foundation approved version 1.0 of the Provider Authentication Policy Extension (PAPE), which “enables Relying Parties to request that OpenID Providers employ specified authentication policies when authenticating users and for OpenID Providers to inform the Relying Parties which policies were actually used.” Regardless, this issue remains a significant additional vector for man-in-the-middle phishing attacks.

History

The original OpenID authentication protocol was developed in May 2005 by Brad Fitzpatrick, creator of popular community website LiveJournal, while working at Six Apart. Initially referred to as Yadis (an acronym for “Yet another distributed identity system”), it was named OpenID after the openid.net domain name was given to Six Apart to use for the project. OpenID support was soon implemented on LiveJournal and fellow LiveJournal engine community DeadJournal for blog post comments and quickly gained attention in the digital identity community. Web developer JanRain was an early supporter of OpenID, providing OpenID software libraries and expanding its business around OpenID-based services.

In late June, discussions started between OpenID users and developers from enterprise software company NetMesh, leading to collaboration on interoperability between OpenID and NetMesh’s similar Light-Weight Identity (LID) protocol. The direct result of the collaboration was the Yadis discovery protocol, adopting the name originally used for OpenID. The new Yadis was announced on October 24, 2005. After a discussion at the 2005 Internet Identity Workshop a few days later, XRI/i-names developers joined the Yadis project, contributing their Extensible Resource Descriptor Sequence (XRDS) format for utilization in the protocol.

In December, developers at Sxip Identity began discussions with the OpenID/Yadis community after announcing a shift in the development of version 2.0 of its Simple Extensible Identity Protocol (SXIP) to URL-based identities like LID and OpenID. In March 2006, JanRain developed a Simple Registration (SREG) extension for OpenID enabling primitive profile-exchange and in April submitted a proposal to formalize extensions to OpenID. The same month, work had also begun on incorporating full XRI support into OpenID. Around early May, key OpenID developer David Recordon left Six Apart, joining VeriSign to focus more on digital identity and guidance for the OpenID spec. By early June, the major differences between the SXIP 2.0 and OpenID projects were resolved with the agreement to support multiple personas in OpenID by submission of an identity provider URL rather than a full identity URL. With this, as well as the addition of extensions and XRI support underway, OpenID was evolving into a full-fledged digital identity framework, with Recordon proclaiming “We see OpenID as being an umbrella for the framework that encompasses the layers for identifiers, discovery, authentication and a messaging services layer that sits atop and this entire thing has sort of been dubbed ‘OpenID 2.0′. ” In late July, Sxip began to merge its Digital Identity Exchange (DIX) protocol into OpenID, submitting initial drafts of the OpenID Attribute Exchange (AX) extension in August.

On January 31, 2007, Symantec announced support for OpenID in its Identity Initiative products and services. A week later, on February 6 Microsoft made a joint announcement with JanRain, Sxip, and VeriSign to collaborate on interoperability between OpenID and Microsoft’s Windows CardSpace digital identity platform, with particular focus on developing a phishing-resistant authentication solution for OpenID. As part of the collaboration, Microsoft pledged to support OpenID in its future identity server products and JanRain, Sxip, and VeriSign pledged to add support for Microsoft’s Information Card profile to their future identity solutions. In mid-February, AOL announced that an experimental OpenID provider service was functional for all AOL and AOL Instant Messenger (AIM) accounts.

In May, Sun Microsystems began working with the OpenID community, announcing an OpenID program, as well as entering a non-assertion covenant with the OpenID community, pledging not to assert any of its patents against implementations of OpenID. In June, OpenID leadership formed the OpenID Foundation, an Oregon-based public benefit corporation for managing the OpenID brand and property. The same month, an independent OpenID Europe Foundation was formed in Belgium by Snorri Giorgetti. By early December, non-assertion agreements were collected by the major contributors to the protocol and the final OpenID Authentication 2.0 and OpenID Attribute Exchange 1.0 specifications were ratified on December 5.

In mid-January 2008, Yahoo! announced initial OpenID 2.0 support, both as a provider and as a relying party, releasing the provider service by the end of the month. In early February, Google, IBM, Microsoft, VeriSign and Yahoo! joined the OpenID Foundation as corporate board members. Around early May, SourceForge, Inc. introduced OpenID provider and relying party support to leading open source software development website SourceForge.net. In late July, popular social network service MySpace announced support for OpenID as a provider. In late October, Google launched support as an OpenID provider and Microsoft announced that Windows Live ID would support OpenID. In November, JanRain announced a free hosted service, RPX Basic, that allows websites to begin accepting OpenIDs for registration and login without having to install, integrate and configure the OpenID open source libraries.

In January 2009, PayPal joined the OpenID Foundation as a corporate member, followed shortly by Facebook in February. The OpenID Foundation formed an executive committee and appointed Don Thibeau as executive director. In March, MySpace launched their previously announced OpenID provider service, enabling all MySpace users to use their MySpace URL as an OpenID. In May, Facebook launched their relying party functionality, letting users use an automatic login-enabled OpenID account (e.g. Google) to log into Facebook.

Overview

Currently, most websites log you in the same way: You enter a username and password, the web-server hashes the password (generally via MD5(), or SHA1()). This hash is then compared to the one stored in a database – if it matches, the user knows the original password, so it logs them in.

This method has numerous problems, such as the password being sent unencrypted to the web-server, and the fact many users reuse passwords, if an intruder works out a users password (though any means), there is a good chance they can log into the same users email account, online banking etc etc..

The whole username/password login method has many flaws, most are down to the fact most people struggle to remember a single 5-6 character password, let alone multiple random messy looking passwords such as “Xm2K?pdT&av”, as most “good password guides” suggest.

GPG (“GnuPG”/”GNU Privacy Guard”) is a free/open-source replacement for PGP. I won’t go into what GPG is, since I guess quite a lot of the people reading this already know, however if you do not, it is primarily used to sign or encrypt email messages – see the page on it

Back to website-logins. When you enter a username/password into a website, you are basically trying to prove you are you, but with this method, you are only really proving you know the password – something that is surprisingly easy to capture. GPG is far more secure than a simple password, as it uses a public/private key system – anything signed/encrypted by GPG is effectively using a 4096 character password, and you never send your password anywhere; only you can sign a message with your private key, and others verify it using your public key.

Since GPG is basically used as an identity-verification tool, it seems logical to use this to prove who you are. You give the site your public key, it gives you a random string, you sign it with your private key and it knows what key-owner signed the string. No private data (private key or password) is ever transmitted.

Steps

• Site displays random string/paragraph.
• The user copies this string, using: gpg --sign -armour
• The user copies the output into a textarea on the site, and submits it.
• The site runs gpg --verify on the returned textarea
• If it validates, who ever’s key it is (“gpg: Good signature from “Bob Smith (Bob) bob@someFakeSite.com“) is logged into the site.

Problems

• Replay attacks. If the signed string is the same, you could simply send the same signed message again. This is easily fixed by using a temporary, random string, like the captcha-systems use. As long as the string is only valid for a short amount of time, these attacks are no longer possible. Even if the string is predictable, the user cannot generate a new signed message.
• Session-stealing. If the login in “remembered” by the site, using cookies, however you login does not prevent “cookie stealing”, so this would be up to the specific site to prevent (Binding the cookie to a specific IP address for example?)
• Mapping GPG-key in GPG keychain to user-account. Not all that complicated, but it’s far more complex than simple MD5($password)..
• Getting users GPG public key. Again, not all that complicated – when the user signs up, they fill in a textarea with their public “ASCII-armored” GPG key.
• One of the bigger problem with this I can foresee is userA putting userB’s public key in their own account – this would lead to duplicate keys. Although this would effectively lock userA from his own account, allowing userB to possibly log in as him. The email/name/nickname could be used to verify who the key belongs to, but since a user may sign up to a site using a nickname or alias, not their real name, it’s may be impossible for the computer to validate this.
• Portability. It’s rather difficult to memorise GPG keys, so the user would be required to carry their keys around if they wish to login from other computers (Schools/libraries/other peoples houses/etc/etc). Although, if SSH is accessible, it’s simple to use GPG on a remote machine (assuming you trust the machine to not have keystroke-loggers and such, but those problems apply even more so to regular password auth)

Implementation

This is just a concept currently, and is yet to be implemented on any site. The biggest hurdle currently seems like the connection between the webpage and the GPG system.

The most obvious method would be system() calls to the “gpg” binary. This would be cross-platform and fairly easy to implement, but does raise possible command-injection security problems (admittedly these are easy to prevent with input-sanitisation).

There is a GPG extension for PHP (called GPGext), which would certainly make implementing this far easier, but I always preferred native implementations over extensions that require shared libraries in system folders and such. There are similar libraries for various other languages commonly used for server-side programming (Perl/Python/Ruby/etc)

Conclusion

For most sites, this is fairly overkill in terms of security. For “normal” users it’s complicated – setting up GPG alone is beyond a lot of people. But, for certain sites (very technically-oriented sites, like BandwidthBandit), where the users are very technically competent, it really becomes a matter of do the users really care enough about their account’s security?

Taking Bandwidth as an example, I’d imagine, no. The most a malicious user could achieve would be to make or delete that users posts – something easily undone.

There are two important things when it comes to security systems. First and most obvious, is the actual security improvements, and second is convenience. If the security improvements aren’t worth the reduced convenience, it’s not going to be popular.

The security improvements are fairly substantial. SSL for a site like BandwidthBandit isn’t practical. With the GPG login system, SSL would be more or less unnecessary, since no passwords are ever sent, and the “signed-message” used to login is invalid once the user has used it once.

The problem is, are these security improvements worth the hassle of having to use GPG every time they want to login? With the regular username/password system, browsers have built-in functionality to remember passwords, so all they have to do is click “Login”. Compare this to having to copy a string, run the GPG command, enter their GPG pass-phrase, paste the string, copy the output to the page and click “Login”..

That’s not to say if the method would ever popularised, it couldn’t be made much easier (By having it built into the browser, or with browser-extensions) – but the possibility of that happening is nearly zero, so the benefit of only having the GPG password to remember is no longer valid (as you still need to remember passwords for every other site on the internet..)

One last thing – this GPG auth system is applicable to any system that can deal with text being sent/receive. IRC for example. This may be a more plausible testing ground for such a concept. Many networks use their own NickServ auth systems, and it would be fairly simple to add a GPG-Auth command to the services, without disruption regular /msg NickServ identify commands. OperServ would benefit most greatly from this, as it would help secure the fairly powerful oper logins, and opers are always going to be very technically competent. The fact IRC clients are also very easily scriptable helps too.

Overview

GNU Privacy Guard (GnuPG or GPG) is a free software alternative to the PGP suite of cryptographic software. GnuPG is compliant with RFC 4880, which is the current IETF standards track specification of OpenPGP. Current versions of PGP (and Veridis’ Filecrypt) are interoperable with GnuPG and other OpenPGP-compliant systems.

GPG is a part of the Free Software Foundation’s GNU software project, and has received major funding from the German government. It is released under the terms of version 3 of the GNU General Public License.

History

GnuPG was initially developed by Werner Koch. Version 1.0.0 was released on September 7, 1999. The German Federal Ministry of Economics and Technology funded the documentation and the port to Microsoft Windows in 2000.

Because GnuPG is an OpenPGP standard compliant system, the history of OpenPGP is of importance. It was designed to inter-operate with PGP, the email encryption protocol developed by Phil Zimmermann.

Version 2.0 was released 13 November 2006. The old stable 1.x branch, whose latest version is 1.4.10, will be continued in parallel with the new GnuPG 2 series because there were significant changes in the architecture of the program which will not fit every purpose.

Usage

Although the basic GnuPG program has a command line interface, there exist various front-ends that provide it with a graphical user interface. For example, GnuPG encryption support has been integrated into KMail and Evolution, the graphical e-mail clients found in the most popular Linux desktops KDE and GNOME. There are also graphical GnuPG front-ends (Seahorse for GNOME, KGPG for KDE). For Mac OS X, the Mac GPG project provides a number of Aqua front-ends for OS integration of encryption and key management as well as GnuPG installations via Installer packages. Instant messaging applications such as Psi and Fire can automatically secure messages when GnuPG is installed and configured. Web-based software such as Horde also makes use of it. The cross-platform plugin Enigmail provides GnuPG support for Mozilla Thunderbird and SeaMonkey. Similarly, Enigform and FireGPG provide GnuPG support for Mozilla Firefox.

In 2005, G10 Code and Intevation released Gpg4win, a software suite that includes GnuPG for Windows, WinPT, Gnu Privacy Assistant, and GnuPG plug-ins for Windows Explorer and Outlook. These tools are wrapped in a standard Windows installer, making it easier for GnuPG to be installed and used on Windows systems.

Process

GnuPG encrypts messages using asymmetric keypairs individually generated by GnuPG users. The resulting public keys can be exchanged with other users in a variety of ways, such as Internet key servers. They must always be exchanged carefully to prevent identity spoofing by corrupting public key ↔ “owner” identity correspondences. It is also possible to add a cryptographic digital signature to a message, so the message integrity and sender can be verified, if a particular correspondence relied upon has not been corrupted.

GnuPG does not use patented or otherwise restricted software or algorithms, like the IDEA encryption algorithm which has been present in PGP almost from the beginning. (It is in fact possible to use IDEA in GnuPG by downloading a plugin for it, however this may require getting a license for some uses in some countries in which IDEA is patented.) Instead, GnuPG uses a variety of other, non-patented algorithms, including:

• Block ciphers: CAST5, Triple DES, AES, Blowfish, and Twofish.
• Asymmetric-key ciphers: ElGamal and RSA
• Cryptographic hashes: RIPEMD-160, MD5, SHA-1, and Tiger
• Digital signatures: DSA

GnuPG is a hybrid encryption software program in that it uses a combination of conventional symmetric-key cryptography for speed, and public-key cryptography for ease of secure key exchange, typically by using the recipient’s public key to encrypt a session key which is only used once. This mode of operation is part of the OpenPGP standard and has been part of PGP from its first version.

Problems

The OpenPGP standard specifies several methods of digitally signing messages. In 2003, due to an error in a change to GnuPG intended to make one of those methods more efficient, a security vulnerability was introduced. It affected only one method of digitally signing messages, only for some releases of GnuPG (1.0.2 through 1.2.3), and there were fewer than 1000 such keys listed on the key servers. Most people did not use this method, and were in any case discouraged from doing so, so the damage caused (if any, and none has been publicly reported) would appear to have been minimal. Support for this method has been removed from GnuPG versions released after this discovery (1.2.4 and later). Two further vulnerabilities were discovered in early 2006; the first being that scripted uses of GnuPG for signature verification may result in false positives, the second that non-MIME messages were vulnerable to the injection of data which while not covered by the digital signature, would be reported as being part of the signed message. In both cases updated versions of GnuPG were made available at the time of the announcement.

GnuPG is a command-line based system, that is not written as an API which can be incorporated into other software. GPGME is an API wrapper around GnuPG which parses the output of GnuPG, and various graphical front-ends based on GPGME have been created. This currently requires an out-of-process call to the GnuPG executable for many GPGME API calls. Because GPGME makes use of a special GnuPG interface designed for machine use, a stable and maintainable API between the components is given. Possible security problems in an application do not propagate to the actual crypto code due to the process barrier.

Other software wraps the command line in a Perl script (e.g. gpg-dialog) that is menu based and more user friendly.

Some more settings you can use in the menu are,

411 show diagnostics data
511 run loopback call test
611 diagnostic data service call c/e/s
126 Lab126 team members