Information Systems:InfoNet Security - Revision history

172.30.20.117: Blanked the page

2015-10-22T15:54:30Z

Blanked the page

Sheilav at 00:02, 22 October 2015

2015-10-22T00:02:35Z

Sheilav at 23:05, 21 October 2015

2015-10-21T23:05:25Z

Sheilav at 23:03, 21 October 2015

2015-10-21T23:03:47Z

Sheilav: Created page with "InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access right..."

2015-10-21T22:59:47Z

Created page with "InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access right..."

New page

InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access rights, and defaults. When a login fails, we do not tell the user which of the ID and password was incorrect – so someone trying to break in won’t know if they hit upon a valid user ID. After an unsuccessful signon attempt, InfoNet will add a record to the user file, which gives the date, and the number of attempts. After five failed attempts, the user ID will be disabled, and the person will have to try a different ID. So by looking at the list of users we will be able to tell if anyone has tried to break in.

[[File:websmart-1.jpg]]

This list shows three people trying to sign on with the incorrect ID – ‘TEST’, ‘BCD’ and ‘VIVIANB’ (one was an example, one was a typo, and one was just wrong). One was tried 5 times then disabled, the other two were only tried once, then apparently the correct ID was used. We know these three ID’s were added by the login program, as the records are incomplete – no authority level. ‘TIFFANYW’ has been disabled manually; not because of 5 failed login attempts.

← Older revision		Revision as of 15:54, 22 October 2015
Line 1:		Line 1:
−	=User=
−
−	InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access rights, and defaults. When a login fails, we do not tell the user which of the ID and password was incorrect – so someone trying to break in won’t know if they hit upon a valid user ID. After an unsuccessful signon attempt, InfoNet will add a record to the user file, which gives the date, and the number of attempts. After five failed attempts, the user ID will be disabled, and the person will have to try a different ID. So by looking at the list of users we will be able to tell if anyone has tried to break in. If someone trying to break in happens upon a valid user ID, it will be disabled after 5 invalid passwords, so no one can break in with a program that tries every possible password.
−
−	[[File:websmart-1.jpg]]
−
−	This list shows three people trying to sign on with the incorrect ID – ‘TEST’, ‘BCD’ and ‘VIVIANB’ (one was an example, one was a typo, and one was just wrong). One was tried 5 times then disabled, the other two were only tried once, then apparently the correct ID was used. We know these three ID’s were added by the login program, as the records are incomplete – no authority level. ‘TIFFANYW’ has been disabled manually; not because of 5 failed login attempts.
−
−	None of the programs are storing cookies on the user’s PC – server side cookies (called SMURFS) are used.
−
−	InfoNet and Web Orders have been made invulnerable to SQL injection attacks. This is done by looking at every selection field a user keys in, and removing all single quotes. This makes it impossible to, for example, search for BOB’S within a partner name; but it also makes it impossible for a malicious user to hijack the SQL statement that is constructed by the program based requests from the user.
−
−	=User Authorities=
−
−	These are maintained in InfoNet / Admin / User Authorities. The user doing the maintenance must have an authority level of 8 or higher (8-administrator, 9-IT).
−
−	[[File:websmart-2.jpg]]

← Older revision		Revision as of 00:02, 22 October 2015
Line 1:		Line 1:
		+	=User=
		+
	InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access rights, and defaults. When a login fails, we do not tell the user which of the ID and password was incorrect – so someone trying to break in won’t know if they hit upon a valid user ID. After an unsuccessful signon attempt, InfoNet will add a record to the user file, which gives the date, and the number of attempts. After five failed attempts, the user ID will be disabled, and the person will have to try a different ID. So by looking at the list of users we will be able to tell if anyone has tried to break in. If someone trying to break in happens upon a valid user ID, it will be disabled after 5 invalid passwords, so no one can break in with a program that tries every possible password.		InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access rights, and defaults. When a login fails, we do not tell the user which of the ID and password was incorrect – so someone trying to break in won’t know if they hit upon a valid user ID. After an unsuccessful signon attempt, InfoNet will add a record to the user file, which gives the date, and the number of attempts. After five failed attempts, the user ID will be disabled, and the person will have to try a different ID. So by looking at the list of users we will be able to tell if anyone has tried to break in. If someone trying to break in happens upon a valid user ID, it will be disabled after 5 invalid passwords, so no one can break in with a program that tries every possible password.

Line 8:		Line 10:

	InfoNet and Web Orders have been made invulnerable to SQL injection attacks. This is done by looking at every selection field a user keys in, and removing all single quotes. This makes it impossible to, for example, search for BOB’S within a partner name; but it also makes it impossible for a malicious user to hijack the SQL statement that is constructed by the program based requests from the user.		InfoNet and Web Orders have been made invulnerable to SQL injection attacks. This is done by looking at every selection field a user keys in, and removing all single quotes. This makes it impossible to, for example, search for BOB’S within a partner name; but it also makes it impossible for a malicious user to hijack the SQL statement that is constructed by the program based requests from the user.
		+
		+	=User Authorities=
		+
		+	These are maintained in InfoNet / Admin / User Authorities. The user doing the maintenance must have an authority level of 8 or higher (8-administrator, 9-IT).
		+
		+	[[File:websmart-2.jpg]]

← Older revision		Revision as of 23:05, 21 October 2015
Line 4:		Line 4:

	This list shows three people trying to sign on with the incorrect ID – ‘TEST’, ‘BCD’ and ‘VIVIANB’ (one was an example, one was a typo, and one was just wrong). One was tried 5 times then disabled, the other two were only tried once, then apparently the correct ID was used. We know these three ID’s were added by the login program, as the records are incomplete – no authority level. ‘TIFFANYW’ has been disabled manually; not because of 5 failed login attempts.		This list shows three people trying to sign on with the incorrect ID – ‘TEST’, ‘BCD’ and ‘VIVIANB’ (one was an example, one was a typo, and one was just wrong). One was tried 5 times then disabled, the other two were only tried once, then apparently the correct ID was used. We know these three ID’s were added by the login program, as the records are incomplete – no authority level. ‘TIFFANYW’ has been disabled manually; not because of 5 failed login attempts.
		+
		+	None of the programs are storing cookies on the user’s PC – server side cookies (called SMURFS) are used.
		+
		+	InfoNet and Web Orders have been made invulnerable to SQL injection attacks. This is done by looking at every selection field a user keys in, and removing all single quotes. This makes it impossible to, for example, search for BOB’S within a partner name; but it also makes it impossible for a malicious user to hijack the SQL statement that is constructed by the program based requests from the user.

← Older revision		Revision as of 23:03, 21 October 2015
Line 1:		Line 1:
−	InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access rights, and defaults. When a login fails, we do not tell the user which of the ID and password was incorrect – so someone trying to break in won’t know if they hit upon a valid user ID. After an unsuccessful signon attempt, InfoNet will add a record to the user file, which gives the date, and the number of attempts. After five failed attempts, the user ID will be disabled, and the person will have to try a different ID. So by looking at the list of users we will be able to tell if anyone has tried to break in.	+	InfoNet uses System i user IDs and passwords to validate users. After a successful logon using the i security, InfoNet has a file that contains authority levels, access rights, and defaults. When a login fails, we do not tell the user which of the ID and password was incorrect – so someone trying to break in won’t know if they hit upon a valid user ID. After an unsuccessful signon attempt, InfoNet will add a record to the user file, which gives the date, and the number of attempts. After five failed attempts, the user ID will be disabled, and the person will have to try a different ID. So by looking at the list of users we will be able to tell if anyone has tried to break in. If someone trying to break in happens upon a valid user ID, it will be disabled after 5 invalid passwords, so no one can break in with a program that tries every possible password.

	[[File:websmart-1.jpg]]		[[File:websmart-1.jpg]]