Strongbox Authentication Methods


Strongbox security system can work with just about any type of user list that might exist, and even simultaneously use several different types of user lists, such as a standard password file, a MySQL database, and a remote authentication server. Most used setups are:

  • Password files
  • SQL Databases

Who or what manages the authentication databases?

The most important aspect to consider is that those password files or databases are usually managed by another system, Strongbox performs a read-only access operation to those authentication databases. Strongbox Admin interface can be used to add users locally, but that’s not recommended unless you have a really small site manually managed by a webmaster.

Usually a third-party script from a payment processing company takes care of adding and removing users from your password file or database, usually by sending data to a script installed in your site, Strongbox need to have read access to those password files or databases, and does not interfere with such third-party scripts.

When Moving your site and Strongbox to a New Server or doing important server upgrades please contact each third-party involved: payment processing companies, your hosting provider and your IT support staff to ensure your third-party script can continue adding and removing users without problems.

Additionally Strongbox has its own administrative password file to grant to access to Strongbox Admin users to the admin interface, learn more at Strongbox Admin Users.

Types of authentication: .htpasswd, SQl, remote, IP , custom

There are several types of authentication methods that the Strongbox security system can use, most of the time

  • .htpasswd style password files
  • SQL databases accesed via DBI perl modules (Perl’s Database Interface).
  • remote authentication servers over HTTP
  • IP based, like a whitelist to bypass Strongbox protection
  • and using a custom user specified Perl routine, which can use existing modules for accessing LDAP, PAM, or any other type of user database. Ask us about this

Password files

.htpasswd password files the Strongbox security system can use one or more old fashioned .htpasswd style password files using either the old standard DES encryption, which is quite weak, or stronger encryption such as an SHA1 hash or best, a salted MD5 hash.

SQL Databases (NATS, etc.)

The Strongbox security system can also authenticate against a database using MySQL, MS-SQL, Pg-SQL, Oracle, or any other SQL database supported by Perl DBI. The settings related to SQL authentication are located in cgi-bin/sblogin/config.pl. To switch to SQL authentication you’ll need to uncomment the first couple of lines in this section by removing the hash marks from these lines:

 # require DBI; # disabled by default
 our $dbinfo = {
     'db'              => 'natsdb',
     'user'            => '',
     'password'        => '',
     'host'            => 'localhost',
     'table'           => 'members',
     'ckuser'          => 'username',
     'ckpass'          => 'password',
     'crypted'         => 0,              # 'crypt', 'DES', 'PASSWORD', 'MD5', 'MD5_salt', 0, or \&somesub
     'where'           => " status=1 ",
     'extra_fields'    => undef,          #  ' *, '
     'socket'          => undef,          # '/tmp/mysql.sock'
 };
 @htpfiles  = (
   [\&checkpasswd_mysql,    $dbinfo ],
   [\&checkpasswd_htpasswd, "$ENV{'DOCUMENT_ROOT'}/../private/password-file1" ],
   [\&checkpasswd_htpasswd, "./.htpasswd_admin" ]
 );

To use 2 different databases

 # require DBI; # disabled by default
 our $dbinfo = {
     'db'              => 'natsdb',
     'user'            => '',
     'password'        => '',
     'host'            => 'localhost',
     'table'           => 'members',
     'ckuser'          => 'username',
     'ckpass'          => 'password',
     'crypted'         => 0,              # 'crypt', 'DES', 'PASSWORD', 'MD5', 'MD5_salt', 0, or \&somesub
     'where'           => " status=1 ",
     'extra_fields'    => undef,          #  ' *, '
     'socket'          => undef,          # '/tmp/mysql.sock'
 };
 # Create a second array like the one above
 our $dbinfo2 = {
     'db'              => 'db2',
     'user'            => 'username2',
     'password'        => 'pw2indedb',
     'host'            => 'localhost',
     'table'           => 'members',
     'ckuser'          => 'username',
     'ckpass'          => 'password',
     'crypted'         => 0,              # 'crypt', 'DES', 'PASSWORD', 'MD5', 'MD5_salt', 0, or \&somesub
     'where'           => " status=1 ",
     'extra_fields'    => undef,          #  ' *, '
     'socket'          => undef,          # '/tmp/mysql.sock'
 };
 @htpfiles  = (
   [\&checkpasswd_mysql,    $dbinfo  ],      # First DB
   [\&checkpasswd_mysql,    $dbinfo2 ],      # Second DB
   [\&checkpasswd_htpasswd, "$ENV{'DOCUMENT_ROOT'}/../path/example-password-file1" ], # If user is not in DB, look into this password file
   [\&checkpasswd_htpasswd, "$ENV{'DOCUMENT_ROOT'}/../path/example-password-file2" ], # Second fallback auth source, use as many you need
   [\&checkpasswd_htpasswd, "./.htpasswd_admin" ]   # Do NOT add normal users here, see Strongbox Admin Users
 );

 

Adding Or Changing Payment Processors

Strongbox security system can be used with virtually any payment processor and can use several different processors simultaneously. There are two ways to set up multiple processors. When you add or switch processors you can simply have the new processor’s user management script work with the existing password file. Using that method, you do not need to change anything in the the .htaccess or the Strongbox security system ™ configuration file. Using the password file that is already configured, changes to your processor are completely transparent to the Strongbox security system tm. The .htaccess file in the members’ area should NOT be changed. If someone else is installing the script for the new processor, advise them to leave the .htaccess as is. The second method, which we think is slightly better, is to have the new processor create their own password file and then set Strongbox to read both password files. To see where the password file is, or to change that information, adjust the @htpfiles array at the top of cgi-bin/sblogin/config.pl. If you’d like the new processor to use a separate password file, simply add the path to the new password file to @htpfiles like so:

 @htpfiles  = (
 #          [\&checkpasswd_mysql,    $dbinfo ], # disabled by default
            [\&checkpasswd_htpasswd, "$ENV{'DOCUMENT_ROOT'}/../.password_file1" ],
            [\&checkpasswd_htpasswd, "$ENV{'DOCUMENT_ROOT'}/../cgi-bin/path/.password_file2" ],
            [\&checkpasswd_htpasswd, "./.htpasswd_admin" ] # See Admin Users
              );

Note the comma separating the two password files.Also note that rather than entering the full path to the files, such as /home/userame/domain.com/public_html/ccbill/.htpasswd, we used the environment variable DOCUMENT_ROOT to specify the base directory of your web site. We could have hardcoded the full path, but if your site was moved to a new server or moved to a different directory on the same server, the path would no longer be valid and it wouldn’t work. By using DOCUMENT_ROOT it should continue to work even if your site is moved. For processors that use dialers or a database of users rather than an old fashioned password file. (Read more about Moving Strongbox to a New Server).

 

service