sábado, 26 de janeiro de 2013

JAVASCRIPT AUTHENTICATION WITH DELPHI REST SERVER

POST #011 ============================================================================= 
Has anyone done Javascript authentication with a Delphi REST server application?

It makes sense to ask about authentication, since without authentication anyone will be able to connect to your web server and execute all server methods available.

In this mini-video, it shows the DataSnap authentication scheme and  mORMot using the HTTP transport layer. My first webservice using the framework mORMot.

AUTHENTICATION SCHEME WITH DATASNAP:

The DataSnap authentication scheme is the awful "Basic Authentication". This scheme is used by most web services (about 95% of webservices).

It is available by default "native" in all browsers, but has some known weaknesses, such as a) that terrible authentication window displayed by browsers b) no appeal to have the feature "logout-like" and c) the fact that the username and password are transmitted "in plain text" to the server (it would be safer to leave the password only stay on the client side, while the keyboard input, and be stored as a hash in secure Server).

The first time a JS client calls the DataSnap REST server, it creates a new session ID and returns it in a custom HTTP header "dssession." Subsequent requests from the client must include a header "Pragma" with the session ID to the server to recognize that the request comes from the same client. This session remains active until the time expires (by default is 20 minutes).

The support code generated by the DataSnap wizard manages the session ID with a JavaScript global variable "$$$$SessionID" and passes next to each AJAX call on the same page. If you change the page or refresh it the session ID is lost.

You can, however, force the code to add this support JavaScript session ID cookie to a browser, so that is still available on all pages. If you try to call a REST URL directly in the browser, you'll be prompted to login HTTP standard. Once the user is authenticated and its session, the method is not called again.

In short, a flexible architecture is always welcome, but the authentication scheme used by Embarcadero is really useless in any real situation, do not use adequate security. You are transmitting clear text, you are transmitting the password! No matter you encrypt the session, is a basic flaw send the password itself.

Another point is unpleasant is when the credentials "username and password" are wrong, you need to restart another session, reopen the browser to be challenged for a username and password dialog box Basic authentication, this is really terrible. 


AUTHENTICATION SCHEME WITH MORMOT:
I did not understand how mORMot Authentication scheme works fully yet. The authentication process is quite secured and complex. It uses a nonce and to increase security, add a salt at the beginning of a SHA-256 hashed expression. The authentication scheme require to exchange binary data, using “params” they are encoded in strings. The connection handshaking requires more than a single call to establish the security context.

The SHA hash functions were designed by the National Security Agency (NSA). SHA-256 is one of the four variants in the SHA-2 set. It isn't as widely used as SHA-1, though it appears to provide much better security.
In mORMot, in order to create a new user session, first of all:
a) a JS Client sends a
GET ModelRoot/auth?UserName=... request to the remote server;
b) Server answers with an hexadecimal nonce contents (valid for about 5 minutes);
c) Client sends a GET ModelRoot/auth?UserName=...&PassWord=...&ClientNonce=... request to the remote server, in which ClientNonce is a random value used as Client nonce, and PassWord is computed from the log-on and password entered by the User, using both Server and Client nonce as salt;
d) Server checks that the transmitted password is valid, i.e. that its matches the hashed password stored in its database and a time-valid Server nonce - if the value is not correct, authentication failed;
e) On success, Server will create a new in-memory session (sessions are not stored in the database, for lighter and safer process) and returns the session number and a private key to be used during the session;
f) On any further access to the Server, a &session_signature= parameter is added to the URL, and will be checked against the valid sessions in order to validate the request;
g) When the Client is about to close (typically in TSQLRestClientURI. Destroy), the GET ModelRoot/auth?UserName=...&Session=... request is sent to the remote server, in order to explicitly close the corresponding session in the server memory (avoiding most re-play attacks);
Looks like Embarcardero is unable to understand what security means in today's world. Please go back to drawing board and design a more modern solution - and not one of the 80's.
 


Tags: Datasnap authentication scheme; mORMot authentication; Javascript authentication;