[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

1535.0. "Lock keyboard - using VMS password ??" by JOCKEY::MARSHALLJ (Glad that the devil is red ......) Wed Sep 30 1992 17:02

    		**  Extending the V3.0 lock keyboard option **
    
    Hi,
    
    I'm trying to work out how, if its possible, to extend the concept of
    lock keyboard under V3.0.   I was quite suprised that I was unable to
    find any mention of this in this conference, but if it has been
    discussed before, please point me accordingly.
    
    What the customer wwants me to do is to be able to automatically
    associatte the users VMS password with the LK option ie. eliminates the
    need to prompt the user.  Their seems to be a `special writable symbol'
    called OA$LCKB_GIVENPSWD  that shows up using <EXAMINE  but I can see
    no mention of this in the documentation.
    
    I suppose what I want to be able to do is read a users (encrypted?)
    password using the UAI dataset, write this value to OA$LCKB_KEYBOARD
    and then modify the code for the LK option to reflect this.  Is this
    possible ?  Anybody done this ?  Does the Change Password functionality
    provide anything that could be used as a basis (unfortunately I don't
    have access to V3.0 at this moment to look at how CP works)
    
    Thanks in advance,
    John

T.R	Title	User	Personal Name	Date	Lines
1535.1	Un-encryption not possible	SCOTTC::MARSHALL	Do you feel lucky?	`Wed Sep 30 1992 17:55`	22
	Hi, VMS (and other) passwords use one-way encryption. That is, there is no way of finding out the plain-text password given the encrypted password. (OK, you can do it by encrypting every possible password and seeing which one matches the encrypted password you have :-) This is why the PASSWORD field of UAI$ is write-only, but the PWD field is read-write. What you (or someone!) really need to do is change the Lock Keyboard function to encrypt the entered password, and test it against that in SYSUAF, using UAI$. But to do this you need an API function to encrypt passwords. You could do this as a site defined function, calling SYS$HASH_PASSWORD. You could even make it do the comparison against SYSUAF and just return yes/no, rather than using UAI$. I think Lock Keyboard was designed to mimic the LATServer keyboard lock functionality, hence the use of a different password. Scott
1535.2	VMS passwords are sacrosanct	IOSG::SHOVE	Dave Shove -- REO-D/3C	`Wed Sep 30 1992 18:10`	16
	The reason why Lock Keyboard doesn't use the VMS password is because the "password" used by Lock Keyboard is not "secure" - that is, it's stored in various places in memory in its original form. It's a fundamental rule that nothing be done to allow even the remotest possibility of the one-way encryption of VMS passwords to be compromised. We even considered checking the Lock Keyboard "password" as entered by the user against the (hashed) VMS password, and _disallowing_ it if it matched, to stop people using the same password and so possibly compromising their VMS password. We didn't. because we decided this was overkill. Dave.
1535.3	Not really a good idea	CHRLIE::HUSTON		`Wed Sep 30 1992 21:18`	24
	>We even considered checking the Lock Keyboard "password" as entered by >the user against the (hashed) VMS password, and _disallowing_ it if it >matched, to stop people using the same password and so possibly >compromising their VMS password. We didn't. because we decided this was >overkill. Hi Dave, This would be overkill, plus not foolproof, not really a security hole, but not what you intended. THere are only so many values for the encrypted password, true it is alot (encr pwd is 64 bits), but there is the possibility that multiple passwords can encrypt to the same value. Actually in VMS 5.5 (I think 5.5) they added a new encryption algorithm since certain long strings were known to hash to the same value as a 2 character subset of the string. So you would set your pwd to a long value then login with something else. VMS didn't like this so they fixed the algorithm. Like I said, not really a security problem, but a hole in what you thought of doing. --BOb
1535.4	Definitely a bad idea	IOSG::TALLETT	Arranging bits for a living...	`Thu Oct 01 1992 09:46`	10
	Also if the lock keyboard stuff used the VMS password it would be open to attack and must therefore do all the intruder stuff. I am talking about if it was done as standard, as a customer customisation I think its fine, as they have to take the responsibility. Regards, Paul
1535.5	KISS!	BRUMMY::MARTIN::BELL	Martin Bell, TCC, Birmingham UK	`Fri Oct 02 1992 16:05`	28
	But if you really want to use the VMS password, write a bit of code to access a "known" file in the user's account, via the network, and test to see if it fails ... eg. dir 0"USERNAME PASSWORD"::LOGIN.COM or something similar. If the password is correct (and LOGIN.COM exists) then the success status should indicate that all is well. If anything fails, which could be the wrong password (or DECnet not available, or file does not exist etc), then assume that baddies are at work and keep the terminal locked. I haven't tried if out, but maybe even the FILE$ dataset could be used, which means that you can test the password from the main (ALL-IN-1) process. I guess that intruder detection would be activated via NETWORK connection (i.e. file access with a username and password), so the necessary security alarms would be activated in case of a hacking attempt. mb p.s. EARS (Electronic Authorisation and Routing System) can be configured to use the VMS password, so you may want to have a peep at how it is done there!