What it does
The solution consists of client-side code (browser plugin) and server-side code (executable or dynamic library) which cooperate in order to authenticate one another over an intrinsically-unsecure communication infrastructure through a secure (SSL) connection.
As mentioned earlier, the user's password is used to identify the server to the user before identifying the user to the server. This is done by using it as an encryption key to encrypt and sign verifiable data sent to the user. The key derivation process includes random nonce data gathered from both the client and server to prevent replay attacks.
This encrypted data (referred to as Saphe data from now on) includes:
- The IP from which a connection was made to the server
- The URL requested from the server during this connection
- A URL that can be used to send the password to after the user authenticates the server
- A URL that can be used to send reports about suspected Phishing attempts (optional)
It is assumed that if the direct connection to the real server originated from the user's machine (the returned 'client IP' match) and the requested URL matches the one sent by the user's browser (the returned 'requested URL' match) then the connection is indeed tamper-free. In combination with the knowledge of the user's password (verified by deriving the key and checking the signature) it can be assumed that no Phishing attempt is taking place. The Phishing scenarios section elaborates on how these details prove there is no Phishing attack in progress.
How it works
After the plugin is installed on the user's machine, a normal login attempt to the real target server will be as follows:
- The user opens the server's login URL with his browser by sending an HTTP GET request to the server
- The server returns a web page, containing an HTML <embed> tag that is associated with the Saphe data type. This tag contains the target URL for sending the Saphe request
- The user's browser automatically identifies the Saphe data type and creates a plugin instance which opens the Saphe dialog box
- The plugin attempts to discover the user's real IP address by sending a secure (SSL) request to a well-known server which provides such a service. This is done since currently many user machines are connected to a home or office network that uses a NAT server in order to connect to the Internet, which means that the machine's own IP address is not valid on the Internet. This is the best way to discover the real IP address of the user machine, but is not perfect
- After discovering the user's real IP address, the user is prompted to enter his user name and password
- An HTTP POST request is sent to the URL that was specified in the <embed> tag ONLY if this URL is secure (starts with 'https://'). The POST request includes the user name and a randomly-generated buffer (referred to as client-challenge) that will be used to derive the key (in combination with the password and a similar server-generated buffer). Note that the password is NOT sent to the server at this time
- The server receives the POST request, extracts the user name and uses it to recover the password (supposedly from a data-base). If the user does not exist or blocked – an appropriate message is sent back to the user
- If the user name is valid, the server uses the password, the client-challenge, the source IP address of the connection and the requested URL (including the domain name) in order to generate an encrypted response. First a random server-challenge is generated and used to derive an encryption key in combination with the client challenge and password. Then an initialization-vector for the AES algorithm is generated. Finally, the response is created by encrypting the aforementioned data in CFB mode and the plain data is signed using SHA-1 HMAC to verify its integrity. The response is sent to the user
- The user's browser directs the response to the plugin, which uses the password, client-challenge, server-challenge and initialization-vector to derive the same key and decrypt the Saphe data received the server. It then automatically compares the IP address and requested URL sent by the server in order to ascertain that the connection is secure
- If the connection is secure, the plugin automatically sends the user name and password to the supplied login URL only if this URL is secure (starts with 'https://'). The response will be handled by the browser itself and the login will successfully complete
- If the connection is not secure, then the user will be notified of a possible Phishing attempt, and a message will be sent to the optional Phishing attempts URL to report this incident (the report includes the user's IP address and the requested URL)
You can also see a graphical description of this process.
Note that the server is responsible to limit the number of consecutive login attempts each user is allowed before blocking him.
See implementation documentation for even more information.