From ffb588086526e73b77b46258c76128c764dc62dc Mon Sep 17 00:00:00 2001 From: Rob van Son Date: Sat, 2 Jun 2012 12:02:46 +0200 Subject: [PATCH] Documentation of login and ticket system --- CGIscriptor.html | 61 ++++++++++++++++++++++++++++++++++--------------- Private/.Passwords/test | 4 ++-- 2 files changed, 44 insertions(+), 21 deletions(-) diff --git a/CGIscriptor.html b/CGIscriptor.html index 3248b06..5adec16 100644 --- a/CGIscriptor.html +++ b/CGIscriptor.html @@ -1532,7 +1532,6 @@ s@regexp@replacement@g instead.

SERVER SIDE SESSIONS AND ACCESS CONTROL (LOGIN)

 -

An infrastructure for user acount authorization and file access control is available. Each request is matched against a list of URL path patterns. @@ -1549,26 +1548,13 @@ PASSWORD ticket with the same name as the user account (name cleaned up for security).

-A Login page should create a LOGIN ticket file localy and send a -server specific SALT, a Random salt, and both the LOGIN and SESSION ticket -identifiers. The server side compares the username and hashed password, -actually hashed(Random salt+hashed(SALT+password)) from the client with -the values it calculates from the stored Random salt from the LOGIN -ticket and the hashed(SALT+password) from the PASSWORD ticket. If -successful, a new SESSION ticket is generated. The SESSION ticket -identifier is available as $SESSIONTICKET, the Username, IP address -and Path as $LoginUsername, $LoginIPaddress, and $LoginPath, respectively. -

-

-In the current example implementation, all random values are created as -a full SHA1 hash (Hex strings) of a 512 byte block read from /dev/urandom. -

-

The example session model implements 3 functions:

  1. Login
    The password is hashed with the server side salt, and then hashed with -a Random salt. The server side only stores the password hashed with the +a Random salt. Client and Server both perform these actions and the +Server only grants access if restults are the same. The server side only +stores the password hashed with the server side salt. Neither the plain password, nor the hashed password is ever exchanged. Only values hashed with the one-time salt are exchanged.
    2. @@ -1577,7 +1563,8 @@ For every access to a restricted URL, the Session Ticket is checked before access is granted.
  2. Password Change
    -A new password is hashed with the server side salt, and then XORed +A new password is hashed with the server side salt, and then encrypted +(XORed) with the old password hashed with the salt. That value is exchanged and XORed with the stored old hashed(salt+password). Again, the stored password value is never exchanged unencrypted. @@ -1599,6 +1586,22 @@ All tickets can have an expiration date in the form of a time duration from creation, in seconds, minutes, hours, or days (+duration[smhd]). An absolute time can be given in seconds since the epoch of the server host.

    +

    +A Login page should create a LOGIN ticket file localy and send a +server specific SALT, a Random salt, and both the LOGIN and SESSION ticket +identifiers. The server side compares the username and hashed password, +actually hashed(Random salt+hashed(SALT+password)) from the client with +the values it calculates from the stored Random salt from the LOGIN +ticket and the hashed(SALT+password) from the PASSWORD ticket. If +successful, a new SESSION ticket is generated. The SESSION ticket +identifier is available as $SESSIONTICKET, the Username, IP address +and Path as $LoginUsername, $LoginIPaddress, and $LoginPath, respectively. +

    +

    +In the current example implementation, all random values are created as +a full, 160 bit SHA1 hash (Hex strings) of a 512 byte block read from +/dev/urandom. +

    Security considerations with Session tickets

    @@ -1606,7 +1609,27 @@ For strong security, please use end-to-end encryption. This can be achieved using a VPN (Virtual Private Network), SSH tunnel, or a HTTPS capable server with OpenSSL. The session ticket system of CGIscriptor.pl is intended to be used as a simple authentication mechanism WITHOUT -END-TO-END ENCRYPTION. +END-TO-END ENCRYPTION. The authenticating mechanism tries to use some +simple means to protect the authentication process from eavesdropping. +For this it uses a secure hash function, SHA1. For all practial purposes, +it is impossible to "decrypt" a SHA1 sum. +

    +

    +Humans tend to reuse passwords. A compromise of a site running +CGIscriptor.pl could therefore lead to a compromise of user accounts at +other sites. Therefore, plain text passwords are never stored, used, or +even exchanged. Instead, a server site SALT value is "encrypted" with +the plain password, actually, both are hashed with a one-way secure hash +function (SHA1) into a single string. Whenever the word "password" is +used, this hash sum is meant. +

    +

    +For the authentication and a change of password, the (old) password +is used to "encrypt" a random one-time token or the new password, +respectively. For authentication, decryption is not needed, so a secure +hash function (SHA1) is used to create a one-way hash sum "encryption". +A new password must be decrypted. New passwords are encryped by XORing +them with the old password.

    USER EXTENSIONS

     diff --git a/Private/.Passwords/test b/Private/.Passwords/test index 779057b..0dd06c5 100644 --- a/Private/.Passwords/test +++ b/Private/.Passwords/test @@ -1,7 +1,7 @@ Type: PASSWORD Username: test -Password: f9fe79236b1e31d6b5966ad447924d517d988a5e -Salt: 13a6bf0002254c123232f24975c386b91319e871 +Password: 288e5fe61ada942a0f700f96c17322a560e26403 +Salt: 46270941646f37e434a0652cff64e9972aab13f1 AllowedPaths: ^/Private/index.html$ AllowedPaths: ^/Private/[^/]+.html$ AllowedPaths: ^/Private/?$ -- 2.11.4.GIT