ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzamv_5.4.0.1/rzamvresworkstationpwd.htm

50 lines
6.7 KiB
HTML
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="concept" />
<meta name="DC.Title" content="Security considerations for workstation session passwords" />
<meta name="abstract" content="This topic discusses the security concerns over passwords being exchanged between workstations and servers." />
<meta name="description" content="This topic discusses the security concerns over passwords being exchanged between workstations and servers." />
<meta name="DC.Relation" scheme="URI" content="rzamvsecstation.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="resworkstationpwd" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>Security considerations for workstation session passwords</title>
</head>
<body id="resworkstationpwd"><a name="resworkstationpwd"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Security considerations for workstation session passwords</h1>
<div><p>This topic discusses the security concerns over passwords being exchanged between workstations and servers.</p>
<p>Typically, when a PC user starts the connection software, such as iSeries™ Access, the user types the user ID and password for the server once. The password is encrypted and stored in PC memory. Whenever the user establishes a new session to the same server, the PC sends the user ID and password automatically.</p>
<p>Some client/server software also provides the option of bypassing the Sign On display for interactive sessions. The software will send the user ID and encrypted password when the user starts an interactive (5250 emulation) session. To support this option, the QRMTSIGN system value on the server must be set to *VERIFY. </p>
<p>When you choose to allow bypassing the Sign On display, you need to consider the security trade-offs.</p>
<p><span class="uicontrol">Security exposure:</span> For 5250 emulation or any other type of interactive session, the Sign On display is the same as any other display. Although the password is not displayed on the screen when it is typed, the password is sent over the link in unencrypted form just like any other data field. For some types of links, this may provide the opportunity for a would-be intruder to monitor the link and to detect a user ID and password. Monitoring a link by using electronic equipment is often referred to as sniffing. Beginning with V4R4, you can use secure sockets layer (SSL) to encrypt communication between iSeries Access and the iSeries server. This protects your data, including passwords, from sniffing.</p>
<p>When you choose the option to bypass the Sign On display, the PC encrypts the password before it is sent. Encryption avoids the possibility of having a password stolen by sniffing. However, you must ensure that your PC users practice operational security. An unattended PC with an active session to the iSeries system provides the opportunity for someone to start another session without knowing a user ID and password. PCs should be set up to lock when the system is inactive for an extended period, and they should require a password to resume the session.</p>
<p>Even if you do not choose to bypass the Sign On display, an unattended PC with an active session represents a security exposure. By using PC software, someone can start a server session and access data, again without knowing a user ID and a password. The exposure with 5250 emulation is somewhat greater because it requires less knowledge to start a session and begin accessing data.</p>
<p>You also need to educate your users about the effect of disconnecting their iSeries Access session. Many users assume, logically but incorrectly, that the disconnect option completely stops their connection to the server. In fact, when a user selects the option to disconnect, the server makes the users session available for another user. However, the clients connection to the server is still open. Another user could walk up to the unprotected PC and get access to server resources without ever entering a user ID and password.</p>
<div class="p">You can suggest two options for your users who need to disconnect their sessions:<ul><li>Ensure that their PCs have a lockup function that requires a password. This makes an unattended PC unavailable to anyone who does not know the password.</li>
<li>To completely disconnect a session, either log off Windows<sup>®</sup> or restart (reboot) the PC. This ends the session to the iSeries.</li>
</ul>
You also need to educate your users about a potential security exposure when they use iSeries Access for Windows. When a user specifies a UNC (universal naming convention) to identify an iSeries resource, the Win95 or NT client builds a network connection to link to the server. Because the user specifies a UNC, the user does not see this as a mapped Network Drive. Often, the user is not even aware of the existence of the network connection. However, this network connection represents a security exposure on an unattended PC because the server appears in the directory tree on the PC. If the users session has a powerful user profile, server resources might be exposed on an unattended PC. As with the previous example, the remedy is to ensure both that users understand the exposure and that they use their PCs lockup function.</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzamvsecstation.htm" title="After you secure printer output, you should secure your workstations. You authorize workstations just like you authorize other objects on the system. Use the EDTOBJAUT command to give users authority to workstations.">Secure your workstations</a></div>
</div>
</div>
</body>
</html>