Secure login - Revision history

Pm705 at 13:03, 20 March 2010

2010-03-20T13:03:09Z

← Older revision		Revision as of 13:03, 20 March 2010
Line 266:		Line 266:
	In the same file you can define the sub ''check_user_password'' as explained in [[LDAP]] and [[LDAP user_login.pl]].		In the same file you can define the sub ''check_user_password'' as explained in [[LDAP]] and [[LDAP user_login.pl]].

	~~[[Category:Howto]]~~
	[[Category:Authentication]]		[[Category:Authentication]]

Tdb01r at 11:56, 12 August 2009

2009-08-12T11:56:46Z

← Older revision		Revision as of 11:56, 12 August 2009
Line 267:		Line 267:

	[[Category:Howto]]		[[Category:Howto]]
			[[Category:Authentication]]

Laci@degas.ceu.hu: /* Caveats */

2009-08-01T22:42:54Z

Caveats

← Older revision		Revision as of 22:42, 1 August 2009
Line 34:		Line 34:
	# ''receive_data'' decrypts the payload, checks credentials, logs in the user if everything checks, and then redirects the browser to the originating page.		# ''receive_data'' decrypts the payload, checks credentials, logs in the user if everything checks, and then redirects the browser to the originating page.

	What is lost in this process of two redirects is the error message when authentication fails. ''Receive_data'' cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. ''C'est la vie''.		What is lost in this process of two redirects is the error message when authentication fails. ''Receive_data'' cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. ''[http://en.wikipedia.org/wiki/C'est_la_vie C'est la vie]''.

	The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent. It also means that '''the secure and eprint servers must synchronize their clocks'''.		The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent. It also means that '''the secure and eprint servers must synchronize their clocks'''.

Laci@degas.ceu.hu: /* Patching Apache::Login */

2009-08-01T22:34:38Z

Patching Apache::Login

← Older revision		Revision as of 22:34, 1 August 2009
Line 244:		Line 244:
	We are making two changes to the ''perl_lib/EPrints/Apache/Login.pm'' module. First, always store the URI of the referring page in the hidden ''target'' variable. Second, set the address of the login page to the value of the configuration variable ''external_login_address'' whenever it is defined.		We are making two changes to the ''perl_lib/EPrints/Apache/Login.pm'' module. First, always store the URI of the referring page in the hidden ''target'' variable. Second, set the address of the login page to the value of the configuration variable ''external_login_address'' whenever it is defined.

	The instructions below are for Eprints version 1.3.1. Locate the line		The instructions below are for Eprints version 3.1.3. Locate the line
	my $form = $session->render_form( "POST" );		my $form = $session->render_form( "POST" );
	in the above module (it should be line 122). Replace it by the following:		in the above module (it should be line 122). Replace it by the following:

Laci@degas.ceu.hu: /* Caveats */

2009-08-01T22:28:55Z

Caveats

← Older revision		Revision as of 22:28, 1 August 2009
Line 38:		Line 38:
	The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent. It also means that '''the secure and eprint servers must synchronize their clocks'''.		The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent. It also means that '''the secure and eprint servers must synchronize their clocks'''.

	The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an oracle to tell whether the password is correct or not (ideal utility for a [http://en.wikipedia.org/wiki/Dictionary_attack dictionary attack]).		The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an [http://en.wikipedia.org/wiki/Oracle oracle] to tell whether the password is correct or not (ideal utility for a [http://en.wikipedia.org/wiki/Dictionary_attack dictionary attack]).

	==Secure login script==		==Secure login script==

Laci@degas.ceu.hu: /* Caveats */

2009-08-01T22:25:40Z

Caveats

← Older revision		Revision as of 22:25, 1 August 2009
Line 36:		Line 36:
	What is lost in this process of two redirects is the error message when authentication fails. ''Receive_data'' cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. ''C'est la vie''.		What is lost in this process of two redirects is the error message when authentication fails. ''Receive_data'' cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. ''C'est la vie''.

	The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent.		The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent. It also means that '''the secure and eprint servers must synchronize their clocks'''.

	The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an oracle to tell whether the password is correct or not (ideal utility for a [http://en.wikipedia.org/wiki/Dictionary_attack dictionary attack]).		The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an oracle to tell whether the password is correct or not (ideal utility for a [http://en.wikipedia.org/wiki/Dictionary_attack dictionary attack]).

Laci@degas.ceu.hu: /* Caveats */

2009-08-01T22:23:18Z

Caveats

← Older revision		Revision as of 22:23, 1 August 2009
Line 30:		Line 30:
	The login process now works as follows.		The login process now works as follows.
	# when a page requires authentication, it creates a "login page" with destination at the secure web site		# when a page requires authentication, it creates a "login page" with destination at the secure web site
	# the "login page" is sent encrypted to the secure site		# data entered to the "login page" is sent encrypted to the secure site
	# the secure site encrypts the payload, and redirects the browser to an unencrypted eprints page ''receive_data''		# the secure site encrypts the payload, and redirects the browser to the unencrypted eprints page ''receive_data''
	# ''receive_data'' decrypts the payload, checks credentials, logs in the user if everything checks, and then redirects the browser to the originating page.		# ''receive_data'' decrypts the payload, checks credentials, logs in the user if everything checks, and then redirects the browser to the originating page.

Laci@degas.ceu.hu: /* Requirements */

2009-08-01T22:21:40Z

Requirements

← Older revision		Revision as of 22:21, 1 August 2009
Line 8:		Line 8:

	===Requirements===		===Requirements===
	You need a ''secure http server'' on the same main domain as ~~your~~ your eprints server. For example, if eprints can be reached on the web address ''<nowiki>http://eprints.umb.edu</nowiki>'', then the secure server must have domain name ending with ''umb.edu'', for example ''<nowiki>https://secure.umb.edu</nowiki>.		You need a ''secure http server'' on the same main domain as your eprints server. For example, if eprints can be reached on the web address ''<nowiki>http://eprints.umb.edu</nowiki>'', then the secure server must have domain name ending with ''umb.edu'', for example ''<nowiki>https://secure.umb.edu</nowiki>.

	You should set up a cgi executable directory on the secure host. The apache config extract below does exactly this so that ''<nowiki>https://secure.umb.edu/eprints/whatever</nowiki>'' requests the script ''/opt/cgi-bin/eprints/whatever'' to be executed:		You should set up a cgi executable directory on the secure host. The apache config extract below does exactly this so that ''<nowiki>https://secure.umb.edu/eprints/whatever</nowiki>'' requests the script ''/opt/cgi-bin/eprints/whatever'' to be executed:

Laci@degas.ceu.hu: /* Receive data script */

2009-07-27T20:08:44Z

Receive data script

← Older revision		Revision as of 20:08, 27 July 2009
Line 132:		Line 132:
	$list[$i] =~ s/%c/:/g; $list[$i] =~ s/%a/%/g;		$list[$i] =~ s/%c/:/g; $list[$i] =~ s/%a/%/g;
	}		}
	$OK=0 if( $list[4] !~ /^\d$/ );		$OK=0 if( $list[4] !~ /^\d+$/ );
	if($OK){		if($OK){
	my $timediff = int(time/60) - $list[4];		my $timediff = int(time/60) - $list[4];

Laci@degas.ceu.hu: /* Caveats */

2009-07-27T19:53:26Z

Caveats

← Older revision		Revision as of 19:53, 27 July 2009
Line 36:		Line 36:
	What is lost in this process of two redirects is the error message when authentication fails. ''Receive_data'' cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. ''C'est la vie''.		What is lost in this process of two redirects is the error message when authentication fails. ''Receive_data'' cannot display the error message as its URL should not be displayed on the user's screen. The final page - which is the original one as well - cannot distinguish between an unsuccessful login and a reload, thus cannot display the error message as well. ''C'est la vie''.

	The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp ~~and~~ checked to be recent.		The encrypted data the ''receive_data'' page receives can be a replay of a sniffed older communication. Thus this data should contain a timestamp which should be checked to be recent.

	The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an oracle to tell whether the password is correct or not (ideal for a [http://en.wikipedia.org/wiki/Dictionary_attack dictionary attack]).		The secure site can also check the credentials, and relay the result only. Interestingly, the result should be sent encrypted, as otherwise the secure site could be used as an oracle to tell whether the password is correct or not (ideal utility for a [http://en.wikipedia.org/wiki/Dictionary_attack dictionary attack]).

	==Secure login script==		==Secure login script==