WordPress Blog with 2FA setup for Windows Live Writer

I use 2 factor authentication for my WordPress blog login. So, when I tried setting up Window Live Writer as my local WordPress blog editor I ran into the following error:


To set up the application-specific password, I had to log on to my WordPress account, navigate to https://wordpress.com/me/security , click on “Two-Step Authentication” tab and click on “Add new application password


Enter a name for my Windows Live Write application and click on “Generate Password”


The new password is displayed on the screen.

I copied the the password into the Windows Live Writer setup window to complete the setup.



I did check “remember password” on the Windows Live Write setup window.


Authentication and authentication protocols

Authentication is the one of the fundamental requirements for ensuring security of important assets. Authentication is the process of validating the identity of an object trying to access an asset. Authentication can be done based on the implementation of one or more the following:

  1. Authentication by what you know.
  2. Authentication by what you have.
  3. Authentication by what you are.

When attempting to authenticate a user/application several industry standard types of authentication may be used depending on various conditions that exists on a subjective basis.

Various types of authentication protocols that is supported by Microsoft Windows Server 2003 family includes:

  1. Kerberos v5 authentication.
  2. SSL/TLS authentication.
  3. NTLM authentication.
  4. Digest authentication.
  5. Passport authentication.

Kerberos v5 authentication protocols: This protocol is either used with password or a smart card for interactive logon. It is also the default method for network authentication of services. The process works like this:

  1. The user on a client system using a password or a smart card authenticates to the KDC.
  2. The KDC issues a TGT to the client. The client system uses the TGT to access the Ticket Granting Service (TGS) which is the part of the Kerberos V5 authentication mechanism on the domain controller.
  3. The TGS issues a service ticket to the client.
  4. The client supplies the required network service with the service ticket. The service ticket provides both the user identity to the service and also the service identity to the user.

So the Kerberos v5 authentication protocol has the following main parts:

  1. Key Distribution Center (KDC)
  2. Ticket Granting Ticket (TGT)
  3. Ticket Granting Service (TGS)

The Kerberos v5 services are installed on each domain controller and a Kerberos client is installed on each workstation and server.

Each domain controller acts as a KDC. The client service uses the DNS to look up for the nearest nearest domain controller and in turn the nearest KDC.

Beginning Windows Server 2003, Kerberos is implemented as a SSP (Security Service Provider) that can be accessed using the SSPI (Security Support Provider Interface)

SSL/TLS authentication Protocols: TLS/SSL authenticates and secures data transfer by using certificate based authentication and symmetric encryption keys. Windows Server 2003 onwards, SSL/TLS protocols are implemented as a Security Service Providers (SSP) using dynamic link libraries that are called SChalnnels that is supplied with the OS implementation. Which one gets used is decided based on the capability of the computer on the other side of the connection. The default SSPs for Windows Server 2003 include the following: Kerberos, Digest, NTLM, SChannel and Negotiate authentication protocols as DLLs in the SSPI.

SChannel SSP is used to access web enabled services such as emails and personal information served over the internet on web pages. The SChannel SSP uses the public key encryption to authenticate parties. It included four authentication protocols that it supports:

  1. TLS v1.0
  2. SSL v3.0
  3. SSL v2.0
  4. Also supports PCT (Private Communications Transport) for backward compatibility.

Schannel then selects the most preferred authentication protocol that both parties can support.

TLS/SSL Architecture: TLS/SSL protocols are layered between the Application layer and the TCP/IP layer, where it can secure and send the application data to the transport layer for farther transport. Just because TLS/SSL works between the application layer and the transport layer it can support multiple application layer protocols.

TLS/SSL assumes that TCP/IP is in use. The main advantage of using TLS/SSL is that it provide the following:

  1. Message Integrity
  2. Message confidentiality
  3. Message authentication

The step by step of how SSL/TLS works:

  1. Client tries to connect to a SSL/TLS enabled service on port 443. The browser will send out the information that will include its supported methods of encrypting data. This includes an encryption type, some random data that encryption program on both side can use in the scrambling routine, and other ssl related data.
  2. Server responds by sending its own random data to be used for the encryption as well as other ssl information that will include its SSL certificate with the public key that the browser will use in the subsequent steps.
  3. The client browser checks the information it has received and compares it to the domain it to the domain it was trying to connect securely with.If the secure certificate information on the web site doesn’t match the domain name the browser will notify the customer that there is a problem. The certificate expiration date and valid certificate authority are also checked at this point.
  4. After validating the server certificate, the browser uses a random data that it encrypts using the agreed upon encryption method. For encryption it uses the public key sent by the server and send this encrypted secret to the server.
  5. With the string that the server received from the browser, both the browser and the web server create a new string and use it to create session keys that their encryption programs use for the rest of the session to scramble and descramble (or encrypt/decrypt) all transmissions for the rest of the session. With the Master Secret key in place, both sides are also able to verify that the data didn’t change in route.

NTLM Authentication: NTLM is the abbreviation for Windows NT LAN Manager This is a Windows network authentication protocol that uses challenge/response system to allow a client to prove its identity without sending the password over the network.  NTLM is the authentication protocol for computers that are not participating in a domain, such as stand-alone servers and workgroups. NTLM is a challenge-response authentication protocol which uses three messages to authenticate a client in a connection oriented environment (connectionless is similar), and a fourth additional message if integrity is desired.

Kerberos has mostly replaced NTLM in domain controller environment within AD implementation, but NTLM still find wide spread usage in environments where the domain controller is unavailable or reachable.

Reference: http://technet.microsoft.com